4 ms·

Lisp thrives in Babel, while the other kinds of languages may be harmed by it. Lisp is a meta-language and it facilitates building a Babel tower of eDSLs for ea

by sklogic 11y ago

Lisp thrives in Babel, while the other kinds of languages may be harmed by it. Lisp is a meta-language and it facilitates building a Babel tower of eDSLs for each and every little project. It is the main source of its unmatched power.

ridiculous_fish 11y ago
But this doesn't require the proliferation of implementations. Each little project doesn't require its own garbage collector, for example. The paper I linked discusses some of the "practical" areas of Haskell: profiling, debugging, packaging, FFI, compiler errors and optimizations, etc. Surely there's a lot of energy being expended replicating this stuff across the various Lisp implementations?
- mbrock 11y ago
  There happens to be wide community consensus around a single Haskell compiler, GHC, at the moment, but that's a contingency and there are some other compilers, interpreters, and stuff like GHCJS. Profiling and debugging support is a feature of GHC (and other implementations), not of the language standard. Common Lisp has unified packaging and FFI and stuff through various community projects like ASDF and Quicklisp. If you're talking about Lisp in the general vague sense of "Lisps" then there can't be general interoperability because that umbrella term covers lots of very different languages with no formal common ground.
- zodmaner 11y ago
  There aren't that many Lisp implementations, especially those that are considered to be mature and ready for production. For Common Lisp, the open source ones are SBCL and Clozure CL, and the proprietary ones are Allegro CL and LispWorks. For Scheme, there are Racket (PLT Scheme), Chicken Scheme, and Guile. I'm quite certain that the majority of people who use Common Lisp and/or Scheme use one of the aforementioned implementations.
- sklogic 11y ago
  Even GC cannot be a common ground for everything. Take a look at Harlan, a Lisp-like language with a region-based memory management. Unification harms diversity and flexibility.

by sklogic 11y ago

ridiculous_fish 11y ago

But this doesn't require the proliferation of implementations. Each little project doesn't require its own garbage collector, for example. The paper I linked discusses some of the "practical" areas of Haskell: profiling, debugging, packaging, FFI, compiler errors and optimizations, etc. Surely there's a lot of energy being expended replicating this stuff across the various Lisp implementations?

mbrock 11y ago
There happens to be wide community consensus around a single Haskell compiler, GHC, at the moment, but that's a contingency and there are some other compilers, interpreters, and stuff like GHCJS. Profiling and debugging support is a feature of GHC (and other implementations), not of the language standard. Common Lisp has unified packaging and FFI and stuff through various community projects like ASDF and Quicklisp. If you're talking about Lisp in the general vague sense of "Lisps" then there can't be general interoperability because that umbrella term covers lots of very different languages with no formal common ground.
zodmaner 11y ago
There aren't that many Lisp implementations, especially those that are considered to be mature and ready for production. For Common Lisp, the open source ones are SBCL and Clozure CL, and the proprietary ones are Allegro CL and LispWorks. For Scheme, there are Racket (PLT Scheme), Chicken Scheme, and Guile. I'm quite certain that the majority of people who use Common Lisp and/or Scheme use one of the aforementioned implementations.
sklogic 11y ago
Even GC cannot be a common ground for everything. Take a look at Harlan, a Lisp-like language with a region-based memory management. Unification harms diversity and flexibility.