3 ms·

Is there something special about CL as compared to other Lisp dialects? Why not choose something like Clojure, or LFE (Lisp-Flavored Erlang) with better async/l

by japhib 5y ago

Is there something special about CL as compared to other Lisp dialects? Why not choose something like Clojure, or LFE (Lisp-Flavored Erlang) with better async/library support? Then you skip over the community aspect entirely by piggybacking off the JVM or Erlang communities. (Another alternative would be Elixir, which is basically Erlang wrapped in a nicely-formatted version of Lisp. I.e. Elixir is to Erlang what Clojure is to Java.) I'm sure the answer comes down to something like, the author was more familiar with Node.JS so it would be a very quick rewrite. But I feel like there are a lot more Lisp-like language choices for backend APIs before you jump to Javascript.

cellularmitosis 5y ago
The article describes making use of one of the key features of Common Lisp implementations, that you can change both data and code on the fly while in the middle of an exception. I’m not certain those other lisps allow for that level of dynamism.
medo-bear 5y ago
> Is there something special about CL as compared to other Lisp dialects? cl is ansi standardized. it has several fast industrial strength implementations available that are self-hosted. it is both a high and low level language. it is FAST ... way faster than the dialects you named. its interactive development env is second to none > Elixir is to Erlang what Clojure is to Java i think LFE is meant to be that for Erlang. and i think that calling Elixir a lisp is stretching definitions quite a bit. as an asside there is an implementation of common lisp that resides on JVM - https://www.abcl.org/ https://www.abcl.org/
patrec 5y ago
> Is there something special about CL as compared to other Lisp dialects? It has by far the best interactive development experience.
- epolanski 5y ago
  Why? Asking as someone who only knows some Scheme.
  - Jtsummers 5y ago
    The Common Lisp debugger, in particular, is not part of Scheme (or at least the Scheme standards). CL is designed around interactivity in a way that Scheme is not and the interaction I describe next is a good example of that: Try doing the Scheme equivalent of this CL code and REPL interaction: ;; in a source file (defun simulate (instructions) (let ((state 0)) ;; this is based on an AoC problem I recently did (loop for (op val) in instructions finally (return state) do (ecase op )))) ;; in the REPL (simulate '((inc 5))) Note that nothing happens in that case expression right now. It will error out and send you to the debugger. Without selecting an option in the debugger, go back to the code and change it to this: (defun simulate (instructions) (let ((state 0)) ;; this is based on an AoC problem I recently did (loop for (op val) in instructions finally (return state) do (ecase op (inc (incf state val)))))) Recompile that code in the source file, and then tell the debugger to restart. Now it works and correctly returns 5 as a result. You can also do this much deeper in a program (I actually implemented the Advent of Code "virtual machine" this way). It doesn't restart the entire program, only the offending bit. (NB: All code written in the HN comment field, not actually tested so I may have mistyped something, should be correct though.) To the best of my knowledge, that sort of interaction is not standard in Scheme implementations.
  - mikelevins 5y ago
    Basically because Common Lisp (along with Smalltalk and very few other languages) is designed from the ground up to support livecoding as its primary workflow. The basic idea is that you start up your Lisp and it's already a working program; it just isn't the one you want to make. So you teach it interactively, a piece at a time, how to be the program you want. The workflow is less like constructing something according to a plan, and more like painting a picture or writing a document, looking at what you've got so far and making improvements and corrections as you go, all while the program continues to run. When the running program is what you want, you save it and ship it. The ANSI Common Lisp standard defines and standardizes a collection of features designed specifically to support this workflow. Because these features are in the standard, you can count on having them in any conforming implementation. For example, it defines a suite of language features that enable the runtime to automatically detect when you change the definition of a class, and it can automatically reinitialize existing instances to conform to the new definition. If you're not livecoding, those features make no sense; if you are, they are a godsend. It defines a suite of error-handling features that ensure that a conforming Common Lisp implementation responds to a runtime error by creating an interactive repl known as a *breakloop* that exists in the dynamic environment where the error occurred, before the stack has been unwound, and which provides interactive features you can use to explore that environment, edit it, redefine any values, types, functions or methods, including the ones that are pending on the stack, and then resume execution as if your new definitions had been in place to begin with. It makes absolutely everything in the runtime environment easily visible to the programmer and places it all under program control, so that you can inspect, edit, and redefine every aspect of the development environment while your work-in-progress is running, and see the effects of your changes instantly. Those are all common features provided for by the language standard. In addition, there are other conveniences for interactive programming, such as featureful interactive editors and image saving, that are not standarized, but that are sufficiently common in the shared history of Lisp implementations that they are notable when they're absent. These kinds of features are designed to facilitate working on a living program, modifying it interactively while it continues to run. They enable you to redefine every aspect of the program without ever being required to restart or rebuild it. Of course, that's a lot of power, and sometimes you'll get yourself into trouble with it, but the tools are designed to help you dig yourself back out, or to restart, if you must, from a convenient starting place. I have about as much experience with Scheme as with Common Lisp. I've been using both since the late 1980s, and have shipped multiple applications and systems with both. I like Scheme. It has some particular features and conventions that I like better than Common Lisp's. But Common Lisp is what I turn to first, and that's because it's designed around livecoding and Scheme is not. Some Schemes and similar languages (like early Dylan) have historically provided some of these features. The only Scheme-like language implementation I know of that provided them all was Leibniz, the early Dylan development environment at Apple--and it had them because it was written in Common Lisp and inherited Lisp's features. Full-featured Smalltalk environments are just as good. Interlisp is just as good (though very dated at this point). Few other development environments come close.

by japhib 5y ago

cellularmitosis 5y ago

The article describes making use of one of the key features of Common Lisp implementations, that you can change both data and code on the fly while in the middle of an exception. I’m not certain those other lisps allow for that level of dynamism.

medo-bear 5y ago

> Is there something special about CL as compared to other Lisp dialects? cl is ansi standardized. it has several fast industrial strength implementations available that are self-hosted. it is both a high and low level language. it is FAST ... way faster than the dialects you named. its interactive development env is second to none > Elixir is to Erlang what Clojure is to Java i think LFE is meant to be that for Erlang. and i think that calling Elixir a lisp is stretching definitions quite a bit. as an asside there is an implementation of common lisp that resides on JVM - https://www.abcl.org/ https://www.abcl.org/

patrec 5y ago

> Is there something special about CL as compared to other Lisp dialects? It has by far the best interactive development experience.

epolanski 5y ago
Why? Asking as someone who only knows some Scheme.
- Jtsummers 5y ago
  The Common Lisp debugger, in particular, is not part of Scheme (or at least the Scheme standards). CL is designed around interactivity in a way that Scheme is not and the interaction I describe next is a good example of that: Try doing the Scheme equivalent of this CL code and REPL interaction: ;; in a source file (defun simulate (instructions) (let ((state 0)) ;; this is based on an AoC problem I recently did (loop for (op val) in instructions finally (return state) do (ecase op )))) ;; in the REPL (simulate '((inc 5))) Note that nothing happens in that case expression right now. It will error out and send you to the debugger. Without selecting an option in the debugger, go back to the code and change it to this: (defun simulate (instructions) (let ((state 0)) ;; this is based on an AoC problem I recently did (loop for (op val) in instructions finally (return state) do (ecase op (inc (incf state val)))))) Recompile that code in the source file, and then tell the debugger to restart. Now it works and correctly returns 5 as a result. You can also do this much deeper in a program (I actually implemented the Advent of Code "virtual machine" this way). It doesn't restart the entire program, only the offending bit. (NB: All code written in the HN comment field, not actually tested so I may have mistyped something, should be correct though.) To the best of my knowledge, that sort of interaction is not standard in Scheme implementations.
- mikelevins 5y ago
  Basically because Common Lisp (along with Smalltalk and very few other languages) is designed from the ground up to support livecoding as its primary workflow. The basic idea is that you start up your Lisp and it's already a working program; it just isn't the one you want to make. So you teach it interactively, a piece at a time, how to be the program you want. The workflow is less like constructing something according to a plan, and more like painting a picture or writing a document, looking at what you've got so far and making improvements and corrections as you go, all while the program continues to run. When the running program is what you want, you save it and ship it. The ANSI Common Lisp standard defines and standardizes a collection of features designed specifically to support this workflow. Because these features are in the standard, you can count on having them in any conforming implementation. For example, it defines a suite of language features that enable the runtime to automatically detect when you change the definition of a class, and it can automatically reinitialize existing instances to conform to the new definition. If you're not livecoding, those features make no sense; if you are, they are a godsend. It defines a suite of error-handling features that ensure that a conforming Common Lisp implementation responds to a runtime error by creating an interactive repl known as a *breakloop* that exists in the dynamic environment where the error occurred, before the stack has been unwound, and which provides interactive features you can use to explore that environment, edit it, redefine any values, types, functions or methods, including the ones that are pending on the stack, and then resume execution as if your new definitions had been in place to begin with. It makes absolutely everything in the runtime environment easily visible to the programmer and places it all under program control, so that you can inspect, edit, and redefine every aspect of the development environment while your work-in-progress is running, and see the effects of your changes instantly. Those are all common features provided for by the language standard. In addition, there are other conveniences for interactive programming, such as featureful interactive editors and image saving, that are not standarized, but that are sufficiently common in the shared history of Lisp implementations that they are notable when they're absent. These kinds of features are designed to facilitate working on a living program, modifying it interactively while it continues to run. They enable you to redefine every aspect of the program without ever being required to restart or rebuild it. Of course, that's a lot of power, and sometimes you'll get yourself into trouble with it, but the tools are designed to help you dig yourself back out, or to restart, if you must, from a convenient starting place. I have about as much experience with Scheme as with Common Lisp. I've been using both since the late 1980s, and have shipped multiple applications and systems with both. I like Scheme. It has some particular features and conventions that I like better than Common Lisp's. But Common Lisp is what I turn to first, and that's because it's designed around livecoding and Scheme is not. Some Schemes and similar languages (like early Dylan) have historically provided some of these features. The only Scheme-like language implementation I know of that provided them all was Leibniz, the early Dylan development environment at Apple--and it had them because it was written in Common Lisp and inherited Lisp's features. Full-featured Smalltalk environments are just as good. Interlisp is just as good (though very dated at this point). Few other development environments come close.