21–30 of 306 posts
Can 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.
Why don’t lisp fans use older lisp implementations like Common Lisp or scheme? Is it just a lack of libraries and frameworks?
Additionally, there are many Lisp old timers that do not consider Clojure a Lisp.
Can 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.
I do apologise. This was written mostly as a stream of consciousness, only stopping to google the github repos.
Anyway, Clojure is great!
[1]: https://stackoverflow.com/a/9859966/750563
[2]: Sorry Template Haskell, Java is more referentially transparent than you, although the consequences of that are not what those same FP people think, either.
Why 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 pa…
Why 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 programm…
It's not obvious that (a) is superior to (b), an (c) is often what you get.
1. Tooling. You end up spending way more time getting your tooling setup than it should be. 2. Difficulty in learning. 3. Clear best practices and frameworks. The philosophy of composing libraries is extremely powerful, but to gain broader adoption you still need straight forward frameworks and opinionated best practices.
The last point has many unintuitive consequences. Clojure tends to attract people who enjoy doing new things, or excelling in their craft. But mass adoption also means catering to people who need to do "boring" things where people just want to get their job done. For boring code, which is the reality for many developers, they just want a clear best practice to get the stuff done.
This could be a clear standard library or framework for a task, a clear architectural pattern, and it certainly means easy to access code snippets. There have been some attempts at these things, e.g. Luminous for the web, but the community hasn't rallied around them with enough weight to make newcomers comfortable.
So when faced with choosing: a testing library, any number of libraries compose into a web service, any number of approaches to client side, then in the end still having 100 equally good ways to architect a given piece of code that requires thinking mathematically, well, it's daunting. Especially when you are new to the language and just want to get your boring CRUD app working.
Maybe this is best summed up as saying that Clojure caters to the creative, but to gain widespread adoption it also needs to cater to those stuck writing boring code and just want to be done with it as fast as possible.
For some reason this doesn't often happen with regular Lisp even though CFFI is available. There's a tendency to just reimplement it directly in Lisp, which is the more maintainable option.
Earlier quoted context omitted.
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 programm…
I'm not sure you've picked the right example here - far from being a gnarly wart, differences types of equality are a fundamental issue. Your language can choose to either a) hide it effectively (constraining some things) b) expose it to the user which means they have to think about it or c) try (a) but leak and give weird corner cases. It's not obvious that (a) is superior to (b), an (c) is often what you get.
Earlier quoted context omitted.
I'm not sure you've picked the right example here - far from being a gnarly wart, differences types of equality are a fundamental issue. Your language can choose to either a) hide it effectively (constraining some things) b) expose it to the user which means they have to think about it or c) try (a) but leak and give weird corner cases. It's not obvious that (a) is superior to (b), an (c) is often what you get.
In the abstract you're right that equality is subtle and complicated, but it seems to me that in practice, most practicing software engineers just want value-equality on garden-variety data structures most of the time (remember == for Strings in Java?), and that for this use-case, a leaky abstraction is fine--preferable, even. At least, the alternative--forcing users to consider the subtleties of equality even in cir…
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.
Why 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.…
Did I parse that correctly as: "I don't trust Oracle, therefore I pretend Graal doesn't exist"?