Why I'm Productive in Clojure (2013)

http://yogthos.net/posts/2013-08-18-Why-I-m-Productive-in-Clojure.html

by tosh • 9 years ago

182 237 9 years ago

As the project matures bugs are inevitably found or new features are added, these correspond the occasional spikes in the activity. However, if the initial phase of the project can't be completed in a timely fashion then nothing else can happen.
In my experience, if you can't get something interesting working in a few days the likelihood of actually finishing the project starts rapidly approaching zero.
With Clojure you can get things done fast, fast enough that you get something working while the initial spark of excitement is still present. I would hazard to guess that this is the reason why Clojure has so many great libraries despite being a young language.

grzm• 9 years ago

(2013)

Discussion from a couple of years ago (97 comments):

https://news.ycombinator.com/item?id=8074186

ronnier• 9 years ago

I’ve already seen large scale clojure projects being rewritten to something average devs can maintain. Don’t expect much more growth out of this language in terms of new projects written in clojure.

zengid• 9 years ago

What domain were these projects in? What was the 'average' developer unable to grok?

quickthrower2• 9 years ago

They can't grok how they will get a higher paid job after once they reset the "years' experience" clock on their chosen stack.

imhoguy2• 9 years ago

Could you elaborate more on that, please? I wonder what are challenges of Clojure in large scale or legacy projects. I already know finding devs with Clojure/FP as core skill is harder than e.g. Java devs. But I have also seen Java projects being rewritten to PHP for similar reason so... just curious the other arguments about rewrite.

zubairq2• 9 years ago

I started again to rewrite my project from clojure as can be seen on my Github repository (https://github.com/zubairq/gosharedata/) but the problem was NEVER Clojure. By writing Clojure for 5 years it made me a better Javascript programmer I would say!

sheepmullet2• 9 years ago

What exactly do average devs struggle with?

Who is making these decisions to rewrite?

It would be great if we can see a before and after comparison.

Clojure is a pretty simple language. Ive taught it to junior devs with only Java experience and they learn it within a few weeks without any major problems.

weego• 9 years ago

It's a business struggle. You're not going to hire Clojure devs. You're just not.

So every hire will be a cost to cross train through language as well as get used to the codebase. And a lot of more seasoned devs are very binary about lisps. I personally wouldn't work at a place that wanted me to do Clojure over Scala/Java/Kotlin.

I worked at a globally known media company that were primarily a Scala company and they had made a handful of applications from people with Scala experience a year at best. The churn of every skilled dev leaving being replaced by someone very green is a horrible opportunity cost even for a large business.

Sevrene• 9 years ago

Who is making these decisions to rewrite?

Anecdotal evidence incoming: For any rewrite it's always the developer. Every time. It might sometimes be the manager's decision to do it, but it's always instigated by a developer.

always_good4• 9 years ago

The hard part about Clojure is the editor tooling, like learning Paredit and how to evaluate code in the buffer. And then training yourself to actually do it.

It's similar to training someone to use Vim in that it's quite a different tooling set and workflow they're probably used to. I think that's the main barrier.

The language itself is pleasantly simple. And tools like Paredit make it one of the most pleasant languages to write. It's just hard for someone to appreciate Clojure until they put in the work to credentialize in its tooling.

macroexchange• 9 years ago

Clojure is great for beating the averages, see: http://www.paulgraham.com/avg.html

Clojure growth is just fine. If average devs have to add something there is Java. In our experience maintenance of Clojure code is orders of magnitude better than average languages (Python, Java, etc). Yes, object orientation in large organizations leads to the most unimaginable mess. People mostly get paid for unproductive behaviour. Clojure is great for startups where you can do things right.

zubairq2• 9 years ago

I agree with this. It was this Paul Graham essay that made me use Clojure/Lisp in the first place :)

hellofunk21• 9 years ago

Ten years ago (appoximately) I read an article about how PHP was dying, thanks in part to many new languages cropping up. But I see PHP mentioned all the time here on HN, and the PHP meetups in my area are frequent and popular, and major companies run on PHP.

For decades, there have been rumors about the death of dynamic languages in general. And yet the decades pass and not only do those languages continue to flourish, but others come along and get popular too.

Clojure just turned 10 years old and I see no signs of it slowing down. They did consolidate their 2 major conferences in the States into just one annual conference, so there's that (which may not mean anything). But I am in a large city and companies keep appearing and starting up with Clojure as their key language.

With Clojure, it's an oddball because it is very simple and very powerful. Oftentimes, simple languages are not so powerful, and powerful languages are not so simple. But with Clojure, you can very easily get yourself into the situation of having extremely dense logic in just a few lines, where another language might easily take 10x (or more) lines to accomplish the same. This leads to code that can indeed be difficult to read later, especially if you are on a team and others must help maintain it. The Clojure community has come up with some excellent solutions to this problem, most recently the Clojure.spec library which is gaining wide adoption, which not only makes such "cleverness" easier to understand when reading it, but also makes a codebase automatically testable with property generators, which is a major feature. But your point about readability is always going to exist with a language like Clojure if it isn't written with a team in mind. That doesn't take away from its power though, in my opinion.

However, there is one particularly indispensable tool that Clojure offers that I have not seen anything to meaningfully compete with for productivity, and that's ClojureScript. Writing a front end with Reagent or even the alternative libraries is such a major win over everything else I've tried. I've worked a bit with Elm, Typescript, Reason, Bucklescript -- I am so spoiled by the extremely fast turnaround and easy interaction with very powerful features like React in Clojurescript that I don't see anything on the horizon that will come close to replacing that workflow for now. Perhaps some day something will come along to shine an even brighter light on how front ends can be developed, but for now, ClojureScript remains one of the most significant contributions to the software industry in many, many years.

user59944613• 9 years ago

PHP has a massive following. It was basically the only language for the web 1-2 decades ago, everything had to be written in PHP. Of course, it cannot be extinguished since the existing sites will drag on forever.

Clojure never had much usage on real world projects. It cannot be extinguishes as it never took of.

j_m_b2• 9 years ago

I second the statement about ClojureScript. It makes developing in Javascript so much nicer and cleaner. With so much work these days being "full-stack", the combination of Clojure/Clojurescript is Clojure's killer feature for me.

kibwen2• 9 years ago

Eh, I don't use Clojure, but I don't think that a lack of a high growth rate is that big a deal. By my unscientific estimate, languages only need about 20,000 active OSS contributors to have a healthy OSS ecosystem, and that's easier to achieve than ever given the growth in the absolute number of programmers. As long as the growth of the language outpaces the attrition rate, it can thrive just the same.

aaron-lebo2• 9 years ago

I've never heard this expressed, but it makes a lot of sense. Wonder what that actual number would be and the best way to measure it?

whalesalad3• 9 years ago

I can confirm this 100%. I've had to work with some really really bad Clojure software that is unbelievably hard to maintain. This is not a fault of the language, but just more proof that no language is a magic bullet.

vemv5• 9 years ago

My thoughts exactly.

There are many ways to use Clojure, the laziest one of course being the least maintainable. No language can subsitute engineering principles, years of experience, empathy etc.

I wrote a few hints of what I consider maintainable here -> https://blog.vemv.net/maintainable-clojure-beyond-aesthetics...

blain_the_train6• 9 years ago

I would imagine one reason for this is because the real complexity of a project has nothing todo with the programming. It has to do with evolving the business. Were on our 3rd re-write of our business, but the codebase still has legacy systems from the first two drafts. No language can save you from that.

new_account5648• 9 years ago

I'm trying to evaluate clojure for standard enterprise applications. But I haven't seen anything on how to model entities and relations without a database:

   Entities:Person, Insurance, Car
   Relationships:
   Insurance--hasHolder-->Person(m:1)
   Insurance--insures-->Car(1:m)
   Car--hasPrimaryDriver-->Person(1:1)
   Person--drives-->Car(m:n).
   Additional constraint: hasPrimaryDriver(C,P) => drives(P,C).

The domain has cyclic relationships, hence I cannot model it as a tree. If everything is immutable, I have to update all entities that reference each other when replacing one?! What's the standard clojure way to implement it?

jasim3• 9 years ago

This was one of the questions (unarticulated at the time) that kept me away from value-based (immutable) programming for a long time.

The answer is straight forward: you use unique identifiers instead of references. A lot of your code would become similar to how you write SQL queries. You always use `id` to cross-reference entities. You can use whatever enumerable functions are in the language - List.find, Map.find etc.

Now if you want to mutate a leaf node inside a tree, well that question is itself invalid. You can't "mutate" a "value". Can you say mutate the number 12? Or the letter 'B'? Imagine every complex data-structure was atomic like this: the array [1,2,3] always remain [1,2,3]. You can't mutate it because it is one single value; you can get information from inside it, but that doesn't mean you can go and change it. If you do want to change it, then you "transform" it into a new value. So instead of using `array.push` in Javascript, you'd use `array.concat` which provides a new value. Or even better you always use the rest operator `{...oldHash, someKey: newValue}`.

This also means your complex, large tree structure is a "value". You can't mutate it. You can however transform it into a new value. So if your leaf node has to change, then it means what you now have is an entirely new value. The old value still exist; any variables that pointed to the old value still point to that, because, duh, values don't change. Rich Hickey has articulated all this really well in his talk "The Value of Values" (https://github.com/matthiasn/talk-transcripts/blob/master/Hi...)

You'd now be rightly vary of the space-time implications of copying over large sets of data everytime you want it changed a tiny bit. This is solved in functional languages by using structural sharing. When you get a new tree value with just one node changed, the runtime would actually share most of the tree structure, and newly create just the one we want changed. It'll update the reference pointer of the root node, and the entire path that goes from the root till the leaf that changed. This means if you do a shallow comparison between the new tree value and the old tree value, you'll immediately know they're different. You can also safely assume that the entire path till the changed leaf has a new reference and you can do quick shallow comparisons.

This is however an optimization and implementation detail. We're able to do this because structural sharing still allows us to keep the semantic model of everything is value for all practical purposes yet have the benefits of immutability.

OCaml lets you do both though - it supports the imperative place-oriented way of programming and value-oriented programming. It encourages value-oriented programming through its syntax and runtime library, but when you need it (for performance reasons), it is there for you.

cutler16• 9 years ago

I don't quite understand your question. Isn't entity relationship modelling an abstraction over the database rather than something separate? In Clojure raw SQL with something like HugSQL is more idiomatic than anything resembling an ORM though you can try to use Clojure as a simpler way of accessing Java classes, in which case all the usual suspects are available.

refset• 9 years ago

This would do the trick: https://github.com/tonsky/datascript

blain_the_train6• 9 years ago

Don’t expect much more growth out of this language in terms of new projects written in clojure.

Why would an average dev not be able to maintain a clojure code base? I'm going to guess what you really mean is a average dev that doesn't know clojure. In which case the argument your really making is that its hard to find "clojure devs". Which I think runs contrary to the numbers which suggest many more people wanting to work in clojure then can find jobs. This piece seems to echo that sentiment: https://juxt.pro/blog/posts/clojure-job-market.html

I think by and large companies probably struggle to find clojure devs in there immediate area. Which is why i see all the clojure jobs either

A) remote B) in big cities

So its possible that companies could get great devs for less if they just allowed for remote.

Nothing backed up here by hard evidence, but worth considering that the language might not really be the only factor here.

yogthos21• 9 years ago

If a dev can't work with Clojure, I'd be pretty suspect about their coding ability in general. I have yet to work with somebody who couldn't pick it up in a few weeks or so.

sd342• 9 years ago

If a dev is dumb enough to advocate clojure, I'd be pretty suspect about their coding ability in general. I have yet to work with a decent programmer who liked it.

mmargerum5• 9 years ago

I’ve been doing c, c++, and objC for over 20 years and am just getting started with Clojure. Sure, it’s easy to understand the basics of clojure in a few weeks but it’s going to take me a while to stop thinking imperstively and objected oriented. Mutating everything is programmed in me at this point. I think it’s going to take me months to get decent at Clojure if not a year. I’m sold in the ideas but it’s not easy if you have been doing imperative style programming . I’d bet it’s almost easier for a novice to pick up Clojure

cutler16• 9 years ago

Examples?

maxpert2• 9 years ago

I have honestly tried many many times to read books/tutorials for getting started in LISP. I know there are many LISP inspired languages and Clojure is one of them. Where LISP throws me off is the excessive use of parenthesis, up-to the point my mind can't keep track of them anymore and IMHO language uses it's comprehension abilities. I am still struggling and pushing hard to learn it; hopefully I can get over it and experience the most powerful language. Any good starting projects/ideas I should try doing in LISP/Clojure etc. to help me out?

hellofunk21• 9 years ago

The parenthesis disappear from your thoughts after a few days, especially if you are using a proper editor with a feature like paredit.

Clojure improves on this compared to other lisps because it uses brackets and squiggly braces instead of parenthesis for a lot of its syntax, making that aspect much easier to read.

Just stick with it, you will see it is a non-issue after you get started in earnest.

vbuwivbiu3• 9 years ago

function.(x,y,z)

(function x y z)

civility2• 9 years ago

I happen to like Lisp (well, Scheme at least), but I think a better comparison would be:

    let a = 123, b = 456, c = 789;
    # more code

vs:

    (let ((a 123)
          (b 456)
          (c 789))
          ; more code
     )

In many cases outside of function calls, there are more parens.

vbuwivbiu3• 9 years ago

that should have been object.function(x,y,z) or function(x,y,z) - typo and it's too late to edit

rixed• 9 years ago

Last time I checked there were not more parenthesis in lisp than parenthesis+brackets+curly brackets on other languages.

If you need the visual differences between those various kind of parentheses, many lisps and schemes allows to use and mix any of those.

If you are confused because the parentheses are not in the usual place, then I think you are trying to solve problems that are too trivial if such a tiny bit of syntax get all the attention. Or, that you are trying Lisp on problems that are not a good fit. Obviously, lisp (or ML, for that matter) shines at manipulating symbols, not bytes.

I do not personally believe that lisp is, in general, "the most powerful language", but there is a problem where it can be said that it is the most powerful language: it's to write a Lisp interpreter.

Maybe that's the good starting project you are looking for? If so, I can't recommend enough the book "lisp in small pieces".

hellofunk21• 9 years ago

Last time I checked there were not more parenthesis in lisp than parenthesis+brackets+curly brackets on other languages.

This is true a lot of the time. Also, commas don't exist in Clojure.

So you might have this in a C-like language:

     if ((foo > bar) && (bar > boo)) {
        doSomething(a,b,c);
     } else {
        doSomethingElse(d,e,f);
     }

And in Clojure:

     (if (> foo bar boo)
         (doSomething a b c)
         (doSomethingElse d e f))

Another interesting side effect is that in C-like lang, one my say that due to precedence rules, (foo > bar) does not need the parenthesis since && is lower precedence. Yet, if you weren't sure, you'd have to take a short break and go look that up to be certain. Most devs will just keep the parenthesis instead of take that little break, or they will write them in anyway for readability. In Lisp, precedence rules are never an issue because all operators and functions are applied the same way. So the parenthesis might seem cumbersome at first, but they quickly make syntax quite a lot simpler.

kazinator2• 9 years ago

Use an editor that helps balance parentheses and automatically indents Lisp code. If the indentation is consistent with the parentheses (very easy to maintain with a decent editor) then you can mostly ignore the parentheses and just look at the indentation.

Break big functions with deep nesting into smaller functions. (Like in any language). If you have to page up and down several screenfuls to check whether multiple blocks are at the same indentation level and under the same parent, maybe the function is too big.

sn9• 9 years ago

Parentheses aren't an issue if you write Lisp in Emacs.

hellofunk21• 9 years ago

You don't need emacs for good parenthesis control. The same tools emacs uses for this are available in about a dozen editors at least. Vim, Atom, Cursive/IntelliJ, Eclipse, Sublime Text, it's pretty common in most good editors.

platz10• 9 years ago

Understanding programs with recusion requires actually programming with recusion that many devs just aren't exposed to. It's just not the dominant paradigm

yogthos21• 9 years ago

You don't even have to use Emacs nowadays. Atom has lisp-paredit and parinfer package, VS Code has paredit, Cursive has a structural mode, and so on.

grayrest• 9 years ago

Where LISP throws me off is the excessive use of parenthesis

There's a standard way to indent lisp (the emacs way, which everybody copies) and as long as it's indented properly you read it like a whitespace significant language (Python, F#, etc).

Clojure is a bit easier to read than other lisps because it uses [] for vectors, arguments, and assignment blocks and {} for maps and sets. Gives the code a bit more texture.

People writing lisp day to day use an editor feature to automatically keep parens balanced (Paredit, Parinfer). Not required since there's a learning curve but it makes editing smoother if you're going to write lisp full time. A text editor that highlights the opening paren when the cursor is on the closing one (pretty common feature) is all you really need.

j_m_b2• 9 years ago

It also uses fewer parens than other lisps. Clojure let statement (let [foo "bar" baz "qux"] foo) => "bar" Scheme (let ((foo "bar") (baz "qux")) foo) "bar"

So in addition to additional symbols for notating vectors, map, etc, it uses fewer parens in general.

didip• 9 years ago

You just have to indent them the same way you'd indent curly braces.

The harder part about lisp is actually recursion. Surprisingly, there aren't a lot of programmers who can follow recursion naturally.

(loop exists in lisp but recursion seems to be the common idiom)

ZenoArrow• 9 years ago

"The harder part about lisp is actually recursion. Surprisingly, there aren't a lot of programmers who can follow recursion naturally."

All examples of recursion I've ever seen in Lisp follow a similar structure...

* First section checks if recursion is finished. If so, return final result (or final element of full result if returning a list).

* Second section performs an action or two on the inputs.

* Third section calls the function again with revised inputs.

In many ways it's just a do while loop with different syntax.

xfer• 9 years ago

Not true; loops exist (as a macro) because recursive functions(that naturally correspond to loops and iterations) are harder to read because they hide the logic of termination conditions. Fortunately we are using a powerful language, that lets us transform natural loop syntax to a recursive function.

Sharlin• 9 years ago

In my experience you rarely need recursion in Clojure, to the point that it's unidiomatic to use it. For 95% of your looping needs you use combinators, and for the rest there are the loop macros.

hellofunk21• 9 years ago

I would say nearly all my loops are either map or reduce. That's it.

keymone• 9 years ago

that was literally my story as well until i tried Clojure. i think convenient data literals is the top reason i could stick with it and properly learn a LISP. immutable to the core, nice concurrency primitives, trivial access to the whole java ecosystem - those are just cherries on top.

try using Atom with Parinfer plugin. i vehemently disagree with people trying to push emacs on Clojure/LISP newcomers. having to learn a possibly completely alien editor to be effective programming LISP is another big thing that pushes people away.

ACow_Adonis• 9 years ago

If you've done lisp for a while, you don't try to match the parentheses.

Firstly, you have an editor that matches them up for you.

Secondly, you read via indentation and whitespace. And since just about the only thing defining the syntax of lisps is the list structure, the editor also parses and can take care of that relatively automatically too.

I found it took about 6-12 months of exposure, and then your brain just tweaks/snaps/breaks magically one day, they all disappear, and then you no longer see them :P

blunte3• 9 years ago

Try once more. Pick a small project and just try and try again until you get it written.

Tip #1 - spend more time in the repl than in the editor. The repl lets you figure out and grok the small things.

Tip #2 - compose the small things into bigger things. (And if you find yourself composing too many semi-complex expressions into on big expression, feel free to take any smaller grouping of expressions and turn them into a function.

You may start out very disoriented; but if you keep trying, at some point after trying (perhaps for a few evenings, consistently) it will just suddenly click. It's a wonderful feeling to suddenly get it.

One last tip - Everything is really just this pattern: open paren, operator, some number of parameters/data, close paren. I'm not a Lisp teacher, so I may be stating this inaccurately, but it's just that simple. The pieces may look like more than what I just described, but they are really that simple.

And on the topic of "too many parens", compared to Javascript, C/C++, Java and many other languages, you'll find about the same number of them. They're just arranged differently (and more uniformly in Lisp). Better yet, because they're so uniform, you can completely ignore/forget about the end of big expressions with their )))). Ignore it. Use an editor that matches braces, (I like rainbow color matching).

And now, a warning. If you take the time to really learn Clojure, there's a good chance you'll love it. Then you will find that in most companies, you won't be able to use it unless you sneak it in. Then you'll end up in Elixir because it "looks like" Ruby, and because everyone bought into Rails. But you'll still wish you were using Clojure.

TeMPOraL5• 9 years ago

And on the topic of "too many parens", compared to Javascript, C/C++, Java and many other languages, you'll find about the same number of them.

Exactly. Even more, if you start counting {}, <> and []...

Also, before someone says "but prefix notation!", all mainstream languages are prefix too everywhere except math. That is,

  frob(barify(foo, bar))

is prefix notation, and equivalent Lisp is achieved by just shifting the opening paren to the left of the operator name (and dropping commas, thanks to the uniform syntax):

  (frob (barify foo bar))

cutler16• 9 years ago

Adoption of Elixir is no higher than Clojure. Slightly lower, I'd say. The bigger danger of loving Clojure is going back to working with OOP. Clojure can seriously damage your tolerance for OOP and in today's job market that's a real handicap.

nnq• 9 years ago

You're trolling.

You never "use your mind" to keep track of parentheses in any language - you use the editor's features for this, and read code structure by indentation like any sane human being does (also, it helps that I touch mostly Python ;) ...but for other languages you just configure your editor to reformat you code on every save or on linting). Everyone can get over "parenthesis madness" after configuring their editor properly and a few days of habit. Also, once you learn about "paredit mode" editing, if you like it, parens become a superpower, because you're not "typing code" anymore, you're just using your editor's shortcuts to edit the abstract syntax tree as a tree object that it rightfully is, not an ugly bucket of "code text"...

If you're sincerely not trolling, then Lispers will be glad you don't join in and come and soil their codebases with miss-indented or unnecessarily over-nested because of bad structure code...

swlkr• 9 years ago

You should try parinfer for your editor, that should help with the parens

maxpert2• 9 years ago

Downvotes for asking? :/

chrisoakman2• 9 years ago

I'm sorry your original question has been downvoted. I think it's a perfectly reasonable experience report and question. I replied here: https://news.ycombinator.com/item?id=15527041

yogthos21• 9 years ago

Clojure code actually ends up having less parens, and others symbols than most languages. Here's an example comparison with Java https://labs.ig.com/lines-of-code-matter

The only difference in readability is that the Java version has a lot more parentheses.

klibertp2• 9 years ago

I wrote a blog post on the issue: https://klibert.pl/posts/tools_for_lisp_syntax.html

I'm linking it because it has a couple of screenshots, which I think works better than just reading a description of how it should look like.

chrisoakman2• 9 years ago

Hi :)

I feel your pain here and just wanted to let you know how common this is for programmers who initially try out Lisp for the first time. As others have alluded to, I promise this initial "parenthesis shock" goes away rather quickly as you read and write Lisp code. In my direct experience, I have hired junior developers straight out of a coding bootcamp who were able to pick up ClojureScript in their first week using Sublime Text with no editor extensions. In other words: you can definitely do this; it's not magic.

I would strongly encourage you to check out Parinfer [1]. Parinfer makes indentation "significant" so you never have to worry about "closing the parens". Basically, if you can handle Python or CoffeeScript indentation, you can handle Lisp. There are no hotkeys to learn and it is available in most common editors today.

For a first project I would recommend rewriting something you have already written and are familiar with. That way you can focus on just the language and not worry about the problem domain or "how to solve it". Just do a 1-to-1 port of something you've already done and compare how the two solutions are the same or different.

I'm sorry you are being downvoted and being told to "just use emacs" or "use the REPL more". IMO, these are not helpful suggestions for someone new to the language.

Good luck. You won't regret learning Clojure. One of the best things I have ever done for my career.

[1] https://shaunlebron.github.io/parinfer/

cutler16• 9 years ago

An editor plugin which supports color-coded parens makes the parens problem disappear.

mmargerum5• 9 years ago

I read 2 books, watched a training video, and watched a Rich h. Video if I needed inspiration, but it didn’t completely click until I just wrote a small app in it. Just build a script in it to learn. Break your code up into defs and tiny functions to understand what you are trying to do and then put it all together into a function. The only parallel I have professionally is when I try to write very complex sql

lloeki• 9 years ago

Some languages are simple but they're also verbose. You've probably heard people say that verbosity really doesn't matter. These people will go to great length to point out that all languages are Turing complete and that in certain languages you simply have to write a bit more code.

This argument I usually dismiss by suggesting moving to INTERCAL or Brainfuck. Even syntax matters a lot more than people care to admit. The best language is the one with which you can frictionlessly reason about and express a problem without impediment from syntax, paradigms, concepts and boilerplate. Computer languages just as much as natural ones are deeply tied to the way we think[0].

[0] https://en.wikipedia.org/wiki/Linguistic_relativity#Programm...

yogthos21• 9 years ago

I agree, and that's one of many reasons I like Clojure so much. I find its syntax maps very cleanly to the way I think. It's one of the most readable languages I've worked with. It primarily has to do with Clojure syntax being simple and consistent.

nickbauman2• 9 years ago

When I have to write something computationally complex in the language my employer wants me to write it in, I first write it in Clojure because it's easier to think about the problem in that language. Then I translate that.

I'm willing to bet that any dev who has learned Clojure does the same thing. If I'm right, that's a huge indictment of what we've been doing for the last 60 years in programming.

aaron-lebo2• 9 years ago

You'd lose that bet. I think it's easier to reason about problems in languages you are familiar with and that fit how you think, which can change through continued use. A lot of the other stuff is just post hoc rationalization about why we like these languages and why they are better.

cutler16• 9 years ago

Surely the argument being made here is for the best prototyping language, not the most familiar. If familiarity was the only yardstick nothing beyond C would even exist.

nickbauman2• 9 years ago

The opposite of my experience. I have many more years of experience and am far more familiar with in the target language than Clojure. But for the really difficult computational problems, say, for example, particular performance analysis of a sensor network for a given time series, I reach for Clojure.

sametmax• 9 years ago

I haven't tried closure but I can believe so. I observe the same phenomenon with Python. Whatever I have to do is just easier to first express in Python then translate for me. I guess there are just some languages that are closer than others to the way we think.

It's quite probable that this language changes from dev to dev, depending of habits, type of problems and skills with said language. However I suspect some languages are just better at it by nature as well.

pron2• 9 years ago

I know Clojure and have used it for some projects, and I don't do that. If I need to sketch an algorithm, I'll do it in pseudocode, and if I need to test the design I do it in a verifiable pseudocode, like PlusCal. For sketching/testing numerical algorithms, I use Matlab/Julia.

sidlls• 9 years ago

Why does the language matter when reasoning about the problem?

It seems to me you're conflating "how to solve this problem" with "how to use a particular tool to implement a particular solution to a given problem."

tomerbd3• 9 years ago

I would love to use closure, i just stay away from dynamically typed languages - after having a bad experience trying to maintain projects written in a dynamically typed languages which was an awful experience. You see a parameter named user and you have no idea which type it is, which fields it has, does this user has a phone number? how can i know? You see functions and you don't have any idea what is the type they return. just to put things in perspective I maintained X100 larger projects in a statically typed languages, with even worse code but maintaining it was easier than these other projects. Simply because I knew what functions were getting in and what their return type was.

marvel_boy• 9 years ago

Which language?

tomerbd3• 9 years ago

mostly javascript, but I had a very similar experience in ruby and python. The main challenge was maintaining projects developed by other people.

vemv5• 9 years ago

Clojure has `defrecord`, so you can `defrecord User`.

Then you can assert that `user` is a User, with type hints, preconditions, 'spec' (a Clojure library), tests, docstrings, or some ad-hoc convention ("this kind of namespace does this kind of data transformation").

Then again, some Clojure users might prefer to use plain hashmaps (Rich tends to encourage this; or at least that's the common interpretation from his talks), and none of the mentioned mechanisms.

The mechanisms are there. Up to each to use them or not, depending on your scenario (and sincerely on one's competence too)

blain_the_train6• 9 years ago

I would encourage you take a look at the rational behind Clojure spec and Schema. Both allow you to specify the expected types of the arguments.

ngrilly8• 9 years ago

How is the spec checked, statically or dynamically?

pron2• 9 years ago

I generally agree with you, but Clojure is not at all like other dynamic languages (like, say, JS). For one, Clojure's dynamic dispatch is more like C++/Java's -- i.e., when you call a function, you can statically know either the precise target or an explicitly designated set of possible targets. Second, Clojure allows you to specify the types of arguments (and much more, in fact), not with a type system, but with a specification system. It's not exactly the same, but it can be more/less powerful than types, depending on usage.

ngrilly8• 9 years ago

How is the specification checked, statically or dynamically?

jgalt2122• 9 years ago

Python dev here who chooses his own tools. I want to move to Clojure, but Clojure and the JVM just aren't that strong in machine learning and ML is my current "growth" area.

Even with JVM based solutions, such as Stanford CoreNLP Python has more support/interest than Clojure.

I am not here to pump up Python and knock Clojure, just to illustrate there are areas that Clojure has a ton more wood to chop. And I do understand there have been significant efforts made in this arena lately. e.g. Neanderthal

http://neanderthal.uncomplicate.org/

falcolas• 9 years ago

Having worked with both Lisp and Python, I feel relatively comfortable saying the only thing missing from Python is macros; and when it comes to readable code, it's not a debilitating loss. Much of a macro's capability to create DSLs can be replicated using the introspection and metaprogramming.

There are also some lisps that target the Python VM, so you could consider using one of those.

cutler16• 9 years ago

Yes, Hy (http://hylang.org) is similar to Clojure and very nice to work with. Sadly, they had to abandon their implementation of let recently.

devmunchies2• 9 years ago

I am not here to pump up Python and knock Clojure, just to illustrate there are areas that Clojure has a ton more wood to chop

If you are talking about ML, then basically every language has "wood to chop" when compared to python.

jgalt2122• 9 years ago

probably not R, though.

yogthos21• 9 years ago

Take a look at Cortext https://github.com/thinktopic/cortex

There's a recent presentation that makes a good case for using Clojure over Python for ML https://www.youtube.com/watch?v=0m6wz2vClQI

thediff• 9 years ago

I liked this quote.

"What matters to me in a language is whether I can use it without thinking about it."

preordained2• 9 years ago

I've really taken a shine to Clojure. Parentheses and dynamic typing initially kept me away, but they're far from the thorns they've been made out to be.

Parentheses? You don't even see them after a short while--as a beginner, you use something like parinfer, you are good to go. That, and like all lisps, you begin to appreciate programming directly in the abstract syntax tree: the language you type and the way it is interpreted aren't disjoint things.

Dynamic typing? Being functional, immutable by default, and data orientated steal the vast majority of the sting from that in my opinion--and leave you with often downplayed advantages. On the last point, "data oriented", to put it succinctly, data itself is first class or the prominent currency among Clojurists, rather than a zoo of abstractions that never quite fit and and all have to be reconciled and made to play with one another (and often the reason you need types everywhere to keep it all straight).

But where types--or validation--are more crucial near the boundaries of the API, there are outside the box solutions like Spec that don't rely on a baked in type system.

The recent keynote by Rich Hickey covers a lot of these points (and far better than me):

https://m.youtube.com/watch?v=2V1FtfBDsLU

jasim3• 9 years ago

If you have used a statically typed language in the ML family (OCaml, Haskell etc.), could you contrast the development experience between the two?

preordained2• 9 years ago

I spent a good year or so with Haskell. I guess at first blush, one thing that jumped out was that Clojure was made from the jump with a focus on productivity and pragmatism, whereas you never feel too far from the academic origins of Haskell. Clojure is a very shrewdly designed--it's not proud, it takes leverage where it can find it, and makes some very deliberate and sensible trade offs. A large aspect of that is the JVM it sits atop of. You will know that it's Java underneath the hood, but this is not a bad thing at all. You get to have your cake and eat it too. It's done really well in the sense that while it would be awkward and not Clojure-like to promiscuously call native Java--especially code with side-effects--it it is perfectly alright, and practical, to pull in any of the multitude of proven Java libraries where it can obviously save you time and effort. There is no snobbery in the core language itself or in the community about "ew, icky Java". Or put another way, there is no from-scratch ecosystem like in so many languages where a new language means starting over (so the language needs a crypto library, and a web server, and...) Not to mention, many of the utility libraries out there are largely functional in nature anyhow (you can use a massive chunk of the wealth that is Apache Commons as just an arsenal of pure functions).

In nitty gritty terms, programming in Clojure actually feels a lot like programming in Haskell to me, without the heavy type system. Lazy infinite lists, all your FP classics like map, reduce, filter, etc. work exactly like you would expect. But I don't miss having to create a stack of monad transformers in an area of code where I need to mix IO and state or something...and using type synonyms to mask the monstrous Turing-complete type signatures I had to make to describe it... In Clojure, you just put the "dirty" work in its own function, clearly separated from the pure functions (which are the de facto default), and you push them to the boundaries of the system while passing extracted data into pure functions (just like Haskell). If you did anything different, you'd get the stink eye from even the least principled Clojurists. It's just not done. A ball and chain type system is unnecessary.

The lack of (explicit) types has been at the very most a minor nuisance. Occasionally I mistype something or miss a parameter, you're going to see the error pretty quickly in the REPL. If you run or test your code at all, the pedestrian type errors (oh, that was a string not an int) will be wrung out immediately. That benefit of type systems (preventing typos, essentially) has been much, much overstated IMO. Given you're going to be in the REPL a lot with Clojure, you'll be iteratatively developing and running your code constantly, so it's really not an issue. As far as refactoring, I think that's where there is more meaningful benefit. I use Intellij/Cursive IDE, and the refactoring capabilities are good--much like if it were a Java project (and there are hints and such for the typos I mentioned earlier, autocomplete, etc). So, while it is more of a challenge for IDEs, there are some excellent ones that do a pretty bang up job of inferring types for you.

I haven't used Clojure on the job (Java dev by day), but I would have no problem using it for something "real", whereas I never felt anywhere near confident in using Haskell for something outside my own fiddling.

devmunchies2• 9 years ago

Is this the same author as this book or is there plagiarism going on: https://www.amazon.com/Web-Development-Clojure-Build-Bulletp...

Go down to the "From the Publisher" section and you'll see:

"But the practical question is how well the language maps to the problem to be solved. Does the language let you think in terms of your problem domain, or do you have to keep translating domain concepts in the constructs of the language? The best case is when you can use the language without thinking about it."

handojin• 9 years ago

Same author.

erichmond3• 9 years ago

I've been debating whether or not to give a talk / write a blog post on this, but I think this might just be the kind of thing that people make their assumptions about, and thats it.

I do wish people would give clojure a real go, not just running a toy program, but taking the time to setup a REPL in clojure and clojurescript, learn about sending commands from the editor directly into the REPL, etc.

The reasons for choosing clojure are un-obvious at first glance. Moving from Java -> Ruby for example is something that you feel immediately. People understand in < 5 mins why ruby might be a better fit for a number of solutions then Java.

I don't dig clojure because it's a LISP, or it's homoiconic, or because of most of the academic ideas here in this thread. I picked clojure because with it, I get clojure and clojurescript.

With clojure I get to target all java libraries, great concurrency primitives, the ability to live code a running system, the ability to experiment extremely quickly due to the REPL based workflow, now with spec/generative testing, I get better testing then I had before, with writing fewer tests. I get systems are often easier to reason about or debug. There's rarely a ton of libraries to do a single thing. Existing libraries don't change much. We launched our first service in clojure 1.6, we've never had to do anything but bump the version number. No breakage.

With clojurescript we get just as many benefits. CLJS gives us access to all javascript libraries that have been written, Re-Frame/Om Next are incredible frameworks on top of react, figwheel allows us to never (rarely actually) have to refresh a page when doing layout / css things. Because we have access to a running REPL we can change the state of the app via function, allowing for way rigamarole when trying to test out inputs, etc. devcards lets you look at all the state of your widgets on the page + figwheel means you can see how CSS changes will affect all the states of your widget at once.

Synchronicity between the two languages allows us to write .cljc files where share functions and schemas can exist, so your backend and front end are pointing to the same place for critical things that should be shared.

It's really really different, but it's really really great. If you're a professional in the field, you owe it to yourself to just try it out and see if it helps you save time and be more productive.

erichmond3• 9 years ago

All that said, it's not perfect and there are annoying things about it, so I'm not painting it as a perfect language. And there are problems that it's probably not well suited to solve.

I discovered clojure about 25 years into my programming career, and while it introduced new "annoying things", it resolved most of the annoying things I had dealt with over the past 25 years in most other languages.

tombert• 9 years ago

I love Haskell for its type system, but I gotta say that I feel I accomplish about 10x as much with Clojure than I do with it. Being able to quickly beam over my code from Vim to the REPL, and seeing my changes happen in real-time is so incredibly valuable, and I personally feel that Clojure's concurrency is a lot easier to grok than Haskell's.

I also feel that Clojure's tooling is a lot nicer than most languages, and especially Haskell; Leiningen is very easy to use and Fireplace is a really simple and nice plugin for Vim.

cutler16• 9 years ago

The sad fact of life is that large corporations often dictate the platform. If you're a mobile app developer, for example, you're only native options are Swift, Java and Kotlin unless you're prepared to settle for a less efficient end product (Xamarin, Scala/Android, Clojure/Android).

city41• 9 years ago

Job trends play a role too. I really like Clojure and would like to keep using it. But it's less likely to help get me a job than say learning Python.

vemv5• 9 years ago

I also feel this pain. The reward is high though (salary, remote, colleagues) so I remain motivated.

One also can help creating job market by

- starting up

- introducing Clojure at work

- evangelizing it at local meetups (e.g. hijack a JS meetup, explaining cljs goodness)

I've been thinking about the latter, as a consultant creating a 'need' for your services would be quite an accomplishment.

vemv5• 9 years ago

There's some real niche to Clojurescript + React Native; one might even outperform a plain React Native app

yogthos21• 9 years ago

I work in corporate environment, and it's absolutely possible to use Clojure there. It's going to be harder to get buy in than in a small company or a startup, but not impossible.

muxator• 9 years ago

I have no lisp experience, but I want to ask to who knows more: isn't the use of too many macros a potential hinder to maintainability? What happens to a project when it becomes a mini-language in itself, with its conventions, it's opinions, it's specific flavour? Does this help or discourage the onboarding of new developers?

I know C is not a good example, bit at least in C projects, I was always wary of "smart" developers inventing their own "smart" conventions and syntaxes

kazinator2• 9 years ago

Macro use scenarios have to be weighed against the alternative: writing by hand the logic that the machine would have generated from macro invocations.

Why I'm Productive in Clojure (2013)

Related Stories