Interestingly enough, I actually worked in both CL and Clojure professionally.
Clojure for certain feels much more modern. They actually have modern build tools, logging systems, and testing frameworks, which is nice. The emphasis on more data types than just linked lists was amazing, sometimes you just need a hashmap, and Clojure's worked great. The rate of progress on the build tools was frankly spectacular, and some of my favorite libraries in the world are available in Clojure (core.logic anyone?)
The Clojure community has an approach to libraries that is utterly unique in my experience, and I miss it in other languages. Clojure libraries are the most lightly coupled libraries I've ever seen, as they use data as the API (a very Clojure and very Rich Hickey thing to do), which makes tying libraries together a trivial and reliable thing to do. They also have a habit of finishing libraries and not arbitrarily creating competitors for whatever reason. The result is that there are a lot of Clojure libraries that are narrowly scoped, feature complete, and trivial to upgrade if necessary. I really miss that.
Clojure also had some downsides however, both for how we used it and in general. The team that I worked on with it is now mostly Java these days.
Domain specific issues. If you have a bunch of objects that are similar syntactically, but vary semantically, you do not want to use Clojure. Clojure has very poor structures for handling this kind of stuff, and it's very very easy to accidentally go from your pretty record type back to a regular persistent hashmap on accident. Basically Clojure encourages (although does not strictly enforce) hashmap oriented programming. There are some domains where this is fine, but ours was decidedly not one of them.
Guidance wise, interacting with Clojure maintainers was rough. It's their project and they can guide it how they want, and we just got the feeling that they couldn't give a rip about what anyone else wanted. That's their right, but it was super annoying as an end user of the products that they were pushing so hard. We never really had any luck getting any of the bugs or issues that we found dealt with by the core team. We got the distinct impression that they were running the code we submitted and then deciding post-facto that what the code did was exactly what they'd wanted in the first place, but proving that is of course impossible. It's been a few years since I last tried to talk to them, so it's entirely possible that this has turned around since then.
I quit that job before Spec was released, so I cannot really comment on how effective that is in bullet-proofing a Clojure code base. What I can say is that the core Clojure libraries are wildly type unsafe, to a degree that's really only beaten by PHP. There are a ton of core functions that'll change output types without warning, sometimes in several different ways. Nominally this is fine because all the collections are built on top of the seq abstraction, but in reality that abstraction is as leaky as they get. The result is that our code base was littered with "(map identity x)" and "(vec y)" and "(into {} z)" to handle all these little weird edge cases. My suspicion is that Spec is a tacit admission that these little type errors really get out of control in a larger Clojure code base, and they're trying to fix it without having to revamp the entire core library.
That being said, between the two I would start any modern project in Clojure rather than CL. Access to Java, modern libraries for web development, and a much much larger pool of developer talent to access are absolutely killer features for that language over CL.
>That being said, between the two I would start any modern project in Clojure rather than CL. Access to Java, modern libraries for web development, and a much much larger pool of developer talent to access are absolutely killer features for that language over CL.
While I agree with the "larger pool of developer talent", I am already working with ABCL which has pretty easy Java interop.
As for developer talent, What's difficult to find, is to find developers who really grok macros and the "code is data" feature.
When you find one, he/she will have it very easy to jump from CL <--> Scheme <--> Clojure, so i'm not too worried about that.
Thanks for this experience report. If you did it again from scratch in Clojure, would you switch from records to using regular maps with a :type key, or your domains analogue? You can even do dispatch on those with defmulti/defmethod.
Clojure for certain feels much more modern. They actually have modern build tools, logging systems, and testing frameworks, which is nice. The emphasis on more data types than just linked lists was amazing, sometimes you just need a hashmap, and Clojure's worked great. The rate of progress on the build tools was frankly spectacular, and some of my favorite libraries in the world are available in Clojure (core.logic anyone?)
The Clojure community has an approach to libraries that is utterly unique in my experience, and I miss it in other languages. Clojure libraries are the most lightly coupled libraries I've ever seen, as they use data as the API (a very Clojure and very Rich Hickey thing to do), which makes tying libraries together a trivial and reliable thing to do. They also have a habit of finishing libraries and not arbitrarily creating competitors for whatever reason. The result is that there are a lot of Clojure libraries that are narrowly scoped, feature complete, and trivial to upgrade if necessary. I really miss that.
Clojure also had some downsides however, both for how we used it and in general. The team that I worked on with it is now mostly Java these days.
Domain specific issues. If you have a bunch of objects that are similar syntactically, but vary semantically, you do not want to use Clojure. Clojure has very poor structures for handling this kind of stuff, and it's very very easy to accidentally go from your pretty record type back to a regular persistent hashmap on accident. Basically Clojure encourages (although does not strictly enforce) hashmap oriented programming. There are some domains where this is fine, but ours was decidedly not one of them.
Guidance wise, interacting with Clojure maintainers was rough. It's their project and they can guide it how they want, and we just got the feeling that they couldn't give a rip about what anyone else wanted. That's their right, but it was super annoying as an end user of the products that they were pushing so hard. We never really had any luck getting any of the bugs or issues that we found dealt with by the core team. We got the distinct impression that they were running the code we submitted and then deciding post-facto that what the code did was exactly what they'd wanted in the first place, but proving that is of course impossible. It's been a few years since I last tried to talk to them, so it's entirely possible that this has turned around since then.
I quit that job before Spec was released, so I cannot really comment on how effective that is in bullet-proofing a Clojure code base. What I can say is that the core Clojure libraries are wildly type unsafe, to a degree that's really only beaten by PHP. There are a ton of core functions that'll change output types without warning, sometimes in several different ways. Nominally this is fine because all the collections are built on top of the seq abstraction, but in reality that abstraction is as leaky as they get. The result is that our code base was littered with "(map identity x)" and "(vec y)" and "(into {} z)" to handle all these little weird edge cases. My suspicion is that Spec is a tacit admission that these little type errors really get out of control in a larger Clojure code base, and they're trying to fix it without having to revamp the entire core library.
That being said, between the two I would start any modern project in Clojure rather than CL. Access to Java, modern libraries for web development, and a much much larger pool of developer talent to access are absolutely killer features for that language over CL.