Hacker News new | ask | show | jobs
by muuh-gnu 4905 days ago
OK, let me correct myself: No competitive free implementation existed able to take a leading position and bootstrap the ecosystem, like gcc, cpython, perl and javac did for their respective language ecosystems.

I did not intend to imply that nothing. existed. whatsoever. cmucl, gcl (akcl) and clisp even today are insignificant also-rans and basically unmaintained abandonware.
3 comments
lispm 4905 days ago
CMUCL was from the start very significant.

DEC Common Lisp was based on CMUCL. LispWorks was based on CMUCL. Scieneer Common Lisp is also based on CMUCL.

SBCL is a fork of CMUCL. SBCL is very popular in the 'free software' Lisp community - it's just a repackaged CMUCL.

Lot's of other Lisp implementations took and still are taking code from CMUCL, since it is 'Public Domain'. Free software.

Btw., CMUCL still has monthly releases.

AKCL spawned several implementations. Including GNU Common Lisp (GCL), which was widely used for some time - in combination with GCC.

GCL has been long used to run Maxima, the free version of Macsyma.

AKCL/GCL is nowadays ECL. Another fork. Which is maintained until today. Again ECL is possible because GCL was Free Software.

link
JabavuAdams 4905 days ago
The paradox of choice.

One implementation that's good for 80% of users will gain more traction than 10 implementations where each user has to figure out which one to use.

Lisp attracts maximizers, while satisficers are more successful at delivering software to real people.

link
lispm 4905 days ago
> No competitive free implementation existed able to take a leading position and bootstrap the ecosystem, like gcc, cpython, perl and javac did for their respective language ecosystems.

it was never a goal in the Lisp community to develop a single unified or leading implementation. This has nothing to do with 'free software' or not.

link
randallsquared 4905 days ago
"it was never a goal in the Lisp community to develop a single unified or leading implementation"

...and that's one reason it hasn't ever achieved critical mass: it's so easy to write software that only works on one implementation that the various CLs effectively compete with each other on the same level that each is competing with other rapid development languages. It wasn't CL vs Python vs PHP, but instead CMUCL vs Python vs SBCL vs Lispworks vs PHP vs Allegro. Scheme has a similar problem. These are the problems that come from having a standard instead of a canonical implementation, in my opinion. Canonical implementations promote growth in a way that a standard for a language doesn't.

link
lispm 4905 days ago
Yeah, and Python competes against Ruby against Perl against Javascript against Python 3 against Perl 6. Without sharing any code. And you win almost nothing. CPython, Perl, Ruby, ... are all slow scripting languages. With the newest implementation, Ruby, being the slowest programming language of all.

CL implementations can share a lot of code.

I've just compiled Mark Tarver's Shen in another Lisp by just changing less than ten lines of code. It took me ten minutes.

link
spacemanaki 4905 days ago
I've struggled with various Scheme programs not working in different implementations (mostly code from books like Lisp in Small Pieces) and have heard plenty about the fragmented Scheme landscape, but is this really such a big problem with Common Lisp? And is/was that really a big reason why Lisp has failed to catch on? (being genuine here, I have no idea really about the history and have only use CL a bit)

It seems to me that there are plenty of more popular languages with a similar glut of implementations: there are multiple JVM vendors, multiple implementations of Java (Sun/Oracle and now Dalvik, ...), many C and C++ compilers, etc...

This is total speculation, but it is perhaps because things like threads and networking were not part of the Common Lisp standard that there are fragmentation issues that impeded adoption? Or do you still think that canonical implementation vs language standard is that much better, in almost all cases?

link
jjwiseman 4905 days ago
In 2002 I was trying to use free Lisps in production and finding it untenable due to serious bugs in fundamental areas like network sockets, and terrible support for threads. I was also surprised that implementors didn't seem to take these issues seriously.

It was very disappointing compared to my experience using commercial Lisps like Allegro Common Lisp and Macintosh Common Lisp in grad school in the mid 90s. They weren't perfect, but MCL on a machine with lots of memory was a pleasure I will always remember.

link