4 ms·

> Commony Lisp is a deeply opinionated language How so? You can do whatever paradgim you want in CL. There is no policing involved. Not in the sense of Haskell

> Commony Lisp is a deeply opinionated language How so? You can do whatever paradgim you want in CL. There is no policing involved. Not in the sense of Haskell or Rust at least. CL will let you modify globals or share data willy nilly just fine. Mixing functions and values in lists is not really a restriction either, it opens up for all kinds of shenanigans.

zetalyrae 5y ago
There is a fairly high bedrock of abstraction, mostly because the compiler is available at runtime, the blurring of the distinction between compile-time and run-time, and image-based development. Common Lisp programs can be as fast as Java, but the executables are huge because they have to bundle the entire image inside. And tree-shaking is less effective because the language is so dynamic it's hard to guarantee some code won't ever be called. And if the abstraction bedrock is high, then problem domains below that bedrock can't be approached with the language.
- lispm 5y ago
  Contrary to popular believe, image support is common, but actually not required by the Common Lisp standard. Various Common Lisp implementations like ABCL (Common Lisp on the JVM), ECL, CLASP, mocl, ... don't support saving and starting images. > And tree-shaking is less effective because the language is so dynamic it's hard to guarantee some code won't ever be called. That depends on the delivery system. For example in LispWorks I can manually remove a lot of functionality: http://www.lispworks.com/documentation/lw71/DV/html/delivery-24.htm#pgfId-90015 http://www.lispworks.com/documentation/lw71/DV/html/delivery...
  - zetalyrae 5y ago
    Yes, LispWorks has a powerful tree shaker and I think SBCL now has one as well. Arguably images could get even smaller by distributing the runtime as a shared library. I admit this is an implementation detail.
    - lispm 5y ago
      It was already years ago a problem for some companies or organisations wanting to deploy Common Lisp software on tiny (embedded) machines or without GC. IS Robotics (later called iRobot) developed L, a small Common Lisp, for robots with small embedded computers - I think it also has been used on the Roomba devices.
      - zetalyrae 5y ago
        Is this a stripped down Common Lisp, or something like Naughty Dog's GOAL[0], basically an embedded assembly DSL? [0]: https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp
        lispm 5y ago
        It's Common Lisp. See "L - A Common Lisp for Embedded Systems" https://www.researchgate.net/publication/2949173_L_--_A_Common_Lisp_for_Embedded_Systems https://www.researchgate.net/publication/2949173_L_--_A_Comm... Another one was CLICC : https://github.com/hoelzl/Clicc https://github.com/hoelzl/Clicc which has a language definition for CL0 : https://github.com/hoelzl/Clicc/tree/master/doc https://github.com/hoelzl/Clicc/tree/master/doc There are or were a bunch of such small delivery oriented implementations: Oracle bought one years ago, Gensym has one, mocl is derived from CLICC, ...
        ekidd 5y ago
        Hello, former minor L contributor here! (I last worked on it in the late 90s, and I'm only going to talk about stuff that iRobot has mentioned publicly.) L was actually a subset of Common Lisp. It would run pretty nicely on a machine with 1 MB total RAM and a 16 MHz CPU. All the basics were there: lambdas and macros and symbols and modules, and they all worked how they did in Common Lisp. (Or they were close enough that you could write and test in Common Lisp and then cross-compile.) There was a REPL that could run most code, and an ahead-of-time compiler. It was a fantastically nice environment for embedded systems too small to run something like Alpine Linux. You could compile a program, load it onto actual hardware, and then tweak things interactively using the REPL. And you could invent all kinds of macro DSLs. Of course, all this becomes moot once your system is large enough to support Alpine Linux and an SSH server. If you can run Linux, then you can use Lisp or Python or PLT Scheme or Rust or anything else you want, and you have half a million open source libraries available. Still, L is proof that Lisp is a great embedded language for anything with a MB of RAM. You can have a pleasant development environment and tons of flexibility, with an excellent REPL.
ekidd 5y ago
The deepest and most radical opinions of Lisp are: - You should be able to implement Lisp-in-Lisp within a few pages of code. This a profound and remarkable design constraint. (See http://languagelog.ldc.upenn.edu/myl/llog/jmc.pdf http://languagelog.ldc.upenn.edu/myl/llog/jmc.pdf (PDF) for an introduction.) - Syntax would only hide the fact that code is a simple data structure that can be manipulated like any other data structure. Just like Rust's strong opinions buy you stress-free threading and bit-banging, Lisp's opinions ensure that it's an almost ideal environment for inventing domain-specific language extensions. But Rust is poorly suited to object graphs where everything mutates everything else, and Common Lisp is poorly suited to proving that a large program obeys certain strict rules. I love opinionated tools, but I try to choose ones with the "right" opinions for the task at hand.
- pharmakom 5y ago
  The object graph problem really hurts Rust imo. In C# I can just mutate and forget about ownership. In Haskell I can solve this using an immutable graph and a state monad. In Rust it gets pretty awkward.
  - db48x 5y ago
    Yea, but in those languages you have a garbage collector working in the background to clean up after you. You don’t always want to pay that cost. From time to time I work on an open source application that spends 60–70% of its time in garbage collection, at least on jobs at the extreme end of the size we can handle. I’m starting to think about ridiculous hacks like combining millions of moderately–sized objects into a giant arena. With no pointers into the arena (just indicies), I can eliminate a huge chunk of the time wasted scanning the heap over and over again. But at that point, why am I writing this in Go? My Rust prototype is very incomplete, but for the parts that are implemented it uses way less memory and completes a lot more quickly. And I haven’t done _any_ performance optimization or ridiculous hacks there yet.
    - pitaj 5y ago
      And in Rust you can always drop down to reference counted heap allocated stuff as well.

zetalyrae 5y ago

There is a fairly high bedrock of abstraction, mostly because the compiler is available at runtime, the blurring of the distinction between compile-time and run-time, and image-based development. Common Lisp programs can be as fast as Java, but the executables are huge because they have to bundle the entire image inside. And tree-shaking is less effective because the language is so dynamic it's hard to guarantee some code won't ever be called. And if the abstraction bedrock is high, then problem domains below that bedrock can't be approached with the language.

lispm 5y ago
Contrary to popular believe, image support is common, but actually not required by the Common Lisp standard. Various Common Lisp implementations like ABCL (Common Lisp on the JVM), ECL, CLASP, mocl, ... don't support saving and starting images. > And tree-shaking is less effective because the language is so dynamic it's hard to guarantee some code won't ever be called. That depends on the delivery system. For example in LispWorks I can manually remove a lot of functionality: http://www.lispworks.com/documentation/lw71/DV/html/delivery-24.htm#pgfId-90015 http://www.lispworks.com/documentation/lw71/DV/html/delivery...
- zetalyrae 5y ago
  Yes, LispWorks has a powerful tree shaker and I think SBCL now has one as well. Arguably images could get even smaller by distributing the runtime as a shared library. I admit this is an implementation detail.
  - lispm 5y ago
    It was already years ago a problem for some companies or organisations wanting to deploy Common Lisp software on tiny (embedded) machines or without GC. IS Robotics (later called iRobot) developed L, a small Common Lisp, for robots with small embedded computers - I think it also has been used on the Roomba devices.
    - zetalyrae 5y ago
      Is this a stripped down Common Lisp, or something like Naughty Dog's GOAL[0], basically an embedded assembly DSL? [0]: https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp
      - lispm 5y ago
        It's Common Lisp. See "L - A Common Lisp for Embedded Systems" https://www.researchgate.net/publication/2949173_L_--_A_Common_Lisp_for_Embedded_Systems https://www.researchgate.net/publication/2949173_L_--_A_Comm... Another one was CLICC : https://github.com/hoelzl/Clicc https://github.com/hoelzl/Clicc which has a language definition for CL0 : https://github.com/hoelzl/Clicc/tree/master/doc https://github.com/hoelzl/Clicc/tree/master/doc There are or were a bunch of such small delivery oriented implementations: Oracle bought one years ago, Gensym has one, mocl is derived from CLICC, ...
        ekidd 5y ago
        Hello, former minor L contributor here! (I last worked on it in the late 90s, and I'm only going to talk about stuff that iRobot has mentioned publicly.) L was actually a subset of Common Lisp. It would run pretty nicely on a machine with 1 MB total RAM and a 16 MHz CPU. All the basics were there: lambdas and macros and symbols and modules, and they all worked how they did in Common Lisp. (Or they were close enough that you could write and test in Common Lisp and then cross-compile.) There was a REPL that could run most code, and an ahead-of-time compiler. It was a fantastically nice environment for embedded systems too small to run something like Alpine Linux. You could compile a program, load it onto actual hardware, and then tweak things interactively using the REPL. And you could invent all kinds of macro DSLs. Of course, all this becomes moot once your system is large enough to support Alpine Linux and an SSH server. If you can run Linux, then you can use Lisp or Python or PLT Scheme or Rust or anything else you want, and you have half a million open source libraries available. Still, L is proof that Lisp is a great embedded language for anything with a MB of RAM. You can have a pleasant development environment and tons of flexibility, with an excellent REPL.

ekidd 5y ago

The deepest and most radical opinions of Lisp are: - You should be able to implement Lisp-in-Lisp within a few pages of code. This a profound and remarkable design constraint. (See http://languagelog.ldc.upenn.edu/myl/llog/jmc.pdf http://languagelog.ldc.upenn.edu/myl/llog/jmc.pdf (PDF) for an introduction.) - Syntax would only hide the fact that code is a simple data structure that can be manipulated like any other data structure. Just like Rust's strong opinions buy you stress-free threading and bit-banging, Lisp's opinions ensure that it's an almost ideal environment for inventing domain-specific language extensions. But Rust is poorly suited to object graphs where everything mutates everything else, and Common Lisp is poorly suited to proving that a large program obeys certain strict rules. I love opinionated tools, but I try to choose ones with the "right" opinions for the task at hand.

pharmakom 5y ago
The object graph problem really hurts Rust imo. In C# I can just mutate and forget about ownership. In Haskell I can solve this using an immutable graph and a state monad. In Rust it gets pretty awkward.
- db48x 5y ago
  Yea, but in those languages you have a garbage collector working in the background to clean up after you. You don’t always want to pay that cost. From time to time I work on an open source application that spends 60–70% of its time in garbage collection, at least on jobs at the extreme end of the size we can handle. I’m starting to think about ridiculous hacks like combining millions of moderately–sized objects into a giant arena. With no pointers into the arena (just indicies), I can eliminate a huge chunk of the time wasted scanning the heap over and over again. But at that point, why am I writing this in Go? My Rust prototype is very incomplete, but for the parts that are implemented it uses way less memory and completes a lot more quickly. And I haven’t done _any_ performance optimization or ridiculous hacks there yet.
  - pitaj 5y ago
    And in Rust you can always drop down to reference counted heap allocated stuff as well.