I'm a Clojure newbie, but what impresses me about Clojure is the restraint and good taste in introducing new features to the language and core libraries. The language continues to be simple, extremely elegant and fun, but most of all, there is a strong sense of good design. APIs are considered carefully and not introduced into the core unless they solve a major problem, and solve it cleanly and well.
What is missing from Clojure, I think, is better support – either at the language level or as common practice – for large software composition, or programming-in-the-large. This is probably the opposite problem from to of Erlang, the other language that tackles the huge problem of state management well. Clojure is terrific when it comes to implementing computation, but how to best assemble various components into a large, maintainable program is not so clear.
I'd highly recommend checking out Stuart Sierra's component library. It's helps define your application into components that manage state and gives you lifecycle control of those components. basically dependency injection for clojure.
These aren't established practices yet. There don't seem to be any. This is not serious criticism, as I'm sure practices will evolve, but I think that currently it is a deficiency in the Clojure ecosystem. Making namespaces more like modules (that can be instantiated and parametrized) might help at the language level.
Your comment below this one focuses more on 'established practices' for large programs rather than 'is there a library that has this feature?'. I think that's just a reflection of both the state of functional programming and Clojure. They are growing and on there way to being commonly used in large systems, but not there yet (and so the practices don't exist).
For a completely different way of thinking about the problem of software composition that is more functional (although not for Newbies, not that you are) - there is lots of work going on with Monads in Clojure.
You can read about Monads in Clojure on Leonardo Borge's blog entry "Monads in Small Bites". This has some nice parallels by comparing Haskell and Clojure usage patterns.
Jim Duey has put lots of work into explaining Monads in Clojure in his talk at Clojure West. The way he builds up the venn diagram is a great visual explanation (some say the addition of arrows wasn't helpful).
In addition the Fluokitten library in Clojure has lots of building blocks for Monads in Clojure. You can read about it on this blog entry "Functors, Applicatives and Monads in Pictures - in Clojure". The great thing about this is the focus on boxing.
http://fluokitten.uncomplicate.org/articles/functors_applica...
I also saw my first Free Monad in Clojure in the wild this year:
One of the things I like about Clojure is that it doesn't tout itself as a "functional language", even though in many senses it is. The reason is that outside the enthusiast circles, i.e. in pretty much every enterprise, the term "functional language" is considered almost toxic; the term "monad" is highly toxic. Because Clojure has always been careful to put a lot of emphasis on practice over theory, if any monad-based approach to program composition is to be taken, a different name must be found for it. I think monads (not that I understand exactly what they are - I used to, but I forgot :)) are mostly useful for language designers. It is a very high-level abstraction, and the developer does not need to understand it in order to use a particular application of monads. In any case, anything with that even mentions the word monad can forget about widespread adoption. You can use them to build a specific API and then give it a different name, just don't mention the word.
Yes - I recall Simon Peyton Jones (one of the Haskell designers) commented on this in a talk when he came to town. He said, "The biggest mistake we made was calling them Monads. That's a big scary word."
Re naming and specific APIs - there is a comment along these lines on this blog entry:
"As you may have noticed, I reused list concatenation as monoid addition, but this makes a lot of sense, as list concatenation satisfies all the monoid laws, and no other laws. A more accessible way of saying that a type is a monoid is to say that it is combinable, addable, appendable or summable."
I started using Clojure in 2012. Here are the changes I've observed, though it is more subtle.
The tooling and the libraries are working much better right now. A strong indicator of this was the decision to nuke Noir, which I gather made a lot of sense when it came out. I've noticed that my code makes fewer calls to Java than it did a year ago. nRepl was a huge improvement over Slime. I'm looking forward to Leiningen 3.
Documentation across the board has improved quite a bit. Its still not perfect, but you can't deny the quality found in Elastich [1], Leinengen [2], ClojureScript [3], Luminus [4].
Many more useful libraries. I can't list them all here, but the library ecosystem has improved quite a bit, not only in quantity, but quality. Don't get me wrong, there are a few duds out there, but it is nice to see that many problems are being solved.
Stuart obviously has a Cognitect-centric view of what's gong on. It's interesting that you name three projects he didn't. This reflects the fact that, these days, there's way too much interesting stuff going on in Clojure. e.g. Cascalog 2
I am mentioning projects that have been around before 2013. I'm simply pointing out that one of the large complaints is being taken seriously. Documentation a year ago was basically "install and good luck." This is changing.
Have you used Elastisch in anger? Last project I used it in I gave up (and so did another colleague) and we started using clj-http + Cheshire to generate the JSON ourselves.
It was not a good experience and trying to get any help with errors netted me angry and uncooperative responses from the maintainer/creator.
No, I haven't exactly had a use-case for it yet. What I've needed so far can be solved with the database.
You do bring up an interesting point though. Some people in the community truly do suck and come across as elitist and are quick to dismiss you as an idiot with no good reason, when reality it is their poor documentation and assumptions that are amiss.
I shouldn't really write the dismissal found in the above paragraph. I've met quite a few Clojure users in real life, and to be honest, the vast majority are humble and just sort of making it up as they go along, albeit at a higher level. Overall, the Clojure community I've been exposed to has been great, and more than willing to help you. Don't let a bad apple ruin the basket.
great video outlining how datomic was implemented using clojure..I would say this is a large sized system....
I have built a larger system in clojure and do not have the same concerns..I feel for the first time in a while I have a powerful tool at my disposal and will be my tool of choice for now..
seems like we are going around in circles. what is so new and great about Clojure? we have Lisp and various implementations of Scheme which are more functional,powerful and stable. Clojure runs on the JVM so what?? seems like we kind of reinvent the wheel when the wheel was not broken to begin with.....i have done some programming in Clojure and also scheme. scheme is the real deal simple but powerful and not restricted because the JVM will not allow it.
After not using Clojure For about half a year (not a language my last customer uses) I have started using Clojure again for a new project. Clojure is like Ruby in the sense that I am simply happy working with both languages. I also use Java and JavaScript a lot, but I don't get the joy using those languages (not knocking them, but they are not as much fun to use).
What is missing from Clojure, I think, is better support – either at the language level or as common practice – for large software composition, or programming-in-the-large. This is probably the opposite problem from to of Erlang, the other language that tackles the huge problem of state management well. Clojure is terrific when it comes to implementing computation, but how to best assemble various components into a large, maintainable program is not so clear.