A very even-handed, honest and accurate evaluation of Clojure, at least from my somewhat limited perspective. I've written a couple of small/trivial programs in Clojure and read a couple of the books ("Joy of" and "Practical"), so I'm far from an expert.
I will say that the online documentation IS atrocious and basically impenetrable, and usable code samples are quite difficult to come by. That being said, it's a very young language, with a very active, helpful and -- dare I say -- friendly IRC channel. (And by the way, a couple of top-notch eval bots)
The documentation piece is easily overcome by spending $20 on an ebook. Joy of Clj and Practical Clj are both very readable & accessible. The code samples are clear and concise, and the explanatory prose is excellent.
IDE support... well, I use emacs. It's widely recommended people use emacs for Clojure simply because it is so well integrated with it. REPL and line evaluation are fantastic in emacs. People who don't like/want emacs tend to use vim's Clojure mode, at least according to IRC.
I will say that the main pain point I had in getting started with Clojure was building the environment. The "best practices" for a Clojure environment has shifted wildly, as far as I can tell, over the past few years, so most/many of the blog posts that describe how to get it set up are wrong, or very dated and unsupported by current software (e.g. Leiningen).
All in all if you are interested in learning Clojure, you are doing yourself an enormous disservice by not joining #clojure and asking your questions there.
Your comments about the build system do bring up a good point. Perhaps leiningen or cake should be adopted as a default build tool and integrated into the main code base and website.
I admit that the complaints about the lack of examples in the documentation does confuse me a bit. The documentation sites for C and C++ don't seem to include examples either. For me, tutorials and books were always the go to places for examples. I will agree whole heartedly that some of the 3rd party libraries like ring/compojure need some serious documentation improvement, in particular since the architecture of these libraries is fairly complicated.
Could someone link examples of good documentation they like from other languages to help clarify?
C and C++? Dude, there's a whole generation of programmers -- paid, successful, professional, prolific programmers -- who have never even looked at C or C++. Or, if they did, it was for a couple of classes and haven't touched it since.
Making C/C++ documentation the standard for documentation is like making a Chevy Nova the standard for features in modern automobiles.
About the IDE: I've tried using Emacs, and I've actually managed to do it for a good while, but when I finally discovered Eclipse's Clojure plugin, it was as if big chunks of iron were removed from my hands. Emacs is simply not for everybody. Eclipse's Counterclockwise (the Clojure plugin) may not be as rich in features, but it's easy as pie to install and start using.
I will say that the online documentation IS atrocious and basically impenetrable...
Maybe it's just me, but I find the documentation to be very good. Everything on clojure.org is relevant, clear and concise. I read two books too, but I learned the most from clojure.org.
thanks. which of those books goes furthest? (i imagine i can work out the basic stuff, so it seems best to choose whichever includes the most obscure/advanced features - and i'd like to save time by reading just one...).
i do use emacs for text editing, so i'll try it for clojure (i should say that there was only one wrinkle in getting the environment working in intellij - that was adding clojure.jar to the classpath, which it told me to do in an error popup, so it wasn't hard at all).
Yes Joy of Clojure does go deeper, but in my opinion Practical Clojure has, well, more practical examples. Both are great, and overlap in many areas. But for code examples, Practical Clojure over Joy.
The second part of the article, titled "Why I tried Clojure then stopped" shows a very shallow understanding of the language. His point is that Clojure heavily uses vectors which aren't efficient when the collection changes size frequently. Clojure does in fact heavily use vector literals in code, but those aren't large enough for their performance characteristics to matter under most circumstances. The use of vectors over lists is to differentiate things that get executed from things that don't; lists are code and vectors are data.
I ran some tests with a function that did nothing but recur/drop on a sequence. There was no speed difference between a vector, a LazySeq (previously evaluated), a PersistentVector and a PersistentList with a million elements. I tried it with ten million and it was 400 times slower with both a LazySeq and a PersistentVector. Attempting to make a PersistentList from the 10M element LazySeq with 'into' resulted in running out of heap space. I did not try again with more heap space allocated.
I disagree with the author about how it suffers from being on the JVM. In fact, I'm not quite sure the author even knows what the full scope of that sentiment means. I believe it is quite the contrary. With respect to the JVM not getting any better, it just did. "invokedynamic" was introduced with the latest release of JDK7 and is directly related to the support of dynamic language such as Clojure and JRuby. Using the JVM opens a bunch of doors for a burgeoning language that normally it would have to re-invent. In this case, because it is on the JVM it doesn't have to re-invent the wheel it can re-use existing and proven libraries, performance and monitoring tools, etc.
I will conceded that documentation can be spotty, but it isn't any worse than most new languages, and it is continually getting better. Furthermore, if you really want to give issue such strong opinions about a language you ought to spend mor time with it than just a day or 2.
IMHO your writeup is shallow and not well conceived.
Indeed, Clojure's excellent Java interop gives me easy access to existing Java libraries. And because it runs on the JVM, I've been able to execute Clojure apps under z/OS (you know, the day job).
I'd call Clojure's use of the JVM a win, not a liability.
given how stalled the JCP seems to be (the disappointment with 7 and the general sentiment against oracle) i can't see TCO ever being fixed and i wonder how much tolerance there will be for third party expansion (without lawsuits or licencing). i agree that invokedynamic is going to help, but even there you can argue that it took a long time in coming (when did davinci appear? 2008? three long years....)
but i agree it's not a "deep" analysis. did you miss the part where i said i had only used the language for a day? or the word "initial" in the title?
[edit:] actually, there is one more thing i want to say. one thing that has discouraged me from looking at clojure earlier is the agressiveness i've seen from the language's fanboys. fwiw.
I'm looking at both Scala and Clojure right now. I'm a .Net guy these days, looked hard at (and fell partially in love with) F#, but - I need to broaden my field.
And - I'd like to see if I can (ab)use those languages to improve my experiences with Android.
So far I'm heavily leaning towards Scala. The documentation seems to make more sense to me. It seems powerful to ~no end~. This post now, while being not totally impressed about all things Clojure, ends with an unqualified 'still more usable than Scala', which threw me off.
More data points, please? If the writer is true and makes sense: What's the reason for this comment? Convert me. :)
The difference between Scala and Clojure, in my opinion, is primarily one of philosophy.
* Clojure is strongly and dynamically typed. Scala has a complex type system, which from what I understand many Scala developers don't fully understand or utilize it. Clojure doesn't suffer much in performance, however, because you can sprinkle in type hints for performance after the fact wherever it turns out to be necessary.
* Clojure is a Lisp. The benefits of that are a whole other discussion, but homoiconicity and macros are undoubtedly pretty cool.
* Scala is multi-paradigm, Clojure is unabashedly single-paradigm.
* Scala includes the kitchen sink, Clojure is highly opinionated about what it provides. As Brian Hurt says, "It's not what a programming language makes possible, it's what it makes easy." For one example, you can do immutability in Scala, but you're also free to go in and make a hairball of state if you want. Clojure has decided immutability is good, and forces you to manage state in a controlled way.
Full disclosure: I'm a huge Clojure fan and author of Practical Clojure, and haven't used Scala on any nontrivial projects, so I'm probably somewhat biased.
Well, if your interest is to release on Android in the immediate future, you may be best served by sticking to Scala. Clojure code needs to bootstrap itself at start-up which creates a bit of a load delay on the initialisation of your app. If you want to just throw up a splash screen and not worry too much about the load time, Clojure may work out fine.
At this point, I have written significant amounts of code in both languages, and I honestly prefer Clojure. Scala is definitely a big step up from Java, and there is a lot to like in the language. Nonetheless, I think that Clojure is a step up from Scala.
There have been a number of times when writing in Scala that I wish I had some of the features of Clojure, macros in particular. Scala provides many neat features that would be implemented as macros in Clojure, but there are some things that can be done as macros that cannot be done in Scala.
Of course, typing is a big issue. I'll have to admit that when writing client code static typing is very nice, but when writing library code dynamic typing makes things easier. Most importantly, Scala suffers from some of the typing problems that are part of the JVM, most notably: type erasure in generics. Scala provides some means to reify generic types, but it is still a pain to work with. I think that Clojure also contains superior polymorphic dispatch capabilities.
In the end, they are both fine languages. I enjoy coding in Scala and Clojure more than C++ or Java. Still, if I have the choice between the two, I'd go for Clojure.
I found that comment strage. Scala is quite usable once you start actually, well, using it. If you just read through the docs it can be intimidating but if you start using it as a "better Java" and then start biting off the more sophisticated features it's not hard to get going at all. Having tried both Clojure and Scala there's no way I'd throw away the benefits of static typing in a good, modern FP.
uff, it's controversial territory... scala is certainly closer to f# than clojure. that could be good - easier to learn - or bad - you learn less (i would strongly encourage learning one lisp, and working through "on lisp" to grok macros, if you haven't done so yet). my problem with scala is that i found it too complicated. i was really frustrated and disappointed with it, and that was exacerbated by my hope that it was the future (i thought it would be haskell for java programmers - and it is, in a way, but it achieves it through brute force rather than elegance, imho). but that was just me, and some time ago (when the language was changing more rapidly) - it may be better now, or for others...
Mostly true. Initially, I got The Joy of Clojure, which is really good and helped me bootstrap my learning process. Now, if I need to know something, I look up the source. This process seems to work well.
The only problem with this strategy is that sometimes I'll not know of a better way to solve a problem (for example, I only discovered update-in a few days ago. Don't ask what I've been doing before that.)
The best way to solve this problem is by pair programming with someone else who knows Clojure. Failing that, you can hop on IRC; people there are super helpful and willing to write big code samples just to make sure you get it. And be sure to read a lot of source code to pick up common idioms, etc.
> Error messages are unhelpful.
This is true, but here's a quick tip: if you just look for errors that come from your-namespace.core (or whatever) then you can rapidly ignore about 99% of the extraneous junk that pops up.
Unfortunately, there's always that 1/10 chance that your error has no line number. Not much you can do about that, except guess where the reported error is coming frm, and hope for more progress in clojure in clojure :/
> IDE support
Use emacs with swank clojure. Just do it. It's amazing, and you won't look back. I'm saying this as a hardcore vim user with visual mode tattooed on his back. (I have to use viper-mode and vimpulse - which makes emacs pretty much just the same as vim.)
> It suffers from using the JVM
I really don't understand this point. I believe JVM integration is a win all around. It allows for speed without much effort, and it gives access to a huge wealth of libraries without need for a community to build them.
Some closing remarks:
You've got to remember that Clojure is only 3 or 4 years old. If you're (subconsciously or not) comparing it to languages with 10 or 20 years of history, the older languages will always dominate in terms of documentation, support, etc. This is unfortunate for new languages, but also exciting, because it means that even beginners like me and you can pick off low hanging fruit and make important contributions.
Good post. I haven't used clojure yet, or any purely functional or lispy languages, but I'm keen to try. I'm especially interested in macros and dsls, as I feel like I'm always trying to bend ruby and python into structures that seem, from the little I know of lisp, like they really want to use lisp macros, and the more experience I get, the more I feel like that sort of metaprogramming is where the real power is. That said, I'm also wary of trading the comfy, curated library ecosystems of rb/py land for what looks from the outside like the overgrown jungle of Java.
I think I've narrowed my next learning project down to either clojure or node. Node seems perhaps more immediately useful and easier to grok, while clojure may offer more for my overall development as a programmer. I'm not the type to build a throwaway educational app--I have to feel like whatever I'm working on could turn into something real, even if it's unlikely, so if I were to go with clojure, I'd want it to be for its potential to really offer more power and productivity in making something cool and getting it launched, not just as an academic exercise. I have a couple busy months of contract work to go before I'll be able to dive into anything, so it's great to read reports like this while the decision stews.
If you're looking for Lisp-like meta-programming, I'm pretty sure you don't want Node. It may be easier to grok, but that's because it's much closer to Ruby and Python than it is to lisp. The interesting thing about Node is its event-driven structure.
For that matter, you might not want Clojure to be your first lisp experience. Have you considered Racket, the scheme dialect? It seems to have lots of useful libraries, in addition to being, I don't know if "cleaner" is the right word, but something like that. A bit more traditional, maybe simpler.
I don't have that much experience with lisp or Node. If someone with more experience can correct my impressions, I would be grateful.
As someone who's used Common Lisp, Scheme and Clojure; out of that bunch I would highly recommend Clojure for a beginner.
Pros:
1. Easier to setup
(with a single script from https://github.com/technomancy/leiningen)
2. Benefits of a lisp-1, with nicer syntax (fewer confusing parens)
3. Easier to get started with Emacs + swank-clojure + lein
4. Wealth of Java libraries
5. Functional
Cons:
1. Can't think of any, unless you want Interface Builder and similar, or are desperate to program using call/cc or are in any of the above ways a non-beginner. drscheme is a nice counterpoint though, in that the learning enviroment could include a bit more hand-holding.
IMHO for those coming from ruby/python etc. Clojure is a huge win. With square brackets for function-args, if you turn off or dim parens (emacs has several options such as rainbow-parens) the source looks very much like python.
And with M-q and friends and sexp editing, it behaves better.
Please forgive my bluntness: this is not a method of evaluating anything.
The entries have been made every few hours. The author started to have some hopes about Clojure, then in the same day (heck! in three hours) he resigned.
Even geniuses need some time to digest information. The best way to do it is to think hard during a day, relax and let the brain work on it during sleep. You're lucky if some insight comes just another day. But it will come eventually.
I'm telling this not in the defense of Closure, but in the defense of a proper method of examining the world around.
And if you like modern Lisps, you can always check Racket. (But slowly :)
Intellij's La Clojure does a little more than syntax highlight: minimal refactoring support, rainbow parenthesis, smart parenthesis, syntax highlighted repl, great autocomplete support, awesome code navigation, autocomplete for java classes and live templates.
Not to mention that slurp forwards (Edit->Clojure->Slurp Forwards) is really nice. Example. Place your carret on |
1. While the complaints about error stack traces and documentation are valid, I would personally use a language for a month or two before publicly publicly criticizing it.
2. If you want to learn Clojure and/or Scala, I think that it is worth taking an initial detour and learn a little Haskell. Every time I spend a few evenings studying Haskell I feel like I understand Clojure and Scala a bit better.
3. I think that tool support is very good. I must admit mostly using IntelliJ with the Clojure plugin, but I also use Emacs+Slime for several hours a week.
4. There are many awesome projects and frameworks written in Clojure - to me this is the clearest indication that Clojure is an important language and deserves careful consideration for new projects.
I used Clojure for 2.5 years. Here are my thoughts.
TL;DR: it's an excellent language, but it's dynamically-typed and that can be a pain.
The language itself is pretty simple. The default collection type is a lazy seq, and that takes a little bit of getting used to, but it's actually a great thing. It allows you to compose filters, maps, et al without taking a hit to performance on account of needless copying.
The language's documentation is mediocre, true, but that doesn't matter that much given that learning a new language is a 6-month (at least) investment. Trust me: if you've never used a functional programming language before, it's more than worth your time.
Some of the error messages are useless, mainly because of Java hangover. Clojure is a very pretty and powerful language built on top of an incredibly ugly one. Impedance mismatches are hardly surprising. Again, this is something that takes a few months to get a hang of, but once you've got a handle on it, it isn't so bad. Clojure is amenable to tracing/printf style debugging, which isn't so bad if you structure your code in an intelligent way. Since the language is mostly functional, the path of least resistance usually is intelligent structuring.
Clojure is a great choice if you're disciplined and willing to do, if not full-on TDD, development with a lot of testing involved. You have to unit test; fast-and-sloppy development will cripple you. It's dynamically typed, and I'll probably always prefer static, but if we accept that the static-vs.-dynamic debate remains unresolved (a lot of smart people with great arguments on both sides) I'd have to give it very high marks within the dynamic category. My ideal language would still be a statically-typed one, but Clojure is more than good enough in practice.
It seems to be increasingly popular to denote some notes with trivial contents as a 'paper'. A paper is something that is published in a peer-reviewed journal.
It would, by the way, be nice to get rid of some of all those self-promoting posts. New rule: You can not link to your own shit. Thank you, Sir.
It's generally held that linking to your own posts is ok as long as it's relevant to HN (and I don't see any argument that this isn't). I mean, who cares who submitted it if it's relevant?
I will say that the online documentation IS atrocious and basically impenetrable, and usable code samples are quite difficult to come by. That being said, it's a very young language, with a very active, helpful and -- dare I say -- friendly IRC channel. (And by the way, a couple of top-notch eval bots)
The documentation piece is easily overcome by spending $20 on an ebook. Joy of Clj and Practical Clj are both very readable & accessible. The code samples are clear and concise, and the explanatory prose is excellent.
IDE support... well, I use emacs. It's widely recommended people use emacs for Clojure simply because it is so well integrated with it. REPL and line evaluation are fantastic in emacs. People who don't like/want emacs tend to use vim's Clojure mode, at least according to IRC.
I will say that the main pain point I had in getting started with Clojure was building the environment. The "best practices" for a Clojure environment has shifted wildly, as far as I can tell, over the past few years, so most/many of the blog posts that describe how to get it set up are wrong, or very dated and unsupported by current software (e.g. Leiningen).
All in all if you are interested in learning Clojure, you are doing yourself an enormous disservice by not joining #clojure and asking your questions there.