Hacker News new | ask | show | jobs
by muuh-gnu 4904 days ago
> If it is so good why ain't it is used more?

* Weird syntax (for most people).

* No free implementations existed during a key period (80s, 90s) so no initial traction, no useful libraries and killer apps which would pull the whole ecosystem. Implementations didnt even exist for commodity hardware.

* The commercial implementations cost too much, so they suffocated the ecosystem. People preferred coding for free in C or Perl, than paying an arm and a leg for Lisp. So they wrote all the useful libs in C, Perl, Java and Python instead of Lisp.

* No canonical implementation, late and incomplete standardisation, which led to extreme fragmentation, which further killed off the growth of the ecosystem. Instead of writing useful libraries, Lispers wasted effort writing 1001 incompatible implementations of the same basic system.

So to summarize, I'd say the Lisp ecosystem is _still_ suffering the consequences of the bad strategic decisions made 30-40 years ago.

But it is slowly but steadily healing and improving, especially the last few years. It has a high-quality free implementation with SBCL [1], consolidated CPAN-like library management with Quicklisp [2] and a IDE with Emacs-based SLIME [3]. Everything is getting better.

[1] http://www.sbcl.org/

[2] http://www.quicklisp.org/beta/

[3] http://common-lisp.net/project/slime/

5 comments

To take the reverse perspective, why it is coming up now, I think that in the 80s and 90s, the increase in processing power came in the form of faster processors. Then, pretty suddenly, really, over the past decade, that trend hit a wall, and instead we're getting more cores, but at the same speed. This rekindled the interest in concurrent programming, and Lisps have a distinctive edge in that space.
Add in the flame wars and jerks on Usenet that crapped on many folks that were interested. People went off in search of friendly enivironments and ended up in C, Perl and Python...
> * No free implementations existed during a key period (80s, 90s) so no initial traction, no useful libraries and killer apps which would pull the whole ecosystem. Implementations didnt even exist for commodity hardware.

Emacs LISP (OK, a limited dialect) was available and so was CMUCL (full implementation), which I believe was used for teaching in 1992 when I first got in contact with LISP at our uni ...

Also, back then (80's and 90's) most people still paid an arm and a leg for C, Modula and Pascal on their platforms, so that can't have been an issue. My take is that LISP implementations were too slow to justify their use for most people over faster compiled languages. Whether you paid for the language or not, you expected to be able to get the most out of your hardware.

I used LISP for several AI classes in the early 90s. My final big class project could do things that were impressive compared to my (non-AI) programs in C++ -- but debugging was absolute hell, because relatively trivial changes would cause the Unix workstation I was working on to run out of stack space running my code. I never used LISP again after that.
> faster compiled languages

Lisp is a compiled language.

For that matter, it's a damn fast one, too. The Lisp implementation of PCREs are actually faster than Perl's, by some benchmarks.

I don't want to start a tangent about benchmarks and their relevance, but it's clear that Lisp performance isn't a limiting factor.

Whenever Lisp's history is mentioned we get another free replay of this classic "who's on first" bit:

A: Lisp didn't succeed in part because it was slow

B: What? Lisp isn't slow!

Do you see the problem? No, it isn't slow now, but it was slow and a resource hog and that is a legitimate variable that may have negatively affected uptake during key points in its history. Times have changed, implementations have improved, resources have become less scarce, but the past is still the past.

C is still faster at common tasks and back then, code from readily available C and Pascal compilers was much faster than CMUCL or ELISP (both had a bytecode interpreter only AFAIR). My point is that in the 80s and 90s, computers were much slower and a factor of 2 was a big deal then, especially for professional developers who had to write well-performing applications, though nowdays a good language is "fast enough" if it's only half as fast as C.
cmucl has native code generation for a VERY long time.
> IDE with Emacs-based SLIME

That's also not new. Common Lisp has an Emacs IDE since before the dark ages. It was called ILISP. Every Lisp + Emacs user was using it. Well, Franz had/has their own Emacs interface called ELI.

> No free implementations existed during a key period

BS.

CMUCL. AKCL. CLISP.

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.

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.

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.

> 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.

"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.

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.

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?

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.

I was paid to develop in Lisp (in a research environment) from '89 to '95 and from what I recall the commercial Lisp environments were way better than the free implementations - at least on the hardware we used (Sun 3s, Sun 4s and the DEC Alphas).
That's still true - for various criteria.