4 ms·

Fun fact I learnt the other day browsing some historic posts: https://en.m.wikipedia.org/wiki/Dynamic_Analysis_and_Replanning_Tool https://en.m.wikipedia.org/w

Fun fact I learnt the other day browsing some historic posts: https://en.m.wikipedia.org/wiki/Dynamic_Analysis_and_Replanning_Tool https://en.m.wikipedia.org/wiki/Dynamic_Analysis_and_Replann... Written in Lisp at the time and widely successful to the point it paid back many times over the investment DARPA put into the language Now the question for anyone who may know, are descendant systems still being written in Lisp?

Jach 4y ago
I don't know about that one, but it wouldn't surprise me either way (still in Lisp or reimplemented/replaced by something else) since such things seem to be hit-and-miss and unless you do some digging it's probably unlikely many programmers of such systems check HN... But for a comparatively old government project in Common Lisp, there's at least one, SPIKE (https://www.stsci.edu/scientific-community/software/spike https://www.stsci.edu/scientific-community/software/spike), that was developed for planning and scheduling the Hubble telescope (and other projects) and is still in use for the JWST (https://www.stsci.edu/contents/newsletters/2018-volume-35-issue-03/artificial-intelligence-techniques-used-in-the-spike-planning-and-scheduling-system https://www.stsci.edu/contents/newsletters/2018-volume-35-is...).
- math-dev 4y ago
  Awesome, thanks for the links!
zozbot234 4y ago
Automated planning is computationally intensive, so you'd want to reimplement any such system using a low-level language, with easier support for parallel and/or distributed compute.
- pjmlp 4y ago
  Like StarLisp.
  - dreamcompiler 4y ago
    Or...Common Lisp, most of the implementations of which can take full advantage of modern SMP cores.
    - lispm 4y ago
      minus the garbage collector, which for most CL implementations does not or only in limited ways benefit from multiple cores
- travisjungroth 4y ago
  They are also cognitively intensive, so it may be worth it to code them in slower but more expressive language.
- nekomorphism 4y ago
  What does "low level" even mean here? Lisp is second only to Fortran in age, so it certainly runs bare metal if that's what you want.
- dreamcompiler 4y ago
  How about reimplementing it in assembler? There's an automated tool that does that, it's called a compiler, and it comes in the box in most implementations of Common Lisp.
- retrac 4y ago
  Lisp is quite good for that, really. Numerical computation, parallelism, etc. With a good compiler, using unboxed values and primitive arithmetic and Boolean operations on ints, most code will compile to not much slower than the C version. For example, I just saw an old paper [1] where the author implements dynamic compilation from Lisp, to Lisp, in Lisp, for parsers. One describes the language to be parsed, in a high and abstract level in a DSL in Lisp. The Lisp program then compiles that definition into to a low-level sequence of unboxed boolean and arithmetic ops and conditionals in Lisp which, being primitives with direct machine code equivalents, the Lisp compiler can translate into reasonable machine code. The end result was probably only a few times slower than doing the recognizers directly in C. Not so different from the usual parser generator technique. But the nice part of doing it that way is that you retain the full Lisp system; your generated blobs of "machine-level Lisp" are still just another Lisp object, so you can take your generated functions and single-step it in interpretation, or transform it further. I suspect that's a big part of why Lisp was so popular for so long. Other languages provide similar capabilities now, though sometimes not so general in ability. But for a long time, this sort of meta-programming where you write the program at the high level to generate the code at the low level for you, was basically a proprietary superpower for Lisp. [1] https://www.plover.com/~mjd/misc/hbaker-archive/Prag-Parse.html https://www.plover.com/~mjd/misc/hbaker-archive/Prag-Parse.h...

Jach 4y ago

I don't know about that one, but it wouldn't surprise me either way (still in Lisp or reimplemented/replaced by something else) since such things seem to be hit-and-miss and unless you do some digging it's probably unlikely many programmers of such systems check HN... But for a comparatively old government project in Common Lisp, there's at least one, SPIKE (https://www.stsci.edu/scientific-community/software/spike https://www.stsci.edu/scientific-community/software/spike), that was developed for planning and scheduling the Hubble telescope (and other projects) and is still in use for the JWST (https://www.stsci.edu/contents/newsletters/2018-volume-35-issue-03/artificial-intelligence-techniques-used-in-the-spike-planning-and-scheduling-system https://www.stsci.edu/contents/newsletters/2018-volume-35-is...).

math-dev 4y ago
Awesome, thanks for the links!

zozbot234 4y ago

Automated planning is computationally intensive, so you'd want to reimplement any such system using a low-level language, with easier support for parallel and/or distributed compute.

pjmlp 4y ago
Like StarLisp.
- dreamcompiler 4y ago
  Or...Common Lisp, most of the implementations of which can take full advantage of modern SMP cores.
  - lispm 4y ago
    minus the garbage collector, which for most CL implementations does not or only in limited ways benefit from multiple cores
travisjungroth 4y ago
They are also cognitively intensive, so it may be worth it to code them in slower but more expressive language.
nekomorphism 4y ago
What does "low level" even mean here? Lisp is second only to Fortran in age, so it certainly runs bare metal if that's what you want.
dreamcompiler 4y ago
How about reimplementing it in assembler? There's an automated tool that does that, it's called a compiler, and it comes in the box in most implementations of Common Lisp.
retrac 4y ago
Lisp is quite good for that, really. Numerical computation, parallelism, etc. With a good compiler, using unboxed values and primitive arithmetic and Boolean operations on ints, most code will compile to not much slower than the C version. For example, I just saw an old paper [1] where the author implements dynamic compilation from Lisp, to Lisp, in Lisp, for parsers. One describes the language to be parsed, in a high and abstract level in a DSL in Lisp. The Lisp program then compiles that definition into to a low-level sequence of unboxed boolean and arithmetic ops and conditionals in Lisp which, being primitives with direct machine code equivalents, the Lisp compiler can translate into reasonable machine code. The end result was probably only a few times slower than doing the recognizers directly in C. Not so different from the usual parser generator technique. But the nice part of doing it that way is that you retain the full Lisp system; your generated blobs of "machine-level Lisp" are still just another Lisp object, so you can take your generated functions and single-step it in interpretation, or transform it further. I suspect that's a big part of why Lisp was so popular for so long. Other languages provide similar capabilities now, though sometimes not so general in ability. But for a long time, this sort of meta-programming where you write the program at the high level to generate the code at the low level for you, was basically a proprietary superpower for Lisp. [1] https://www.plover.com/~mjd/misc/hbaker-archive/Prag-Parse.html https://www.plover.com/~mjd/misc/hbaker-archive/Prag-Parse.h...