3 ms·

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

> * 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.
- lazyjones 14y ago
  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.
  - lispm 14y ago
    cmucl has native code generation for a VERY long time.

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.
lazyjones 14y ago
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.
- lispm 14y ago
  cmucl has native code generation for a VERY long time.