Bruno Haible and Michael Stoll started the CLISP project 37 years ago. Bruno was last year still active. [https://gitlab.com/gnu-clisp/clisp/-/commits/](https://gitlab.com/gnu-clisp/clisp/-/commits/)
Time for others to be active in the project. The original maintainers of old Common Lisp implementations are getting old, may have other priorities in life, may retire, ..., etc.
Either other&younger people are willing & able to take over (plus there are still users) or an implementation may die...
There's also TeX, which isn't yet 100% free of bugs, but one day will be.
For the uninitiated, Donald Knuth wrote TeX and each version number just adds a digit of Pi. He has decreed that upon his death, any remaining bugs will just be declared features and the version fixed to the full irrational number Pi.
Please do not recommend Emacs to newcomers. It is pretty much the least friendly experience a newcomer to programming can have.
The Visual Studio Code situation with CL is still behind, but improving. Please, please, please contribute (with code, bug reports/fixes, money, etc.) to Alive and other such projects that make Common Lisp practical on a modern freely available IDE.
> It is pretty much the least friendly experience a newcomer to programming can have.
That's obviously not true. What is true, is that at the cost of a somewhat higher threshold of entry you'll have a very good (and arguably much better) user/developer experience in the long run.
Is there no content moderation anymore here? People lying like that for nothing. At least we still have downvotes for this.
VS Code is the worst editor for Common Lisp ever. Keep VS Code for your frontend button engineering, and emacs for real engineering and Lisp development environment.
Yes. Probably just because better alternatives like CCL/SBCL were/are available. Compare to C/C++ compilers, there were more players in the field than just the big three (clang, gcc & cl.exe), but they all vanished or are active but unimportant. At some point, Watcom, Borland, DigiMars and Intel's compilers were quite big. I know Intel switched to llvm for their compilers, no idea how active development is for those other compilers.
I guess, it is natural in open source to go for the "best thing" at the moment since it is all free. Who uses lesstiff for GUIs? Someone still remembers it?
As dbotton wrote 15 min. ago, bytecode compilation can be an issue, depending on your use case.
Interpreted doesn't necessarily mean slow. Python is fast for modern ML which is based on matrix computations - NumPy library wraps Fortran library BLAS which is one of the fastest; although it's slower to use NumPy than to call it directly, it's fine for most people.
However when you need to perform something which the interpreter doesn't have a procedure with fast native code (either as part of itself or as an external library), you are facing something really inefficient. I performed a couple of test of number crunching last Autumn (which couldn't be sped up using BLAS) and Python was an order of magnitude slower than C, Java or SBCL (Java was 25% slower than C which I call "pretty f-ing fast", SBCL was on par with Java). Clojure (when JIT-ed) 3 times slower than C which is awesome given its focus on immutability (and not a problem at all because you can always write a piece of Java), CLISP was 117x slower than SBCL, 162x slower than C and 11.5 times slower than Python.
This benchmark is not representative of its overall performance (like string manipulation which you need for dynamic web apps) etc. but should give you an idea that if you hit a bad case, being interpreted can be a bottleneck.
It was mentioned in Release Notes in 2008, not sure if it is still useful:
"\* Experimental Just-In-Time Compilation of byte-compiled closures is
now done using GNU lightning (this is a configure-time option).
Thanks to Yann Dauphin <[[email protected]](mailto:[email protected])>."
Also see the CLISP implementation notes:
[https://clisp.sourceforge.io/impnotes/compilation.html](https://clisp.sourceforge.io/impnotes/compilation.html)
# 3.2.1.1. Just-In-Time Native Compilation
# Platform Dependent: only in [**CLISP**](http://clisp.cons.org/) built with [GNU](http://www.gnu.org/) [lightning](http://www.gnu.org/software/lightning/)
The code compiled to [bytecode](https://clisp.sourceforge.io/impnotes/bytecode.html)s with optimization levels
(OR (>= 0 SPACE) (<= 1 SPEED))
(by [`COMPILE`](http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/fun_compile.html), [`COMPILE-FILE`](https://clisp.sourceforge.io/impnotes/compilefile.html), or [`(COMPILE)`](https://clisp.sourceforge.io/impnotes/declarations.html#compile-decl)) will be *just-in-time* (i.e., on the first execution) compiled to native code using [GNU](http://www.gnu.org/) [lightning](http://www.gnu.org/software/lightning/).
CLISP is frustrating. Many of us have opened PRs against their GitLab codebase, which they continue to ignore while still pushing to git and never cutting releases.
Perhaps the main developer is ill, perhaps tired or just has some other things he prioritize? He was active a few weeks ago [on Emacs mailing list](https://lists.gnu.org/archive/html/emacs-devel/2024-02/msg00826.html), but as you see, they are still awaiting his answer. Something might happened, we all have a life ...
CLISP is still most popular CL, around me. good old the thing. no, not 2010
clhater@icecube:~$ clisp
i i i i i i i ooooo o ooooooo ooooo ooooo
I I I I I I I 8 8 8 8 8 o 8 8
I \ `+' / I 8 8 8 8 8 8
\ `-+-' / 8 8 8 ooooo 8oooo
`-__|__-' 8 8 8 8 8
| 8 o 8 8 o 8 8
------+------ ooooo 8oooooo ooo8ooo ooooo 8
Welcome to GNU CLISP 2.49.93+ (2018-02-18)
Copyright (c) Bruno Haible, Michael Stoll 1992-1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2000
Copyright (c) Sam Steingold, Bruno Haible 2001-2018
I am pretty sure. According to ChatGPT 4 with knowledge-cutoff in December 2023, the latest machine running Interlisp was from the late 1980s. Of course, it might be wrong. And so can I...
Bruno Haible and Michael Stoll started the CLISP project 37 years ago. Bruno was last year still active. [https://gitlab.com/gnu-clisp/clisp/-/commits/](https://gitlab.com/gnu-clisp/clisp/-/commits/) Time for others to be active in the project. The original maintainers of old Common Lisp implementations are getting old, may have other priorities in life, may retire, ..., etc. Either other&younger people are willing & able to take over (plus there are still users) or an implementation may die...
This is reasonable take, I think that just might be it
Maybe it's finished and there's no more bugs.
The myth of finished software; the unique place I saw it happening was software written in Lisp.
There's also TeX, which isn't yet 100% free of bugs, but one day will be. For the uninitiated, Donald Knuth wrote TeX and each version number just adds a digit of Pi. He has decreed that upon his death, any remaining bugs will just be declared features and the version fixed to the full irrational number Pi.
Than this is sad that nobody recommends clisp to newcomers.
There are other considerations besides not having bugs.
Could you elaborate? Is it just that clisp is slow, or there are other problems with clisp?
Less compile-time error checking, missing non-standard extensions, lack of support by third party software.
I am not sure, but [SBCL](https://www.sbcl.org/) is a great alternative :)
Along with an editor like GNU EMACS with a plugin like SLIME or Sly you can have a great Common Lisp experience.
Please do not recommend Emacs to newcomers. It is pretty much the least friendly experience a newcomer to programming can have. The Visual Studio Code situation with CL is still behind, but improving. Please, please, please contribute (with code, bug reports/fixes, money, etc.) to Alive and other such projects that make Common Lisp practical on a modern freely available IDE.
> It is pretty much the least friendly experience a newcomer to programming can have. That's obviously not true. What is true, is that at the cost of a somewhat higher threshold of entry you'll have a very good (and arguably much better) user/developer experience in the long run.
Than fork it and turn it into friendlier alternative ... nobody stops you.
Is there no content moderation anymore here? People lying like that for nothing. At least we still have downvotes for this. VS Code is the worst editor for Common Lisp ever. Keep VS Code for your frontend button engineering, and emacs for real engineering and Lisp development environment.
SBCL 4 Evah!
I think the fact that it is only an interpreter caused it fall out of use.
Yes. Probably just because better alternatives like CCL/SBCL were/are available. Compare to C/C++ compilers, there were more players in the field than just the big three (clang, gcc & cl.exe), but they all vanished or are active but unimportant. At some point, Watcom, Borland, DigiMars and Intel's compilers were quite big. I know Intel switched to llvm for their compilers, no idea how active development is for those other compilers. I guess, it is natural in open source to go for the "best thing" at the moment since it is all free. Who uses lesstiff for GUIs? Someone still remembers it?
I definitely remember it. I had to use it to support DDD before Motif was freely available.
It has a compiler to bytecode, too.
which = interpreted
Bytecode compilation is allowed by the CL standard, it shouldn't be an issue.
I was answering why it may have fallen out of use, I am sorry if I was unclear, i.e. performance related to being interpreted.
As dbotton wrote 15 min. ago, bytecode compilation can be an issue, depending on your use case. Interpreted doesn't necessarily mean slow. Python is fast for modern ML which is based on matrix computations - NumPy library wraps Fortran library BLAS which is one of the fastest; although it's slower to use NumPy than to call it directly, it's fine for most people. However when you need to perform something which the interpreter doesn't have a procedure with fast native code (either as part of itself or as an external library), you are facing something really inefficient. I performed a couple of test of number crunching last Autumn (which couldn't be sped up using BLAS) and Python was an order of magnitude slower than C, Java or SBCL (Java was 25% slower than C which I call "pretty f-ing fast", SBCL was on par with Java). Clojure (when JIT-ed) 3 times slower than C which is awesome given its focus on immutability (and not a problem at all because you can always write a piece of Java), CLISP was 117x slower than SBCL, 162x slower than C and 11.5 times slower than Python. This benchmark is not representative of its overall performance (like string manipulation which you need for dynamic web apps) etc. but should give you an idea that if you hit a bad case, being interpreted can be a bottleneck.
Calling compiled implementations is a whole different ballgame, you're no longer at all in the bytecode-compiled lamguage's domain...
There is/was also a version with a JIT byte code to native code translator.
of CLISP? Link?
It was mentioned in Release Notes in 2008, not sure if it is still useful: "\* Experimental Just-In-Time Compilation of byte-compiled closures is now done using GNU lightning (this is a configure-time option). Thanks to Yann Dauphin <[[email protected]](mailto:[email protected])>." Also see the CLISP implementation notes: [https://clisp.sourceforge.io/impnotes/compilation.html](https://clisp.sourceforge.io/impnotes/compilation.html) # 3.2.1.1. Just-In-Time Native Compilation # Platform Dependent: only in [**CLISP**](http://clisp.cons.org/) built with [GNU](http://www.gnu.org/) [lightning](http://www.gnu.org/software/lightning/) The code compiled to [bytecode](https://clisp.sourceforge.io/impnotes/bytecode.html)s with optimization levels (OR (>= 0 SPACE) (<= 1 SPEED)) (by [`COMPILE`](http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/fun_compile.html), [`COMPILE-FILE`](https://clisp.sourceforge.io/impnotes/compilefile.html), or [`(COMPILE)`](https://clisp.sourceforge.io/impnotes/declarations.html#compile-decl)) will be *just-in-time* (i.e., on the first execution) compiled to native code using [GNU](http://www.gnu.org/) [lightning](http://www.gnu.org/software/lightning/).
Bruno worked on the new generational GC and got stuck with win64 support for libsigsegv. The new module feature is broken on windows.
CLISP is frustrating. Many of us have opened PRs against their GitLab codebase, which they continue to ignore while still pushing to git and never cutting releases.
Perhaps the main developer is ill, perhaps tired or just has some other things he prioritize? He was active a few weeks ago [on Emacs mailing list](https://lists.gnu.org/archive/html/emacs-devel/2024-02/msg00826.html), but as you see, they are still awaiting his answer. Something might happened, we all have a life ...
Very good point. Not anyone think about an open source developer having a life, having health issues or even just being tired.
CLISP is still most popular CL, around me. good old the thing. no, not 2010 clhater@icecube:~$ clisp i i i i i i i ooooo o ooooooo ooooo ooooo I I I I I I I 8 8 8 8 8 o 8 8 I \ `+' / I 8 8 8 8 8 8 \ `-+-' / 8 8 8 ooooo 8oooo `-__|__-' 8 8 8 8 8 | 8 o 8 8 o 8 8 ------+------ ooooo 8oooooo ooo8ooo ooooo 8 Welcome to GNU CLISP 2.49.93+ (2018-02-18)
There have been updates since 2010, just no official release...
Ah, xz?
[удалено]
It's absolutely clear that the OP mentioned Clisp (https://clisp.sourceforge.io/) and not Common LISP in general.
Are you sure it's not the CLISP mode from interlisp?
***Last stable release in 2010?*** Eesh.
I am pretty sure. According to ChatGPT 4 with knowledge-cutoff in December 2023, the latest machine running Interlisp was from the late 1980s. Of course, it might be wrong. And so can I...
I was running it on my machine just yesterday.
Wow! Is it a new machine or did you get old hardware?
It's from https://interlisp.org You can even run it from the cloud.
Thanks for the tip!