4 ms·

An order of magnitude "or more" is an extraordinary claim. The evidence just isn't there. > but which very few people use simply because there are very few pe

by mlyle 3y ago

An order of magnitude "or more" is an extraordinary claim. The evidence just isn't there. > but which very few people use simply because there are very few people using it. Ecosystems matter: they're one of the ways you get productivity.

lisper 3y ago
> An order of magnitude "or more" is an extraordinary claim. The evidence just isn't there. Let me clear: I am claiming that these kinds of productivity gains are possible, not that using Lisp will automatically give you a 10x improvement under all circumstances. And yes, I can give you concrete examples of demonstrable >10x productivity improvements which resulted in products succeeding where they otherwise would undoubtedly have failed. These are generally found in niche applications where there is a lot of domain knowledge that needs to be brought to bear. So you're not going to see big wins in, say, commodity consumer products, which is the reason that the wins don't get much press. But the evidence is definitely there if you look in the right places.
- marginalia_nu 3y ago
  If it gives such a productivity boost, why aren't LISP shops outcompeting other languages?
  - lisper 3y ago
    That's a good question without an easy answer, but there are two leading theories. One is that languages are infrastructure and it's really hard to replace infrastructure once it gets established (look at how much time it's taking for electric cars to replace gas-powered ones). The other is that Lisp's productivity boost allows individuals to get things done by themselves and so it tends to attract people who aren't good at collaborating (the famous "Lisp curse"). So on an individual level it's a win, but at an organizational level it might not be unless you manage it very carefully.
    - leetrout 3y ago
      > So on an individual level it's a win, but at an organizational level it might not be unless you manage it very carefully. This is why I choose Go many times over other languages. Its a bit easy to keep on the rails since it is so restrictive (at the cost of repetitive, explicit verbosity).
  - fidotron 3y ago
    Historically I think there's a very strong case that Symbolics did outperform others with their software productivity, especially in graphics. They had an ability to wade into certain domains and produce legitimately shockingly competitive products, which really should not have been possible. But I also think Lisp leads to spectacular burnout as I think it imposes a greater cognitive requirement on the part of the developer. A Symbolics graphics reel from 1989 https://www.youtube.com/watch?v=V4HXPJtym2Q https://www.youtube.com/watch?v=V4HXPJtym2Q This stuff was still in use on Final Fantasy 7 https://lunduke.substack.com/p/the-computers-used-to-do-3d-animation?s=r https://lunduke.substack.com/p/the-computers-used-to-do-3d-a...
    - kagevf 3y ago
      > it imposes a greater cognitive requirement on the part of the developer ... because of the "monotonous" syntax? That was a reason mentioned by L Peter Deutsch in Coders at Work ...
      - fidotron 3y ago
        I do think it's the relatively superficial uniformity of it, regardless of the level of abstraction at which you're operating, which eventually makes things crack. My hunch is top performing lisp devs are capable of holding more of this in their head at once than mere mortals. A key benefit of more conventional languages is you can limit the scope of your concerns and reasoning (within limits), however, that does prevent you from being able to make whole system optimisations, which is notably what Symbolics (at least in graphics) were outperforming everyone else at. What the Symbolics devs achieved seems to me only viable by having an unusually capable team focused on a specific domain for a long time, without too much diversion/distraction. The bus factor must have been horrific. This thread made me go off and look more into this, and I couldn't help thinking the software industry has really lost something with the commercial failure of these very deeply specialised and incredibly high end tools. (ICAD was the other). It's odd how people could justify spending huge amounts on the hardware just to run the software, but didn't want to pay for the software when it became possible to run it on just about anything, and so the software stops being developed.
- pkkm 3y ago
  > I can give you concrete examples of demonstrable >10x productivity improvements which resulted in products succeeding where they otherwise would undoubtedly have failed. Well, I would definitely be interested in these examples. I occasionally write Lisp (admittedly, Emacs Lisp rather than Common Lisp) and while I appreciate having macros and other metaprogramming tools at my fingertips, I've never encountered a situation in which their use was critically important. I can always replicated the thing I wanted to do in Python with a bit of boilerplate; if I had to choose, I would certainly take Python's huge ecosystem over Lisp's metaprogramming. Frankly, I don't think there have been any language silver bullets after structured programming and garbage collection. So I'm very skeptical of the claims of extreme Lisp productivity. I'm open to being convinced otherwise though.
  - lisper 3y ago
    The big wins are in niches that involve a lot of domain-specific knowledge. The two best examples that I was personally involved with were the NASA Deep Space One Remote Agent and the Meta chip design tool from Barefoot Networks (acquired by Intel in 2019). In the former case, an attempt was made to do the implementation in C++, which failed outright. In the latter case you can do a pretty direct apples-to-apples comparison of the design cycle time relative to off-the-shelf design tools. Meta lets you iterate in minutes what would take hours using standard tools. (To be fair, Meta does not do everything that the standard tools do, and before you can tape-out you have to do a few iterations on standard place-and-route and timing verification. But it's still a huge win over just using those for the entire design.)
    - FreakLegion 3y ago
      I have experience with EUROPA, which has gone on to have a long life independent of RAX (e.g. I believe it's still used via SACE for the ISS solar arrays). EUROPA is C++, not Lisp, even though Lisp isn't an unusual choice in AI planning.
      - lisper 3y ago
        > EUROPA is C++, Maybe it is now (I don't know -- I've been out of that field for over 20 years) but it wasn't then.

by mlyle 3y ago

lisper 3y ago

> An order of magnitude "or more" is an extraordinary claim. The evidence just isn't there. Let me clear: I am claiming that these kinds of productivity gains are possible, not that using Lisp will automatically give you a 10x improvement under all circumstances. And yes, I can give you concrete examples of demonstrable >10x productivity improvements which resulted in products succeeding where they otherwise would undoubtedly have failed. These are generally found in niche applications where there is a lot of domain knowledge that needs to be brought to bear. So you're not going to see big wins in, say, commodity consumer products, which is the reason that the wins don't get much press. But the evidence is definitely there if you look in the right places.

marginalia_nu 3y ago
If it gives such a productivity boost, why aren't LISP shops outcompeting other languages?
- lisper 3y ago
  That's a good question without an easy answer, but there are two leading theories. One is that languages are infrastructure and it's really hard to replace infrastructure once it gets established (look at how much time it's taking for electric cars to replace gas-powered ones). The other is that Lisp's productivity boost allows individuals to get things done by themselves and so it tends to attract people who aren't good at collaborating (the famous "Lisp curse"). So on an individual level it's a win, but at an organizational level it might not be unless you manage it very carefully.
  - leetrout 3y ago
    > So on an individual level it's a win, but at an organizational level it might not be unless you manage it very carefully. This is why I choose Go many times over other languages. Its a bit easy to keep on the rails since it is so restrictive (at the cost of repetitive, explicit verbosity).
- fidotron 3y ago
  Historically I think there's a very strong case that Symbolics did outperform others with their software productivity, especially in graphics. They had an ability to wade into certain domains and produce legitimately shockingly competitive products, which really should not have been possible. But I also think Lisp leads to spectacular burnout as I think it imposes a greater cognitive requirement on the part of the developer. A Symbolics graphics reel from 1989 https://www.youtube.com/watch?v=V4HXPJtym2Q https://www.youtube.com/watch?v=V4HXPJtym2Q This stuff was still in use on Final Fantasy 7 https://lunduke.substack.com/p/the-computers-used-to-do-3d-animation?s=r https://lunduke.substack.com/p/the-computers-used-to-do-3d-a...
  - kagevf 3y ago
    > it imposes a greater cognitive requirement on the part of the developer ... because of the "monotonous" syntax? That was a reason mentioned by L Peter Deutsch in Coders at Work ...
    - fidotron 3y ago
      I do think it's the relatively superficial uniformity of it, regardless of the level of abstraction at which you're operating, which eventually makes things crack. My hunch is top performing lisp devs are capable of holding more of this in their head at once than mere mortals. A key benefit of more conventional languages is you can limit the scope of your concerns and reasoning (within limits), however, that does prevent you from being able to make whole system optimisations, which is notably what Symbolics (at least in graphics) were outperforming everyone else at. What the Symbolics devs achieved seems to me only viable by having an unusually capable team focused on a specific domain for a long time, without too much diversion/distraction. The bus factor must have been horrific. This thread made me go off and look more into this, and I couldn't help thinking the software industry has really lost something with the commercial failure of these very deeply specialised and incredibly high end tools. (ICAD was the other). It's odd how people could justify spending huge amounts on the hardware just to run the software, but didn't want to pay for the software when it became possible to run it on just about anything, and so the software stops being developed.
pkkm 3y ago
> I can give you concrete examples of demonstrable >10x productivity improvements which resulted in products succeeding where they otherwise would undoubtedly have failed. Well, I would definitely be interested in these examples. I occasionally write Lisp (admittedly, Emacs Lisp rather than Common Lisp) and while I appreciate having macros and other metaprogramming tools at my fingertips, I've never encountered a situation in which their use was critically important. I can always replicated the thing I wanted to do in Python with a bit of boilerplate; if I had to choose, I would certainly take Python's huge ecosystem over Lisp's metaprogramming. Frankly, I don't think there have been any language silver bullets after structured programming and garbage collection. So I'm very skeptical of the claims of extreme Lisp productivity. I'm open to being convinced otherwise though.
- lisper 3y ago
  The big wins are in niches that involve a lot of domain-specific knowledge. The two best examples that I was personally involved with were the NASA Deep Space One Remote Agent and the Meta chip design tool from Barefoot Networks (acquired by Intel in 2019). In the former case, an attempt was made to do the implementation in C++, which failed outright. In the latter case you can do a pretty direct apples-to-apples comparison of the design cycle time relative to off-the-shelf design tools. Meta lets you iterate in minutes what would take hours using standard tools. (To be fair, Meta does not do everything that the standard tools do, and before you can tape-out you have to do a few iterations on standard place-and-route and timing verification. But it's still a huge win over just using those for the entire design.)
  - FreakLegion 3y ago
    I have experience with EUROPA, which has gone on to have a long life independent of RAX (e.g. I believe it's still used via SACE for the ISS solar arrays). EUROPA is C++, not Lisp, even though Lisp isn't an unusual choice in AI planning.
    - lisper 3y ago
      > EUROPA is C++, Maybe it is now (I don't know -- I've been out of that field for over 20 years) but it wasn't then.