Clojure is a great language that has an achilles heel right now. The community doesn't treat the lack of learning resources / documentation as a serious problem. I've heard prominent members of the community say this exactly, "Clojure is such a great language that the lack of learning resources doesn't constitute a real problem in the grand scheme of things." I know what they're trying to communicate, but to beginners it comes off like "We've created the greatest thing since sliced bread - but we're not going to tell you how to use it - and if you would just take our word for it and blindly follow with no guidance you'll be a better developer". Which is really frustrating to hear, because it's like this thing seems so great, and smart people are all about it, but the only way to learn it is absolute misery. It's a tough perspective to have when you're only a couple years in to your dev career.
Clojure gives you massive benefits, but god it's a brutal road to competence. Things that should be simple like setting up a web server, adding user authentication, making JSON API's, trying to find the best libraries, it's all a time-consuming trudge through pain and suffering. And after some months when you get somewhat competent with the language, you realize that in order to get the full power of Clojure you need to not only learn the Clojure language, but the entire Clojure ecosystem. So you need Clojure, Clojurescript, Datomic, Edn, Core.async etc... And each piece of that puzzle is equally horribly documented and has no beginner resources so you have to struggle at each point in the process, praying to god that it's ultimately worth it.
It's frustrating as hell, but it really is rewarding, because you have to learn every little piece at a low-level to ever make anything happen. There's no Rails-like framework that makes things 'just-work' waiting for you. I find that using Clojure is awesome, but learning Clojure is awful. I'm hoping to play a role in fixing that second part pretty soon, but really wish the community would be more active in helping to remedy the problem. The first step is admitting that the problem exists and it matters, and not sure that we're there yet.
[context: I work at Cognitect on Clojure and community efforts]
I'll start by saying that documentation, examples, getting started, etc could be better and efforts are ongoing to improve all of those to various degrees.
In the web area, the philosophy is different than other languages and it is evolving rapidly (especially on the client side). Luminus (http://www.luminusweb.net/) is a good effort to provide a reasonable set of defaults that tie together the various Clojure web libraries.
So yes, it could be better. However, there are significant resources now and gaps continue to be filled.
One thing I've always found bizarre is that ClojureDocs hasn't been updated since 1.3. I know it isn't an official resource so you may not be able to do anything about it, but it's always at the top of Google's results.
I had the opposite experience. It's pretty obvious how to do anything in Clojure. I don't need to hunt down magical incantations to use libraries like I had to in Ruby.
I started Clojure for web development. Once I found out about the Compojure template, everything else was just a stone's throw away.
$ lein new compojure myapp
$ cd myapp
$ lein ring server-headless
Server started on port 3000
I wager the average HN reader could run with that.
> There's no Rails-like framework that makes things
> 'just-work' waiting for you.
That's actually what stifles the productivity of Rails projects I've worked on. It's why I started looking at other solutions and why the simplicity of Clojure pulled me over.
rails g devise:install
rails g devise user
rails g devise:views
Nobody really knows what just happened. Things kinda work til the answers to your questions can't be pasted from Devise's wiki anymore.
> because you have to learn every little piece at a low-level to
> ever make anything happen.
Maybe we have different things in mind, here. The alternative to this in my experience is an application where nobody actually knows, for example, what's being put into the cookie, when it's put into the cookie, what part of the session is serialized in the DB, if the cookie is signed, etc.
At least that's how it was at all the Rails projects I worked on.
https://github.com/ring-clojure/ring/wiki was refreshing. It turns out that managing your own session/cookie/authentication lifecycle in your own application code is easy. And it turns out that these "it just works" generators doesn't actually save any time because when you want to make trivial changes to them, you have to credentialize in yet another abstraction.
I haven't found that true, especially compared to any other language at this stage of development (complicated by the lack of the modern Internet, but I'm thinking especially about C++).
E.g. I'm helping someone with a web application and I've found no need whatsoever for Datomic (PostgreSQL + korma is just fine), I gather that means Edn is irrelevant, Core.async appears to be less than a year old, so I'm not surprised it might be lacking in documentation, and I don't see it as critical for a lot of applications, including mine. Clojurescript: we'll see, I do engines, and would prefer to continue to have others do almost all of that side of things.
Granted, it did take me a while to find and get up to speed on a set of libraries to do the web app I'm working on (mostly CRUD with some non-real time backend external communications), but it's been relatively pain free. I started with a recommended set, then as I found I needed to do something new, like JSON, I found a good library in a few minutes with Google and didn't find it at all difficult to fold it in.
Did change after a bit my form validation library to Red Tape, which modulo one detail (limited data available to form level cleaners (functions that act on more than one item in the form)) is superb.
And "superb" in general describes my experience doing all this. And I fully expect documentation and other learning resources to continue to improve as Clojure gets greater acceptance.
(Disclaimer: I'm an old Lisp and Scheme hand, e.g. not someone who had to learn anything conceptually new to use loop and recur. I could see the above plus learning basic functional Lisp concepts to be brutal if you're new to everything.
On the other hand, I can remember the days when learning MACLisp required reading an old David Moon manual and then the archives of a mailing list following it's publication; thank goodness there was a really great Lisp Machine Lisp manual and they were just starting to be somewhat available to use and learn on.)
I attended the Clojure/West conference about 3 weeks ago, and the sentiments are valid. But also, the Clojure community is starting to focus on the beginner learning curve aspects. Right now, there's a ClojureBridge effort (based on RailsBridge) to increase the diversity in the community. And it's been generating interest among people even outside the under-represented demographics. I'll be co-teaching the ClojureBridge SF session in 3 weeks, ping me if you're interested in future Clojure workshops (given the huge amount of interest, there definitely will be more!).
I think there's going to be some efforts in the near future in the Clojure community to tackle the low-hanging fruit of improving beginners' path to mastery.
If you come from OOP school of programming and the Algol/C++/Java style of syntax (true of many popular languages these days), then Clojure does require a re-think of the programming paradigm. But it truly is worth it -- it will make you a better programmer -- and the community is friendly, smart, and always learning and improving. It's certainly a language that I think that I will grow as a programmer by being with.
I think you might be overstating the syntax switching problems. The syntax of earlier Lisps is insanely simple, and Clojure only a little more so.
I base this in part on the very popular Python language's use of white space, which to a seasoned Lisper looks very familiar.
As for the focus on "diversity", I submit it might be misplaced at the moment, especially to the extent AlwaysBCoding's complaints are valid. To the extent Clojure is not making the sale to a target audience that's already
98%" heteronormative eeeevil white male (https://news.ycombinator.com/item?id=7581226), how likely are you to entice those outside that demographic? In fact, if you view Clojure as an experiment that may fail, are you doing them a favor by evangelizing it to them?
(I'd argue yes, since it's probably one of the easiest functional programming (FP) languages to learn, and it really helps to have FP in your toolkit. But I'd argue SICP or something gentler with multipardigm Scheme would be a better approach if you're just trying to accomplish that sort of thing.)
The first two ClojureBridge (http://clojurebridge.org) workshops sold out quickly and many more cities are working on events in the coming months. In addition, 100s of people have signed up to help or attend on the mailing list. There is clearly demand in diverse communities to learn programming via Clojure.
I don't think any serious student should expect to learn only one language. Clojure can teach concepts that any learner will find valuable in applying to other languages. In particular, I think that clear separation of values, identity, and state avoids many kinds of complication in learning how to program that are introduced early with other languages.
I am definitely not the best developer you will ever find, however I learn clojure by myself and it wasn't so hard...
(This is exactly the behaviour you are point as wrong, and I know it.)
The resource I had (back in the 2011/2012) were just a book, `The joy of Clojure`, my background was some C and mostly python, nothing about FP.
I don't see any of ClojureScript, Edn (???) nor core.whatever so fundamental...
Those are just other tools, you can write any webserver using the old JS, JSON and any other lib you may need...
(Anyway you should not try to learn clojure building web server, are the less clojure-y piece of software you can build IMHO)
IMHO, the biggest problem is the paradigm shift that most developer need to have in order of learn clojure.
Indeed. Learning functional programming in any language is a major jump for those of us (pretty much all of us?) who started out with imperative languages. It's ultimately very rewarding, but plenty of work in addition to mind stretching.
Then again you probably should have listened to all those people telling you to do The Structure and Interpretation of Computer Programs (SICP/6.001) ^_^, I merely lucked out to be at the edge of the community that created it, so it sort of fell into my lap, with strong recommendations that "this is revealed truth" as I like to put it.
To give but one example, if you're having any trouble with loop/recur, do the exercises on recursive functions that implement iteration without stack growth through tail recursion (the latter a feature that's unfortunately not available in the JVM; the flip side is that recur isn't going to blow your stack).
In the last couple of weeks I had to write a bunch of those in Clojure for the first time "in anger" (for real), and that part of it was trivial because of the SCIP I'd done in the early '80s. Learning that and pounding in my head for the first time was a bit hard, but well worth it, back then and of course now.
I am the developer of HiveMind (crudzilla.com), it is a web app platform which supports Clojure...it does have a middleware which is language independent, meaning you can use Clojure for your logic and tap into the middle-ware for things like DB interaction, email and JSON based application configuration...etc
Let me make a suggestion - the next person you convince to start working with clojure ... hold their hand through the process and make notes of everything you had to tell them about (because they couldn't find it in the docs) ... then at the very least publish those notes.
One of the big problems is that it's -really- hard to go back and explain this stuff once you're already an expert, and I metaphorically burts into tears at your comment because if you'd documented all the things you had to learn the hard way as you went, you'd probably've gone a noticeable way towards fixing the problem you describe.
Note: I'm not, at all, trying to criticise you for not doing so. I'm just saying that if you could arrange for this to happen as you mentor somebody else it would be really really awesome :)
Clojure is a great language that has an achilles heel right now.
The other thing is that you cannot learn Clojure without learning Java, despite various claims; the atrocious error messages are just the tip of the iceberg there (and I say this as a professional Java developer).
Embracing the host (the JVM and Java) provides tremendous leverage in tooling, performance, and reach but has the corresponding tradeoffs of leaking that host environment throughout various parts of the stack. This is just something to accept and manage - the compromise is made.
I personally do not think the error messages are "atrocious". Some error messages are confusing or lack context. There are many tickets in progress to improve those and they continue to get better over time. This is an area we continue to work on within the language.
I'd say that might be moderated if you're got a good grounding in Lisp. I've been able to get a good distance basically learned nothing more about Java that what it took from C++ ... but that knowledge I brought to the table might enough to satisfy your claim in essence.
The community doesn't treat the lack of learning resources / documentation as a serious problem.
This is what drove me back to Haskell from Clojure. Haskell is miles ahead in documentation, references, tutorials and tooling. Tools like Hoogle are manna from heaven for beginners and experienced developers alike. Couple that with the self-documenting aspect of types and even undocumented Haskell libraries are grokkable in a reasonable amount of time.
While this has no bearing on anything you or anyone else should do today, it's worth noting Haskell is 24 years old, Clojure 9. I'd be astonished if Haskell wasn't miles ahead on all that you mention.
That may be so, but Haskell went through a very long gestation period while Clojure really hit the ground running. The Haskell as we know it today (from the revised Haskell 98 report) didn't come around until early 2003.
If you don't mind a longer journey to learning Clojure (works for Scala also): as you learn Clojure from online tutorials or books, also spend some time learning a bit about Haskell because so many ideas behind Clojure (and Scala) come from Haskell.
Comments
Clojure is a great language that has an achilles heel right now. The community doesn't treat the lack of learning resources / documentation as a serious problem. I've heard prominent members of the community say this exactly, "Clojure is such a great language that the lack of learning resources doesn't constitute a real problem in the grand scheme of things." I know what they're trying to communicate, but to beginners it comes off like "We've created the greatest thing since sliced bread - but we're not going to tell you how to use it - and if you would just take our word for it and blindly follow with no guidance you'll be a better developer". Which is really frustrating to hear, because it's like this thing seems so great, and smart people are all about it, but the only way to learn it is absolute misery. It's a tough perspective to have when you're only a couple years in to your dev career.
Clojure gives you massive benefits, but god it's a brutal road to competence. Things that should be simple like setting up a web server, adding user authentication, making JSON API's, trying to find the best libraries, it's all a time-consuming trudge through pain and suffering. And after some months when you get somewhat competent with the language, you realize that in order to get the full power of Clojure you need to not only learn the Clojure language, but the entire Clojure ecosystem. So you need Clojure, Clojurescript, Datomic, Edn, Core.async etc... And each piece of that puzzle is equally horribly documented and has no beginner resources so you have to struggle at each point in the process, praying to god that it's ultimately worth it.
It's frustrating as hell, but it really is rewarding, because you have to learn every little piece at a low-level to ever make anything happen. There's no Rails-like framework that makes things 'just-work' waiting for you. I find that using Clojure is awesome, but learning Clojure is awful. I'm hoping to play a role in fixing that second part pretty soon, but really wish the community would be more active in helping to remedy the problem. The first step is admitting that the problem exists and it matters, and not sure that we're there yet.
[context: I work at Cognitect on Clojure and community efforts]
I'll start by saying that documentation, examples, getting started, etc could be better and efforts are ongoing to improve all of those to various degrees.
However, there are substantial and rapidly growing resources (http://clojure.org/getting_started) for learning Clojure and other parts of the ecosystem. Some of the more recent beginner resources I'd recommend are "Clojure for the Brave and True" (http://www.braveclojure.com/) and Kyle Kingsbury's "Clojure from the ground up" series (http://aphyr.com/posts/301-clojure-from-the-ground-up-welcom...). There are also many good Clojure books - I'd recommend any of them.
In the web area, the philosophy is different than other languages and it is evolving rapidly (especially on the client side). Luminus (http://www.luminusweb.net/) is a good effort to provide a reasonable set of defaults that tie together the various Clojure web libraries.
So yes, it could be better. However, there are significant resources now and gaps continue to be filled.
One thing I've always found bizarre is that ClojureDocs hasn't been updated since 1.3. I know it isn't an official resource so you may not be able to do anything about it, but it's always at the top of Google's results.
I am working on that. :)
What are your thoughts on Neal Ford and Stu's Clojure from inside out series?
I haven't watched it but they are both excellent teachers with thorough knowledge of Clojure, so I can confidently predict that it's high quality.
I've been emailing one of your colleagues about working at cognitect - any chance you could help me get inducted into that software illuminati?
I had the opposite experience. It's pretty obvious how to do anything in Clojure. I don't need to hunt down magical incantations to use libraries like I had to in Ruby.
I started Clojure for web development. Once I found out about the Compojure template, everything else was just a stone's throw away.
I wager the average HN reader could run with that. That's actually what stifles the productivity of Rails projects I've worked on. It's why I started looking at other solutions and why the simplicity of Clojure pulled me over. Nobody really knows what just happened. Things kinda work til the answers to your questions can't be pasted from Devise's wiki anymore. Maybe we have different things in mind, here. The alternative to this in my experience is an application where nobody actually knows, for example, what's being put into the cookie, when it's put into the cookie, what part of the session is serialized in the DB, if the cookie is signed, etc.At least that's how it was at all the Rails projects I worked on.
https://github.com/ring-clojure/ring/wiki was refreshing. It turns out that managing your own session/cookie/authentication lifecycle in your own application code is easy. And it turns out that these "it just works" generators doesn't actually save any time because when you want to make trivial changes to them, you have to credentialize in yet another abstraction.
I haven't found that true, especially compared to any other language at this stage of development (complicated by the lack of the modern Internet, but I'm thinking especially about C++).
E.g. I'm helping someone with a web application and I've found no need whatsoever for Datomic (PostgreSQL + korma is just fine), I gather that means Edn is irrelevant, Core.async appears to be less than a year old, so I'm not surprised it might be lacking in documentation, and I don't see it as critical for a lot of applications, including mine. Clojurescript: we'll see, I do engines, and would prefer to continue to have others do almost all of that side of things.
Granted, it did take me a while to find and get up to speed on a set of libraries to do the web app I'm working on (mostly CRUD with some non-real time backend external communications), but it's been relatively pain free. I started with a recommended set, then as I found I needed to do something new, like JSON, I found a good library in a few minutes with Google and didn't find it at all difficult to fold it in.
Did change after a bit my form validation library to Red Tape, which modulo one detail (limited data available to form level cleaners (functions that act on more than one item in the form)) is superb.
And "superb" in general describes my experience doing all this. And I fully expect documentation and other learning resources to continue to improve as Clojure gets greater acceptance.
(Disclaimer: I'm an old Lisp and Scheme hand, e.g. not someone who had to learn anything conceptually new to use loop and recur. I could see the above plus learning basic functional Lisp concepts to be brutal if you're new to everything.
On the other hand, I can remember the days when learning MACLisp required reading an old David Moon manual and then the archives of a mailing list following it's publication; thank goodness there was a really great Lisp Machine Lisp manual and they were just starting to be somewhat available to use and learn on.)
I attended the Clojure/West conference about 3 weeks ago, and the sentiments are valid. But also, the Clojure community is starting to focus on the beginner learning curve aspects. Right now, there's a ClojureBridge effort (based on RailsBridge) to increase the diversity in the community. And it's been generating interest among people even outside the under-represented demographics. I'll be co-teaching the ClojureBridge SF session in 3 weeks, ping me if you're interested in future Clojure workshops (given the huge amount of interest, there definitely will be more!).
I think there's going to be some efforts in the near future in the Clojure community to tackle the low-hanging fruit of improving beginners' path to mastery.
If you come from OOP school of programming and the Algol/C++/Java style of syntax (true of many popular languages these days), then Clojure does require a re-think of the programming paradigm. But it truly is worth it -- it will make you a better programmer -- and the community is friendly, smart, and always learning and improving. It's certainly a language that I think that I will grow as a programmer by being with.
I think you might be overstating the syntax switching problems. The syntax of earlier Lisps is insanely simple, and Clojure only a little more so.
I base this in part on the very popular Python language's use of white space, which to a seasoned Lisper looks very familiar.
As for the focus on "diversity", I submit it might be misplaced at the moment, especially to the extent AlwaysBCoding's complaints are valid. To the extent Clojure is not making the sale to a target audience that's already 98%" heteronormative eeeevil white male (https://news.ycombinator.com/item?id=7581226), how likely are you to entice those outside that demographic? In fact, if you view Clojure as an experiment that may fail, are you doing them a favor by evangelizing it to them?
(I'd argue yes, since it's probably one of the easiest functional programming (FP) languages to learn, and it really helps to have FP in your toolkit. But I'd argue SICP or something gentler with multipardigm Scheme would be a better approach if you're just trying to accomplish that sort of thing.)
The first two ClojureBridge (http://clojurebridge.org) workshops sold out quickly and many more cities are working on events in the coming months. In addition, 100s of people have signed up to help or attend on the mailing list. There is clearly demand in diverse communities to learn programming via Clojure.
I don't think any serious student should expect to learn only one language. Clojure can teach concepts that any learner will find valuable in applying to other languages. In particular, I think that clear separation of values, identity, and state avoids many kinds of complication in learning how to program that are introduced early with other languages.
I am definitely not the best developer you will ever find, however I learn clojure by myself and it wasn't so hard...
(This is exactly the behaviour you are point as wrong, and I know it.)
The resource I had (back in the 2011/2012) were just a book, `The joy of Clojure`, my background was some C and mostly python, nothing about FP.
I don't see any of ClojureScript, Edn (???) nor core.whatever so fundamental... Those are just other tools, you can write any webserver using the old JS, JSON and any other lib you may need... (Anyway you should not try to learn clojure building web server, are the less clojure-y piece of software you can build IMHO)
IMHO, the biggest problem is the paradigm shift that most developer need to have in order of learn clojure.
Indeed. Learning functional programming in any language is a major jump for those of us (pretty much all of us?) who started out with imperative languages. It's ultimately very rewarding, but plenty of work in addition to mind stretching.
Then again you probably should have listened to all those people telling you to do The Structure and Interpretation of Computer Programs (SICP/6.001) ^_^, I merely lucked out to be at the edge of the community that created it, so it sort of fell into my lap, with strong recommendations that "this is revealed truth" as I like to put it.
I catch up on the SICP :)
To give but one example, if you're having any trouble with loop/recur, do the exercises on recursive functions that implement iteration without stack growth through tail recursion (the latter a feature that's unfortunately not available in the JVM; the flip side is that recur isn't going to blow your stack).
In the last couple of weeks I had to write a bunch of those in Clojure for the first time "in anger" (for real), and that part of it was trivial because of the SCIP I'd done in the early '80s. Learning that and pounding in my head for the first time was a bit hard, but well worth it, back then and of course now.
I am the developer of HiveMind (crudzilla.com), it is a web app platform which supports Clojure...it does have a middleware which is language independent, meaning you can use Clojure for your logic and tap into the middle-ware for things like DB interaction, email and JSON based application configuration...etc
You can find a quick installation guide here: http://blog.crudzilla.com/2014/04/hivemind-on-digital-ocean-...
Here's a screencast showing usage of Clojure, it requires no additional setup besides the installation guide above: http://crudzilla.com/assets/img/info-graphics/lang-demo.gif
Let me make a suggestion - the next person you convince to start working with clojure ... hold their hand through the process and make notes of everything you had to tell them about (because they couldn't find it in the docs) ... then at the very least publish those notes.
One of the big problems is that it's -really- hard to go back and explain this stuff once you're already an expert, and I metaphorically burts into tears at your comment because if you'd documented all the things you had to learn the hard way as you went, you'd probably've gone a noticeable way towards fixing the problem you describe.
Note: I'm not, at all, trying to criticise you for not doing so. I'm just saying that if you could arrange for this to happen as you mentor somebody else it would be really really awesome :)
The other thing is that you cannot learn Clojure without learning Java, despite various claims; the atrocious error messages are just the tip of the iceberg there (and I say this as a professional Java developer).
Embracing the host (the JVM and Java) provides tremendous leverage in tooling, performance, and reach but has the corresponding tradeoffs of leaking that host environment throughout various parts of the stack. This is just something to accept and manage - the compromise is made.
I personally do not think the error messages are "atrocious". Some error messages are confusing or lack context. There are many tickets in progress to improve those and they continue to get better over time. This is an area we continue to work on within the language.
I'd say that might be moderated if you're got a good grounding in Lisp. I've been able to get a good distance basically learned nothing more about Java that what it took from C++ ... but that knowledge I brought to the table might enough to satisfy your claim in essence.
The community doesn't treat the lack of learning resources / documentation as a serious problem.
This is what drove me back to Haskell from Clojure. Haskell is miles ahead in documentation, references, tutorials and tooling. Tools like Hoogle are manna from heaven for beginners and experienced developers alike. Couple that with the self-documenting aspect of types and even undocumented Haskell libraries are grokkable in a reasonable amount of time.
While this has no bearing on anything you or anyone else should do today, it's worth noting Haskell is 24 years old, Clojure 9. I'd be astonished if Haskell wasn't miles ahead on all that you mention.
That may be so, but Haskell went through a very long gestation period while Clojure really hit the ground running. The Haskell as we know it today (from the revised Haskell 98 report) didn't come around until early 2003.
If you don't mind a longer journey to learning Clojure (works for Scala also): as you learn Clojure from online tutorials or books, also spend some time learning a bit about Haskell because so many ideas behind Clojure (and Scala) come from Haskell.