4 ms·

> 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

> 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/ http://www.sbcl.org/ [2] http://www.quicklisp.org/beta/ http://www.quicklisp.org/beta/ [3] http://common-lisp.net/project/slime/ http://common-lisp.net/project/slime/

mseebach 14y ago
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.
lispm 14y ago
> No free implementations existed during a key period BS. CMUCL. AKCL. CLISP.
- arethuza 14y ago
  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).
  - lispm 14y ago
    That's still true - for various criteria.
- muuh-gnu 14y 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.
  - lispm 14y 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.
    - JabavuAdams 14y 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.
  - lispm 14y 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.
    - randallsquared 14y ago
lispm 14y ago
> 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.
xradionut 14y ago
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...
lazyjones 14y ago
> * 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.
- colomon 14y ago
  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.
- chimeracoder 14y ago
  > 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.
  - fusiongyro 14y ago
    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.

mseebach 14y ago

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.

lispm 14y ago

> No free implementations existed during a key period BS. CMUCL. AKCL. CLISP.

arethuza 14y ago
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).
- lispm 14y ago
  That's still true - for various criteria.
muuh-gnu 14y 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.
- lispm 14y 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.
  - JabavuAdams 14y 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.
- lispm 14y 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.
  - randallsquared 14y ago

lispm 14y ago

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

xradionut 14y ago

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

lazyjones 14y ago

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

colomon 14y ago
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.
chimeracoder 14y ago
> 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.
- fusiongyro 14y ago
  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.