Why don’t lisp fans use older lisp implementations like Common Lisp or scheme? Is it just a lack of libraries and frameworks?
The Rationale page on clojure.org has a pretty good rundown: https://clojure.org/about/rationale
For me Racket is probably the closest thing to a decent end-to-end modern lisp experience with decent libraries outside Clojure. Gerbil Scheme also looks promising.
For me I’m most often writing smallish standalone apps, which I feel are easier to make in Racket than Clojure. But between the two languages, I’d probably take Clojure if I didn’t have the JVM along for the ride. Of course the JVM is also one of Clojure’s biggest strengths. Also, I don’t trust Oracle enough to stop pretending that Graal doesn’t exist.
Did I parse that correctly as: "I don't trust Oracle, therefore I pretend Graal doesn't exist"?
And Graal (the option I’m aware of for compiling JVM-based code into a redistributable binary) is definitely Oracle. If I wrote more long-running code, or I could redistribute a stripped down JVM as easily as with Racket’s build tool “raco” I might have a different view, and I’d definitely prefer OpenJDK to Oracle’s.
[2]: https://docs.oracle.com/en/java/javase/13/docs/specs/man/jli...
Those are still LispWorks and Allegro Common Lisp.
Clojure, being just over 10 years old, has gotten to benefit from decades of witnessing other languages' spectacular design disasters, and it was designed by one person in a few years instead of by committee over decades. This results in a language that is much more aesthetically coherent, adhering to a pragmatic flavor of FP, and avoids a lot of gnarly warts: for instance, Clojure has one basic way to test equality irrespective of data type, and all basic data structures are immutable.
It's not obvious that (a) is superior to (b), an (c) is often what you get.
Really I'm rejecting the idea that that equality as presented in CL was any of: wrong, design by committee, or something we have learned do better since '84.
There are historical artifacts in CL that aren't great (cf filesystem stuff) but this wasn't a good example in my opinion.
I hear your argument - not fully convinced other than in a 80/20 sense. And CL was not designed as a language to leave the 20% out in the cold.
To be fair I don't find clojure compelling as a lisp but I don't think I'm being biased in above.
I don't love the CL implementation, particular eql vs equalp on numerics seems fiddly, and it's hard to keep all the cases separate. Homoiconicity introduces the need for a "representation equality" i guess which isn't always needed, etc.
I'd like to have a broad view of how many lispers working with one.
the few I know:
- scheme had a coma period due to specs issues (scheme small and large standard)
- commonlisp .. no idea but it seems quicklisp is enough for anybody to work, and there are many libs. Maybe not java/python levels .. but many. It's just out of the radar.
Additionally, there are many Lisp old timers that do not consider Clojure a Lisp.
From my brief experience it can do most of the same things except reader macros.
* Clojure is based on seqs rather than cons cells.
* Clojure renamed certain common functions, like car and cdr, so 30 year old Lisp example code no longer compiles.
* Clojure doesn't have implicit tail call optimisation for recursion.
* Clojure reveals its host platform when it has runtime errors.
Obviously this is okay for people who don't care of the historical baggage (and want to avoid it) and who don't care about the functionality of Lisps, like interactive error handling.
Nowadays I don't think of Scheme as a mainline Lisp -> it moved from a close Lisp dialect to its own language with its own standards, books, user groups, libraries, implementations, applications, ...
I've gone on at some length about those things before (for example, see my long comment in this thread: https://news.ycombinator.com/item?id=22318748, ), so I won't repeat it here.
I'll just say that Clojure is pretty nice as far as it goes, and I like it when it's the right tool for the job, but I feel like it's only halfway to being a proper Lisp. Whenever I work in it for very long I always miss more complete Lisps, and I daydream about a Clojure with the missing pieces filled in.
Be the change you want to see in the world and start filling in the missing pieces! ;-)
Cloture is an interesting effort:
https://github.com/ruricolist/cloture
I hope ruricolist succeeds.
But so far I haven't actually done any work in that direction. When I work on interpreters and compilers, I generally work on trying to improve upon Common Lisp, rather than trying to help Clojure catch up to it.
Years ago, in the early 1990s, I worked on an experimental OS at Apple. It was written mostly in a Lisp called Ralph (which later evolved into Dylan). Ralph was basically Scheme's kernel operations on top of data types built on CLOS with some functional-programming idioms.
Ralph had all of the nice things I was pining for in that post that I previously linked, but it was also a smaller, simpler, and more consistent language than Common Lisp, and it was easier to learn and easier to extend.
I've been working for years now on a language that started as a Ralph embedded in Common Lisp, but which has mutated quite a bit over the years as I learned new things and experimented with adding them to my implementations. It's been complete enough for me to ship a few products with it, but it's not done, and lately I've been inclined to steer it more back toward Ralph.
Mostly. There are still a few newer features I might like to keep.
So, while I acknowledge that it's totally fair of you to exhort me to work on Clojure, and it's not necessarily a bad idea, there is another Lisp for me to work on that is dearer to me.