3 ms·
I have felt some of the pain and gripes you have with Clojure and while I am not denying that some of them are very real, I am not sure if you understand the me
by optionalparens 10y ago
I have felt some of the pain and gripes you have with Clojure and while I am not denying that some of them are very real, I am not sure if you understand the mentality and philosophy behind Clojure as far as most of us who use it seem to have decided at least. Put succinctly, it is to balance practicality with features to get real work done.
Clojure is quite wisely based on the JVM because the idea was not to create a Lisp replacement or a new Lisp, but rather a practical Lisp. Some of the historical problems with Lisp and many other languages like Smalltalk were related to specialized hardware, development environments, and/or ecosystems. Clojure did away with most of these concerns by attaching itself to one of the largest existing environments.
Using the JVM was a wise decision that has/had many advantages not limited to:
- Ability to leverage an already huge ecosystem of libraries, tools, servers, etc. that are well-tested
- Already battle-tested and working package system - this is severely underestimated by some popular languages
- Justifying its existence as a tool along side other JVM languages within an organization, not a full replacement
- Existing, highly optimized JIT
- Reasonably fast, nearly for free
Originally there were some plans to expand more to other environments, for example the CLR, but the JVM got the most attention and in the end this was practical.
As for some of the real drawbacks:
- Clojure alienates Lisps zealots and people who could never grasp Lisp. IMO, this is a stupid person/psycho filter so I don't see it as a drawback but it's worth noting.
- Startup time as you note. Startup time sucks, but it has gotten better and there are workarounds that are the same ones you could use for Java apps traditionally. The mobile dev issue you note is somewhat wrong and without a huge explanation, one option is to more or less enjoy a huge part of Clojure via ClojureScript, or in other words, targeting JavaScript and using things like React Native.
- Garbage. This is an issue of a lot of things on the JVM and Clojure is no exception. You can work around this somewhat with specific coding practices if you need to, but yeah, Clojure isn't going to be good if you can't fathom an eventual garbage collection cycle.
- No TCO, which is mainly a JVM issue if I remember right. This would be great, but it's a tradeoff and Clojure has negotiated this somewhat by providing what I feel is more readable code than when I worked in certain Lisps.
- Some legacy baggage in the standard lib, for example Clojure.zip. Recently they've been more brutal about what can and cannot go into standard libs. Every language though suffers from this a bit.
Regarding developing its own VM, I think you again miss the point about practicality. If Clojure did this, it would have been even more years before its release. Moreover, comparing to Lua is a bad example as it is a very different language (yes, I used Lua professionally). Lua achieves a lot by really keeping it simple, and while there is merit to that, Lua leaves a ton to be desired which I won't get off-topic about here.
So Clojure could work better in its own VM, but then you'd lose the JVM ecosystem along with many other things. I personally would rather have the ability from the beginning to reach from a huge amount of libraries rather than have nothing but what other people writing the language provide or via crude things like calling back into C. There are many talks about all of this, many from Rich Hickey himself. I think you really missed the point of Clojure and I am more of the mindset that I am glad it exists and not in an ever state of flux so that I can use it today, get things done, and not have it relegated to some research language I could never justify in a workplace. And no, I am not a Clojure zealot, I used about a dozen languages in any given year depending on my project and interests. There's a lot I prefer in Lisp over Clojure, but I see Clojure as taking some lessons from various Lisps rather than trying to be the one true Lisp.
- progman 10y agoI understand why Clojure deliberately focuses on the Java ecosystem. If I still would be in Java development today I likely would use Clojure. If I were in web development I likely would use Clojurescript. Currently I prefer the Emacs/SLIME/SBCL toolbox which is more responsible (and Nim by the way). My humble two cents to the Clojure team: 1) You should implement a cache mechanism ("save-image") for native code so that at least the annoying startup time of clojure apps is gone. I wonder why Java doesn't support native caches to this day. 2) The weird Java stack trace problem could be solved by providing an individual stack tracer which is close to the source code. I know that this is not possible for Java libraries but at least clojure stack traces should be presented in a more convenient manner.