7 ms·

I've read this story a couple times as it's popped up on the internet in different places. I've enjoyed it each time because it promises that lisp is an uber-po

I've read this story a couple times as it's popped up on the internet in different places. I've enjoyed it each time because it promises that lisp is an uber-powerful and easy (?) language. I'm always curious though: what's the other side of the story? Why is lisp always rejected? I started programming seriously (for money) in 2009, and when we needed a language we went with python because it had better math/science libraries than Java and much more libraries in general than clojure/lisp/ocaml. I confess I like the functional languages and like using some of their features in python. Was the no-libraries dealbreaker for the "pure" functional languages also true in 1999, which led google to java? Or maybe there are complex meta-programming bugs you can generate in the functional languages (and elsewhere) that are the dealbreaker? Or what?

lisper 7y ago
> Why is lisp always rejected? It isn't always. I have a consulting gig for a chip design company that uses Common Lisp internally. It's one of their principal competitive advantages. But mainly it's a vicious cycle: no one uses it because no one uses it. Employers don't use it because they think (mostly correctly) that they can't find CL coders, and no one learns CL because no one hires CL coders.
- maliker 7y ago
  Always great to hear there are companies out there thriving with these more powerful languages. The tired example I always turn to is Ocaml being the language for all the code at janestreet (~900 employees). I've always been annoyed by the "there are no X coders" argument. Coding skills are broadly transferrable. My team's code base is all python, and we've had successful team members who'd previously worked only in javascript, Java, C#, etc. When we tell recruiters that any of these languages will do, they hate that. Oof.
erikpukinskis 7y ago
I think the key metric for programming language popularity is something like “when someone makes a thing work, how easy is it for someone else a) to find out about it b) understand what’s happening, and c) shoehorn the solution into their own janky application”.
- maliker 7y ago
  Some combination of easy integration and a big ecosystem of active development? Makes a lot of sense to me.
_bxg1 7y ago
http://winestockwebdesign.com/Essays/Lisp_Curse.html http://winestockwebdesign.com/Essays/Lisp_Curse.html
oddity 7y ago
One of the key selling points of lisp is that it allows you to easily build a language that more closely maps to the problem you're trying to solve. In the 1970s, this was powerful because parsing was an active area of research. Today, parsing is one of the least interesting problems in language design (unless you're C++ or based on natural language). Most of the effort of spinning up a new language is in the backend (optimization and error checking), where lisp doesn't offer a compelling advantage (well, writing folding rules in C is a total pain, but this is a recursive problem... I can just write a code generator).
- maliker 7y ago
  So maybe other languages have finally beat lisp at its own game? Makes sense from the wave of functional language features becoming popular in the 2010s.
  - oddity 7y ago
    It's not necessarily that they beat lisp at its own game. I still think the tight integration story of lisp is unmatched nearly anywhere else, but, when viewed holistically, lisp's advantages have become less compelling over time for people who have already written software outside of the ecosystem. It suffers from a lot of the same problems as smalltalk.
- _pmf_ 7y ago
  > Most of the effort of spinning up a new language is in the backend (optimization and error checking), where lisp doesn't offer a compelling advantage SBCL literally allows writing compiler intrinsics (and I'm talking about native machine code, not bytecode) at runtime out of the box: https://www.pvk.ca/Blog/2014/03/15/sbcl-the-ultimate-assembly-code-breadboard/ https://www.pvk.ca/Blog/2014/03/15/sbcl-the-ultimate-assembl...
closeparen 7y ago
Languages like Lisp, APL, and Haskell reward extraordinary skill with extraordinary power. If you're a researcher or an early-stage startup founder, that's great. You want your little band of geniuses to have the maximum possible leverage. But if you're an engineering leader at a large company, the last thing you want is an asset in your portfolio that only extraordinarily skilled people can work on. What if they quit? What if your company's stature declines and you can't attract such people anymore? What if a more pressing problem comes along and you want to deploy them elsewhere? So we get languages with short learning curves and low ceilings (Go!) instead. Except in performance critical contexts, where it can’t be helped, but C++ already won that one.
- RookyNumbas 7y ago
  This seems correct to me. The last two things I've learned were javscript/node/react and Haskell. I had never touched js or html before, but within two days I had a pretty decent web app up and running. It was something that could (and did) provided value for a business. Two days after starting Haskell I had essentially nothing to show for it except a feeling that I has a huge amount to learn before I could be productive. Even a year later I still have a huge amount to learn.
- deleted 7y ago
  [deleted]
- stefan_ 7y ago
  No, that's not it. The world is not run by functional programming languages, despite their "leverage". The word you are looking for is "quirky". Of course, the same is true for the programmers. They are not extraordinarily smart, they make quirky technical decisions. Interest in functional programming solves technical problems as much as your choice of editor.
- zbentley 7y ago
  I don't think that extraordinary skill and power are linked at the language level. Within a rounding error, an "extraordinarily skilled" developer can probably be just as much of an asset to a company with an "extraordinarily powerful" language as they could with an "ordinarily powerful" (read: mainstream) one. Now, super-skilled folks might like playing with Lisp or Haskell or what-have-you (and if it affects your ability to retain them and get value from them, you might want to let them), but their skilled-ness is usually transferable to other languages if the need arises.
mnm1 7y ago
Not to be pedantic, but since Clojure is a hosted JVM language (as one of a few platforms it's hosted on) and has full interoperability with Java, by definition it has more libraries than Java as it has all the Java libraries plus all the clojure libraries. So definitely not library support in recent years but maybe back in the days. Performance was an issue early on as well, but that's certainly not the case now. Clojure is extremely performant and outperforms pretty much all the popular interpreted languages easily.
- didibus 7y ago
  Yup, it can also now use all of the Python libraries as well: https://github.com/cnuernber/libpython-clj https://github.com/cnuernber/libpython-clj So it now has all of Java, JavaScript and Python ;)
  - mnm1 7y ago
    Or clojure, java, scala, kotlin, python, ruby, JavaScript, c, cpp, r all together with graal vm. https://www.graalvm.org/ https://www.graalvm.org/
  - vips7L 7y ago
    This is really a non-argument since Graal [0] can do anything JVM plus JS, R, Python, Ruby, and LLVM. [0] https://www.graalvm.org/ https://www.graalvm.org/
    - didibus 7y ago
      Polyglot programming with Graal will eventually be awesome, but it isn't yet. If it was, I'd use Graal to use Python libraries from Clojure, but I'm not, because it still has some ways to go. So for now, I use Pandas, Numpy, matplotlib, and all that from Clojure using libpython-clj. Which is the biggest issue with graal-python currently, how to leverage all the C-based libraries. That's where libpython-clj excels over Graal.
      - vips7L 7y ago
pritovido 7y ago
From my point of view, Lisp gives programmers too much power. No company wants giving a programmer so much concentrated power, they want it distributed around the workforce, and people disposable. Replace them whenever is needed. With lisp you can modify your development platform to suit your needs, In practice, over time you create your own programming language. You create your DSP(Domain specific language) with your own systems. This is not standard. You are dependent on the programmer. Companies prefer to buy "solutions"(packages,environments) from companies and depend on those solutions. They are standard and you can hire people trained on them. Replace them if needed and make people continue the work that someone else left. That is because "solutions" have open documentation, designed by people that are able to draw beautiful diagrams, lots of books, videos on the Internet, but lisp gurus have all the info in their heads. Bugs are way easier(orders of magnitude) to find with meta programming. In fact you can create a subsystem that finds all bugs so you don't have to.
- fctorial 7y ago
  > Bugs are way easier(orders of magnitude) to find with meta programming. In fact you can create a subsystem that finds all bugs so you don't have to. This needs some explanation.
  - jiggawatts 7y ago
    In homoiconic languages like Lisp or Mathematica the program is just "data" and can be transformed arbitrarily, even at runtime. This allows you to write utility functions that transform programs in all sorts of useful ways to find bugs. A simple example is to just transform the program so that it traces whatever you want to a log, much like Visual Studio Intellitrace, but completely flexible. You can do things like replace all floating point numbers with a "dual number" (a 2-number tuple) where the first number is always rounded down when operated on, and the second number is always rounded up. This then lets you robustly determine if your numerical accuracy is guaranteed to be within a certain range (due to floating point error, at any rate). You can symbolically evaluate programs involving random variables using their distributions instead, symbolically working out the products of functions instead of scalar values. This allows things like video poker or lottery programs to be robustly evaluated for average payout even if some of the plays are rare, such as jackpots. A friend of mine did this using Mathematica back in the early 2000s. It goes on and on...
didibus 7y ago
> Why is lisp always rejected? My best guess is performance. In the 70s, computers were slow. When the decade started, the competing languages of the time were Fortran, Algol and Cobol. All were imperative languages with manual memory management that would compile directly to hardware and had semantics very close to that of the hardware. On the other hand, at that time, Lisp was this high level thing, garbage collected, dynamic types, semantics more removed from the hardware, etc. Meaning Lisp was much less performant. Then in 1972, came C. A language inspired by Algol and Fortran, using very similar imperative semantics and constructs, but changing the syntax slightly to what is now the common syntax most programming languages use. The whole point of C was to be crazy fast, and for compilers to be easy to write so it could be portable as well. C's biggest move was that Unix was re-written in it. Before that, operating system kernels were implemented in assembly language! Unix was implemented in assembly language! Think about that, performance was critical in the 70s for a kernel. Once Unix was re-written in C, and C proved to be performant enough to run a Kernel, its momentum started growing. Unix won the OS war, and slowly everyone was using computers running Unix, meaning that it had a C API. What happens when the most popular OS has binding in a specific language, more people choose that language to write programs for that OS. Thus C became ever so popular. Lisp was there, but not leveraging Unix as much, and still much too slow. And this was the beginning of the momentum for C, it only accelerated since then. Linux came around, also in C, Windows, also in C, all major OS were in C. So C like syntax, semantics and programming constructs became the norm, and was what got thought in school and uni, etc. Fast forward to today, and Lisp is finally "fast enough" to be used. We finally reached a point where you can have useful programs in slower languages, like Python, Java, JavaScript, C# all demonstrate. But how can you beat 50 years of momentum in C like languages? That's what most everyone knows. That's why imperative, mutable, procedural statement based, with C like semantics and syntax is still the norm, and all other languages that aren't struggle to get a foothold.
- maliker 7y ago
  Interesting. Choosing languages to get work done in the 2010s has insulated my team from a lot of these historical forces; interpreted and garbage collected has always been more than fast enough. I can see how earlier businesses would choose a different route.
abecedarius 7y ago
I was at JPL on this Lisp project, and left for Silicon Valley. First place I interviewed was Peter Norvig's startup (that's how I think of it, though it had actual cofounders and he was an employee). He told me if they'd known they could hire Lispers, they wouldn't be using Java. Just one datapoint on how things were trending then.
- maliker 7y ago
  Sounds like the lisp programmer skillset doesn't have a strong overlap with the java/python/javascript programmer skillset. Makes me want to learn more lisp. :)
  - dreamcompiler 7y ago
    There is some overlap with javascript because it's the only one of the three that offers uncrippled lambdas. Or I may be wrong about that; did Java finally add them?
    - mst 7y ago
      ES6 offers sane lambdas via => and lexical scoping via let. I can actually program in it without wanting to stab myself, which has previously mostly been limited to perl and various lisps ;)
    - skissane 7y ago
      Java has had lambdas since Java 8. (I don’t know if you’d consider them “crippled” or not; they are less crippled than Python’s.)
      - cbsmith 7y ago
        Even before Java 8, Java had inner classes that if you squinted at them right looked like very syntactically awkward lambdas (indeed, Java 8 lambdas compile down to something that looks an awfully lot like an inner class).
slifin 7y ago
In the Clojure community we just got access to all of python http://gigasquidsoftware.com/blog/2020/01/10/hugging-face-gpt-with-clojure/ http://gigasquidsoftware.com/blog/2020/01/10/hugging-face-gp... I think learning Clojure will continue to pay off the reach you can get with it in one language is insane
- hatmatrix 7y ago
  I think it was on HN that I read recently, but I heard some complaints that it's a language that you develop on, but not a language that you develop. Rich Hickey develops it and lets everyone use it. May be good or bad but that seems to have turned away some good developers. So anyway I don't know if that has any impact on its long-term future.
fulafel 7y ago
What led Google to Java is a good question - I'd guess they wanted to standardize on something likely have longevity, because they knew they couldn't predict the success of good languages, so the same old reason why less all the other corporations usually do it. Good that JVM eventually started to get nice languages like Clojure, Scala, etc - despite being the platform of choice of corporate Vorlons.
cbsmith 7y ago
I actually worked at Sun as a Java architect back in this era, and consulted with the JPL as they were adopting Java. In the end, the JPL isn't a software shop. The glory is in the hardware end of things. As a consequence, you want something that has a broad pool of talent, tooling, vendors, etc. to draw upon for support. It also was a more natural transition from their extant Fortran & C code. LISP's marketshare had already declined significantly at that point, and it's primary remaining user base didn't have very similar needs to the JPL. When you're an outlier for a language with small marketshare, that means the tools, skills, vendors, etc. aren't going to be as well suited to what you're trying to achieve. tl;dr: when you're in a domain where you aren't trying to be quite so innovative, it helps to run with the pack.

lisper 7y ago

> Why is lisp always rejected? It isn't always. I have a consulting gig for a chip design company that uses Common Lisp internally. It's one of their principal competitive advantages. But mainly it's a vicious cycle: no one uses it because no one uses it. Employers don't use it because they think (mostly correctly) that they can't find CL coders, and no one learns CL because no one hires CL coders.

maliker 7y ago
Always great to hear there are companies out there thriving with these more powerful languages. The tired example I always turn to is Ocaml being the language for all the code at janestreet (~900 employees). I've always been annoyed by the "there are no X coders" argument. Coding skills are broadly transferrable. My team's code base is all python, and we've had successful team members who'd previously worked only in javascript, Java, C#, etc. When we tell recruiters that any of these languages will do, they hate that. Oof.

erikpukinskis 7y ago

I think the key metric for programming language popularity is something like “when someone makes a thing work, how easy is it for someone else a) to find out about it b) understand what’s happening, and c) shoehorn the solution into their own janky application”.

maliker 7y ago
Some combination of easy integration and a big ecosystem of active development? Makes a lot of sense to me.

_bxg1 7y ago

http://winestockwebdesign.com/Essays/Lisp_Curse.html http://winestockwebdesign.com/Essays/Lisp_Curse.html

oddity 7y ago

One of the key selling points of lisp is that it allows you to easily build a language that more closely maps to the problem you're trying to solve. In the 1970s, this was powerful because parsing was an active area of research. Today, parsing is one of the least interesting problems in language design (unless you're C++ or based on natural language). Most of the effort of spinning up a new language is in the backend (optimization and error checking), where lisp doesn't offer a compelling advantage (well, writing folding rules in C is a total pain, but this is a recursive problem... I can just write a code generator).

maliker 7y ago
So maybe other languages have finally beat lisp at its own game? Makes sense from the wave of functional language features becoming popular in the 2010s.
- oddity 7y ago
  It's not necessarily that they beat lisp at its own game. I still think the tight integration story of lisp is unmatched nearly anywhere else, but, when viewed holistically, lisp's advantages have become less compelling over time for people who have already written software outside of the ecosystem. It suffers from a lot of the same problems as smalltalk.
_pmf_ 7y ago
> Most of the effort of spinning up a new language is in the backend (optimization and error checking), where lisp doesn't offer a compelling advantage SBCL literally allows writing compiler intrinsics (and I'm talking about native machine code, not bytecode) at runtime out of the box: https://www.pvk.ca/Blog/2014/03/15/sbcl-the-ultimate-assembly-code-breadboard/ https://www.pvk.ca/Blog/2014/03/15/sbcl-the-ultimate-assembl...

closeparen 7y ago

Languages like Lisp, APL, and Haskell reward extraordinary skill with extraordinary power. If you're a researcher or an early-stage startup founder, that's great. You want your little band of geniuses to have the maximum possible leverage. But if you're an engineering leader at a large company, the last thing you want is an asset in your portfolio that only extraordinarily skilled people can work on. What if they quit? What if your company's stature declines and you can't attract such people anymore? What if a more pressing problem comes along and you want to deploy them elsewhere? So we get languages with short learning curves and low ceilings (Go!) instead. Except in performance critical contexts, where it can’t be helped, but C++ already won that one.

RookyNumbas 7y ago
This seems correct to me. The last two things I've learned were javscript/node/react and Haskell. I had never touched js or html before, but within two days I had a pretty decent web app up and running. It was something that could (and did) provided value for a business. Two days after starting Haskell I had essentially nothing to show for it except a feeling that I has a huge amount to learn before I could be productive. Even a year later I still have a huge amount to learn.
deleted 7y ago
[deleted]
stefan_ 7y ago
No, that's not it. The world is not run by functional programming languages, despite their "leverage". The word you are looking for is "quirky". Of course, the same is true for the programmers. They are not extraordinarily smart, they make quirky technical decisions. Interest in functional programming solves technical problems as much as your choice of editor.
zbentley 7y ago
I don't think that extraordinary skill and power are linked at the language level. Within a rounding error, an "extraordinarily skilled" developer can probably be just as much of an asset to a company with an "extraordinarily powerful" language as they could with an "ordinarily powerful" (read: mainstream) one. Now, super-skilled folks might like playing with Lisp or Haskell or what-have-you (and if it affects your ability to retain them and get value from them, you might want to let them), but their skilled-ness is usually transferable to other languages if the need arises.

mnm1 7y ago

Not to be pedantic, but since Clojure is a hosted JVM language (as one of a few platforms it's hosted on) and has full interoperability with Java, by definition it has more libraries than Java as it has all the Java libraries plus all the clojure libraries. So definitely not library support in recent years but maybe back in the days. Performance was an issue early on as well, but that's certainly not the case now. Clojure is extremely performant and outperforms pretty much all the popular interpreted languages easily.

didibus 7y ago
Yup, it can also now use all of the Python libraries as well: https://github.com/cnuernber/libpython-clj https://github.com/cnuernber/libpython-clj So it now has all of Java, JavaScript and Python ;)
- mnm1 7y ago
  Or clojure, java, scala, kotlin, python, ruby, JavaScript, c, cpp, r all together with graal vm. https://www.graalvm.org/ https://www.graalvm.org/
- vips7L 7y ago
  This is really a non-argument since Graal [0] can do anything JVM plus JS, R, Python, Ruby, and LLVM. [0] https://www.graalvm.org/ https://www.graalvm.org/
  - didibus 7y ago
    Polyglot programming with Graal will eventually be awesome, but it isn't yet. If it was, I'd use Graal to use Python libraries from Clojure, but I'm not, because it still has some ways to go. So for now, I use Pandas, Numpy, matplotlib, and all that from Clojure using libpython-clj. Which is the biggest issue with graal-python currently, how to leverage all the C-based libraries. That's where libpython-clj excels over Graal.
    - vips7L 7y ago

pritovido 7y ago

From my point of view, Lisp gives programmers too much power. No company wants giving a programmer so much concentrated power, they want it distributed around the workforce, and people disposable. Replace them whenever is needed. With lisp you can modify your development platform to suit your needs, In practice, over time you create your own programming language. You create your DSP(Domain specific language) with your own systems. This is not standard. You are dependent on the programmer. Companies prefer to buy "solutions"(packages,environments) from companies and depend on those solutions. They are standard and you can hire people trained on them. Replace them if needed and make people continue the work that someone else left. That is because "solutions" have open documentation, designed by people that are able to draw beautiful diagrams, lots of books, videos on the Internet, but lisp gurus have all the info in their heads. Bugs are way easier(orders of magnitude) to find with meta programming. In fact you can create a subsystem that finds all bugs so you don't have to.

fctorial 7y ago
> Bugs are way easier(orders of magnitude) to find with meta programming. In fact you can create a subsystem that finds all bugs so you don't have to. This needs some explanation.
- jiggawatts 7y ago
  In homoiconic languages like Lisp or Mathematica the program is just "data" and can be transformed arbitrarily, even at runtime. This allows you to write utility functions that transform programs in all sorts of useful ways to find bugs. A simple example is to just transform the program so that it traces whatever you want to a log, much like Visual Studio Intellitrace, but completely flexible. You can do things like replace all floating point numbers with a "dual number" (a 2-number tuple) where the first number is always rounded down when operated on, and the second number is always rounded up. This then lets you robustly determine if your numerical accuracy is guaranteed to be within a certain range (due to floating point error, at any rate). You can symbolically evaluate programs involving random variables using their distributions instead, symbolically working out the products of functions instead of scalar values. This allows things like video poker or lottery programs to be robustly evaluated for average payout even if some of the plays are rare, such as jackpots. A friend of mine did this using Mathematica back in the early 2000s. It goes on and on...

didibus 7y ago

> Why is lisp always rejected? My best guess is performance. In the 70s, computers were slow. When the decade started, the competing languages of the time were Fortran, Algol and Cobol. All were imperative languages with manual memory management that would compile directly to hardware and had semantics very close to that of the hardware. On the other hand, at that time, Lisp was this high level thing, garbage collected, dynamic types, semantics more removed from the hardware, etc. Meaning Lisp was much less performant. Then in 1972, came C. A language inspired by Algol and Fortran, using very similar imperative semantics and constructs, but changing the syntax slightly to what is now the common syntax most programming languages use. The whole point of C was to be crazy fast, and for compilers to be easy to write so it could be portable as well. C's biggest move was that Unix was re-written in it. Before that, operating system kernels were implemented in assembly language! Unix was implemented in assembly language! Think about that, performance was critical in the 70s for a kernel. Once Unix was re-written in C, and C proved to be performant enough to run a Kernel, its momentum started growing. Unix won the OS war, and slowly everyone was using computers running Unix, meaning that it had a C API. What happens when the most popular OS has binding in a specific language, more people choose that language to write programs for that OS. Thus C became ever so popular. Lisp was there, but not leveraging Unix as much, and still much too slow. And this was the beginning of the momentum for C, it only accelerated since then. Linux came around, also in C, Windows, also in C, all major OS were in C. So C like syntax, semantics and programming constructs became the norm, and was what got thought in school and uni, etc. Fast forward to today, and Lisp is finally "fast enough" to be used. We finally reached a point where you can have useful programs in slower languages, like Python, Java, JavaScript, C# all demonstrate. But how can you beat 50 years of momentum in C like languages? That's what most everyone knows. That's why imperative, mutable, procedural statement based, with C like semantics and syntax is still the norm, and all other languages that aren't struggle to get a foothold.

maliker 7y ago
Interesting. Choosing languages to get work done in the 2010s has insulated my team from a lot of these historical forces; interpreted and garbage collected has always been more than fast enough. I can see how earlier businesses would choose a different route.

abecedarius 7y ago

I was at JPL on this Lisp project, and left for Silicon Valley. First place I interviewed was Peter Norvig's startup (that's how I think of it, though it had actual cofounders and he was an employee). He told me if they'd known they could hire Lispers, they wouldn't be using Java. Just one datapoint on how things were trending then.

maliker 7y ago
Sounds like the lisp programmer skillset doesn't have a strong overlap with the java/python/javascript programmer skillset. Makes me want to learn more lisp. :)
- dreamcompiler 7y ago
  There is some overlap with javascript because it's the only one of the three that offers uncrippled lambdas. Or I may be wrong about that; did Java finally add them?
  - mst 7y ago
    ES6 offers sane lambdas via => and lexical scoping via let. I can actually program in it without wanting to stab myself, which has previously mostly been limited to perl and various lisps ;)
  - skissane 7y ago
    Java has had lambdas since Java 8. (I don’t know if you’d consider them “crippled” or not; they are less crippled than Python’s.)
    - cbsmith 7y ago
      Even before Java 8, Java had inner classes that if you squinted at them right looked like very syntactically awkward lambdas (indeed, Java 8 lambdas compile down to something that looks an awfully lot like an inner class).

slifin 7y ago

In the Clojure community we just got access to all of python http://gigasquidsoftware.com/blog/2020/01/10/hugging-face-gpt-with-clojure/ http://gigasquidsoftware.com/blog/2020/01/10/hugging-face-gp... I think learning Clojure will continue to pay off the reach you can get with it in one language is insane

hatmatrix 7y ago
I think it was on HN that I read recently, but I heard some complaints that it's a language that you develop on, but not a language that you develop. Rich Hickey develops it and lets everyone use it. May be good or bad but that seems to have turned away some good developers. So anyway I don't know if that has any impact on its long-term future.

fulafel 7y ago

What led Google to Java is a good question - I'd guess they wanted to standardize on something likely have longevity, because they knew they couldn't predict the success of good languages, so the same old reason why less all the other corporations usually do it. Good that JVM eventually started to get nice languages like Clojure, Scala, etc - despite being the platform of choice of corporate Vorlons.

cbsmith 7y ago

I actually worked at Sun as a Java architect back in this era, and consulted with the JPL as they were adopting Java. In the end, the JPL isn't a software shop. The glory is in the hardware end of things. As a consequence, you want something that has a broad pool of talent, tooling, vendors, etc. to draw upon for support. It also was a more natural transition from their extant Fortran & C code. LISP's marketshare had already declined significantly at that point, and it's primary remaining user base didn't have very similar needs to the JPL. When you're an outlier for a language with small marketshare, that means the tools, skills, vendors, etc. aren't going to be as well suited to what you're trying to achieve. tl;dr: when you're in a domain where you aren't trying to be quite so innovative, it helps to run with the pack.