17 ms·

Well CL is pretty useful, lightweight, featureful… and Emacs Lisp is very similar to it, so you won't be lost.

User23 4y ago
I’m not sure I’d call CL lightweight. It’s a large language that also has some very interesting gaps in the standard. It is possible to write very performant code with modern implementations though. One of my favorite examples is the regex library cl-ppcre. Thanks to the nature of Lisp, the recognizer for each regex you create can be compiled to native code on compiler implementations of CL. And as a practical matter if you want to learn Common Lisp you’re probably going to be using GNU Emacs. Thus you’ll probably end up picking up some Elisp too. Both have their share of idiosyncrasies, but a great deal of what you’ll learn applies to both.
- hayley-patton 4y ago
  > One of my favorite examples is the regex library cl-ppcre. Thanks to the nature of Lisp, the recognizer for each regex you create can be compiled to native code on compiler implementations of CL. That is not true - cl-ppcre generates a chain of closures. Experimental performance is in the same ballpark as typical "bytecode" interpreting regex implementations. However, the "compiler macro" feature in Common Lisp allows for generating the chain of closures to be performed at compile-time, and invalid syntax (in string literals) can be detected at compile-time. (Disclosure: I wrote another regex library at <https://github.com/telekons/one-more-re-nightmare https://github.com/telekons/one-more-re-nightmare>, which does do native code compilation.)
- vindarel 4y ago
  the binaries are not specially lightweight either. What I had in mind in that when you start CL or install a bunch of dependencies (by staying in the REPL), this doesn't take many resources. Try another modern Lisp and bam, CPU and memory on fire. Running a binary is instantaneous too. That's a smooth developer experience.

I’m not sure I’d call CL lightweight. It’s a large language that also has some very interesting gaps in the standard. It is possible to write very performant code with modern implementations though. One of my favorite examples is the regex library cl-ppcre. Thanks to the nature of Lisp, the recognizer for each regex you create can be compiled to native code on compiler implementations of CL. And as a practical matter if you want to learn Common Lisp you’re probably going to be using GNU Emacs. Thus you’ll probably end up picking up some Elisp too. Both have their share of idiosyncrasies, but a great deal of what you’ll learn applies to both.

hayley-patton 4y ago
> One of my favorite examples is the regex library cl-ppcre. Thanks to the nature of Lisp, the recognizer for each regex you create can be compiled to native code on compiler implementations of CL. That is not true - cl-ppcre generates a chain of closures. Experimental performance is in the same ballpark as typical "bytecode" interpreting regex implementations. However, the "compiler macro" feature in Common Lisp allows for generating the chain of closures to be performed at compile-time, and invalid syntax (in string literals) can be detected at compile-time. (Disclosure: I wrote another regex library at <https://github.com/telekons/one-more-re-nightmare https://github.com/telekons/one-more-re-nightmare>, which does do native code compilation.)
vindarel 4y ago
the binaries are not specially lightweight either. What I had in mind in that when you start CL or install a bunch of dependencies (by staying in the REPL), this doesn't take many resources. Try another modern Lisp and bam, CPU and memory on fire. Running a binary is instantaneous too. That's a smooth developer experience.