4 ms·

If common lisp is the go-to Lisp, that's a sad indictment of Lisp itself. By commit counts in Github in first quarter of 2022, it doesn't even break into top 50

by natrys 4y ago

If common lisp is the go-to Lisp, that's a sad indictment of Lisp itself. By commit counts in Github in first quarter of 2022, it doesn't even break into top 50 languages [1]. Surely a flawed metric, but it's damning when you have Elisp - configuration language for a freaking text editor - at #25, and Clojure at #28. [1] https://madnight.github.io/githut/#/pushes/2022/1 https://madnight.github.io/githut/#/pushes/2022/1

forgotpwd16 4y ago
Thing is you don't have an alternative for ELisp. If you want to configure or/and extend Emacs, you've to use it. Common Lisp doesn't have such a strong connection to any platform. Nevertheless checking the list it comes as a surprise that languages like Smalltalk, Erlang, Groovy, Lean (a freaking theorem prover) are in but not Common Lisp.
- natrys 4y ago
  That's true. However consider the context that: i) Emacs has stopped appearing even at the bottom of popular surveys like stackoverflow years ago ii) Most Emacs users probably aren't too heavily into customisation iii) Or they likely already achieved their heavily customised system years ago, and mostly enjoy stability nowadays (that's me) iv) Most customisations are too personal in nature and aren't published online (also me) Given that, I think for Elisp to still come at #25 in this metric is a huge credit to its ecosystem for sure, but I still think that puts into perspective how much of a non-entity Common Lisp has become.
epr 4y ago
What? Wasn't ANSI CL standardized in 1994? Besides incremental performance and security improvements, what needs to change? Compare this to other popular languages from C++ to Python, which surely generate tons of additional work by continually changing the languages themselves.
- Jtsummers 4y ago
  There are a lot of redundancies in the language standard library caused by it being an amalgamation of multiple prior Lisps. Later standards could have deprecated some of those and then later removed them to provide a cleaner system, but they were needed in order to achieve the goal of mostly supporting other Lisps out of the box at the time of the standard (that is, with few or no code changes). elt and nth as examples. The former is generic, works on any sequence, the latter is list specific. In practice, what's the reason (besides backwards compatibility) to have both of these? There are other list-only functions which either have an equivalent sequence function or reasonably could if they don't. This would have been a natural improvement over time. Even if there was a lot of debate, Lisp being Lisp means you could always keep a package around for each prior set of the standard library. The later standards would have you start a package not based on the :cl package but on, say, the :cl99 package or :cl05 package. If you needed the deprecated/eliminated features, you'd use :cl94 or import specific symbols from it if you didn't want it all. It would also be nice to see a greater adoption of "sequence" (which has a limited set of things that qualify) being opened up so that user-defined sequences could be used with existing sequence processing functions. Same for numbers and other things. Allowing (performance is a valid concern here, though) more generic functions would open up more interesting developments later. See Julia and its application in the numerical computing domain. You can do that kind of computing in CL, but you can't use the existing arithmetic and numeric functions because they're only generic to the limit of the defined numeric tower and can't be extended beyond that. Concurrency, totally absent in the language standard, for better or worse. On the one hand you don't necessarily want to bless a particular concurrency model, and Common Lisp is nothing if not a toolbox language (pick your base capabilities and grow it to fit your application). So you'd want some low-level primitives that can be composed rather than blessing one or two particular models. But without standardization, this isn't happening. You do have Bordeaux-threads which basically gives you a portable threads interface by mapping to each CL implementation's specific threading library. But threads can be heavyweight compared to other options, and BT limits you to the lowest common denominator across the implementations. People have built useful abstractions on top of it, still. And some implementation could always implement something like coroutines and a thread pool for distributing them, but it would be implementation specific rather than standard. Even having that as a baseline model, leaving specifics of implementation open but locking down semantics, would be a good development for CL. And Lisp is almost uniquely able to handle transitions to later standards as I described above. You don't actually have to forfeit backwards compatibility entirely or at all if the changes are handled by moving to a new default base package. :cl-user/:cl become :cl##-user/:cl##. Accessing old features is still feasible.

by natrys 4y ago

forgotpwd16 4y ago

Thing is you don't have an alternative for ELisp. If you want to configure or/and extend Emacs, you've to use it. Common Lisp doesn't have such a strong connection to any platform. Nevertheless checking the list it comes as a surprise that languages like Smalltalk, Erlang, Groovy, Lean (a freaking theorem prover) are in but not Common Lisp.

natrys 4y ago
That's true. However consider the context that: i) Emacs has stopped appearing even at the bottom of popular surveys like stackoverflow years ago ii) Most Emacs users probably aren't too heavily into customisation iii) Or they likely already achieved their heavily customised system years ago, and mostly enjoy stability nowadays (that's me) iv) Most customisations are too personal in nature and aren't published online (also me) Given that, I think for Elisp to still come at #25 in this metric is a huge credit to its ecosystem for sure, but I still think that puts into perspective how much of a non-entity Common Lisp has become.

epr 4y ago

What? Wasn't ANSI CL standardized in 1994? Besides incremental performance and security improvements, what needs to change? Compare this to other popular languages from C++ to Python, which surely generate tons of additional work by continually changing the languages themselves.

Jtsummers 4y ago
There are a lot of redundancies in the language standard library caused by it being an amalgamation of multiple prior Lisps. Later standards could have deprecated some of those and then later removed them to provide a cleaner system, but they were needed in order to achieve the goal of mostly supporting other Lisps out of the box at the time of the standard (that is, with few or no code changes). elt and nth as examples. The former is generic, works on any sequence, the latter is list specific. In practice, what's the reason (besides backwards compatibility) to have both of these? There are other list-only functions which either have an equivalent sequence function or reasonably could if they don't. This would have been a natural improvement over time. Even if there was a lot of debate, Lisp being Lisp means you could always keep a package around for each prior set of the standard library. The later standards would have you start a package not based on the :cl package but on, say, the :cl99 package or :cl05 package. If you needed the deprecated/eliminated features, you'd use :cl94 or import specific symbols from it if you didn't want it all. It would also be nice to see a greater adoption of "sequence" (which has a limited set of things that qualify) being opened up so that user-defined sequences could be used with existing sequence processing functions. Same for numbers and other things. Allowing (performance is a valid concern here, though) more generic functions would open up more interesting developments later. See Julia and its application in the numerical computing domain. You can do that kind of computing in CL, but you can't use the existing arithmetic and numeric functions because they're only generic to the limit of the defined numeric tower and can't be extended beyond that. Concurrency, totally absent in the language standard, for better or worse. On the one hand you don't necessarily want to bless a particular concurrency model, and Common Lisp is nothing if not a toolbox language (pick your base capabilities and grow it to fit your application). So you'd want some low-level primitives that can be composed rather than blessing one or two particular models. But without standardization, this isn't happening. You do have Bordeaux-threads which basically gives you a portable threads interface by mapping to each CL implementation's specific threading library. But threads can be heavyweight compared to other options, and BT limits you to the lowest common denominator across the implementations. People have built useful abstractions on top of it, still. And some implementation could always implement something like coroutines and a thread pool for distributing them, but it would be implementation specific rather than standard. Even having that as a baseline model, leaving specifics of implementation open but locking down semantics, would be a good development for CL. And Lisp is almost uniquely able to handle transitions to later standards as I described above. You don't actually have to forfeit backwards compatibility entirely or at all if the changes are handled by moving to a new default base package. :cl-user/:cl become :cl##-user/:cl##. Accessing old features is still feasible.