While we are at it - how do you refactor a mid-sized/large Clojure project?
By making use of nice tooling like Cursive.
Clojure: A Lisp that wants to spread
11–20 of 306 posts
Re: Clojure: A Lisp that wants to spread
#12Why don’t lisp fans use older lisp implementations like Common Lisp or scheme? Is it just a lack of libraries and frameworks?
Who knows what the lisp crowd is ?
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.
Re: Clojure: A Lisp that wants to spread
#13I really like Clojure, it's a well designed language and one can get quite productive, surprisingly fast.
My core criticism that is not really mentioned in the article is the error messages. At the beginning I often felt lost and had no idea where to look if something went wrong.
Re: Clojure: A Lisp that wants to spread
#14While we are at it - how do you refactor a mid-sized/large Clojure project?
To add to your question: does spec help here?
Re: Clojure: A Lisp that wants to spread
#15Why don’t lisp fans use older lisp implementations like Common Lisp or scheme? Is it just a lack of libraries and frameworks?
Clojure is functional to the core and innovates a lot of areas, while other Lisps are more multi-paradigm and slant towards an OOP style. If you want to work universally with persistent data structures in your code and the libraries you use, Clojure is really the only option. Clojure also modernises Lisp syntax slightly (and a bit controversially) by getting rid of lots of parentheses and introducing new styles of parens for the core built-in data structures: ( ) [ ] { } #{ }. There's a bunch of other stuff, but really, Clojure is significantly different from other lisps.
The Rationale page on clojure.org has a pretty good rundown: https://clojure.org/about/rationale
Re: Clojure: A Lisp that wants to spread
#16Why don’t lisp fans use older lisp implementations like Common Lisp or scheme? Is it just a lack of libraries and frameworks?
My personal take: CL is a multi-paradigm rummage bin that demonstrated to the world the greatness of many features (e.g. macros, CLOS), but is also beset by many design flaws--some due to genuine infelicity of conception, and some due to unavoidable limitations of software and hardware at the time. (For one thing, there are approximately 101 ways to test equality). The result is that you could be a career CL programmer and see code written in a style you've never seen before, and that it suffers from design flaws that, if fixed, would result in something that would no longer be Common Lisp. Scheme's problem is kind of the opposite: it's stripped down, but also has not purged all of CL's unfortunate baggage, and very conspicuously lacks an out-of-the-box and full-featured package manager.
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.
Re: Clojure: A Lisp that wants to spread
#17Why don’t lisp fans use older lisp implementations like Common Lisp or scheme? Is it just a lack of libraries and frameworks?
It's amusing in retrospect because one of the criticisms of Common Lisp at the time was the massive size of its library.
Re: Clojure: A Lisp that wants to spread
#18Can we please stop using the verb transpile? Compile is fine, thank you.
When it was used only for certain kinds of "shallow" compilation it was bad enough (and it was really horrible even then), but this article uses it when describing compilation with whole-program analysis and optimization and machine code as the target.
Re: Clojure: A Lisp that wants to spread
#19Why don’t lisp fans use older lisp implementations like Common Lisp or scheme? Is it just a lack of libraries and frameworks?
Some of it is libraries and frameworks. Some of it is the attention Clojure has paid to ergonomics. A lot of Clojure’s libraries seem to have been built by smart people for mediocre programmers (like me!). Elsewhere in lisp land it can feel like smart people wrote libraries for themselves.
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.
Re: Clojure: A Lisp that wants to spread
#20I really like Clojure, it's a well designed language and one can get quite productive, surprisingly fast. My core criticism that is not really mentioned in the article is the error messages. At the beginning I often felt lost and had no idea where to look if something went wrong.
I like Clojure too but its less-than-useful error messages are what got me interested in Elixir. I still get Lisp-style macros with a better syntax (for me) and outstanding error messages (generally speaking).