3 ms·

> And the worst parts of Common Lisp would be the massive, inconsistent, designed-by-committee language, CLOS, and macros. I've always wondered what would happ

> And the worst parts of Common Lisp would be the massive, inconsistent, designed-by-committee language, CLOS, and macros. I've always wondered what would happen if there was a CL standardization where everything was CLOS'ified in the :common-lisp package, so the #'+, #'map(can), etc. were generic functions along with a nice set of collections (dictionary, etc.). And the more specialized/efficient functions were squirreled away in a non-default package. Well that, and a bunch of other things like a different module system. SBCL seems like such a nice compiler that doesn't get the respect it deserves for being able to compile fast binaries for such a dynamic language.

ScottBurson 6y ago
There are lots of good ideas floating around for a second CL standard. The problem is, either such a language has a CL compatibility environment, in which case it is probably implemented in CL using the features already in the language, meaning that it's really just another Quicklisp package; or it doesn't, in which case it has to fill some need that couldn't be filled the first way in order to attract a critical mass of interest. Julia is the closest thing I'm aware of to the latter. It's hard to get people to switch from something they find good enough for their needs, if the new thing is incompatible. See: Perl 6.
- lizmat 6y ago
  In the case of Perl 6 this has resulted in a rename of the language to Raku (https://raku.org https://raku.org using the #rakulang tag on social media). An experience I would not recommend.