13

If one considers the languages which were considered as a basis for Ada, as listed in the "Report to the High Order Language Working Group" at e.g. http://bernd-oppolzer.de/DoD-Language-Evaluation-1977.pdf, Lisp is conspicuously absent while even COBOL gets a fair evaluation.

Can anybody account for this?

I have come across references to Lisp later being used for US-government related work, see e.g. "Red Team versus the Agents" at https://gist.github.com/fogus/4716440 (spoiler: the result was embarrassing).

Improve this question
23
  • 14
    Nobody in industry or government, considering programming avionics or weapons or sensors or other instruments, would have considered LISP suitable for purpose at all. Not at all. Perhaps there were some applications for it in non-production systems, but not running a fighter jet or aircraft carrier or air-traffic control system. Nope. Nothing to be learned there at all. And I'm quite serious. Literally nothing.
    – davidbak
    Feb 5 at 21:33
  • 4
    COBOL is more powerful than you think. It was probably evaluated at such a high level for its features, namely, what the new language needed (since Ada was supposed supposed to be a do-everything language). PL/1 had to be on the list, too
    – RonJohn
    Feb 5 at 21:51
  • 11
    There was no way then - and nearly no practical way now - to use Lisp for hard real-time embedded systems. Or soft real-time embedded systems. GC. There has been work over time on GC that satisfies at least soft-real-time systems but such GC algorithms, though they offer latency guarantees that can help you meet real-time requirements are not highly performant. Early versions required read barriers that raised costs for all reads of memory, or required fixed size list cells to avoid fragmentation, etc. In the Ada-development timeframe: none were available.
    – davidbak
    Feb 5 at 22:51
  • 3
    Seconding what @davidbak wrote, perhaps the most widely known iteration of the "GC in real-time systems" (hard or soft), is that stuttering is a prevalent issue for games written in Unity, a game engine using C#.
    – jaskij
    Feb 6 at 12:49
  • 3
    There was a joke that went around usenet those days that someone hacked the central source code for the Strategic Defensive Initiative (SDI), that it was in LISP, and to prove it they published the last page of the code. It was a page of nothing but ))))))....
    – Alan
    Feb 24 at 8:00

3 Answers 3

Reset to default
18

Lisp is conspicuously absent while even COBOL gets a fair evaluation.
Can anybody account for this?

I would say the very first paragraph of the introduction on page 8 sets a foundation that pretty much excludes Lisp on the spot:

First Paragraph of the Introduction

A quick search will reveal that the word 'Embedded' shows up in every chapter for a total of 31 times. A strong hint that the embedded theme was the main target for Ada.

COBOL is, unlike Lisp, suitable for embedded applications, not at least due to its ability to generate extremely compact code. Of course it will fail utterly when looking at other requirements (see below).

Lisp may be great to handle complex data relations in highly variable data sets, but I doubt it is first choice for embedded applications. Especially not back in the 1970s when even high-end control systems had at best a few dozen KiB of code space.

When looking at the 'general requirements' noted on page 12, it can easy be seen that Lisp fails in essentially all categories named.

List of Requirements: Simplicity, Reliability, Readability, Maintainability, Efficiency, Implementability, Machine Independence, Portability, Definition.

Looking at those criteria helps to understand why several other languages are also not included. FORTH, for example, a language often praised for its great performance in embedded designs, holds only barely better than Lisp with a single check mark at efficiency.

Looking at the list of languages evaluated does suggest that a good number (including COBOL) may have not been added because of them fitting well, but rather due them being already used in DoD related applications before.

have come across references to Lisp later being used for US-government related work

I'm not entirely convinced that such an anecdotal story makes a good argument. While it misses any placement on the continuum of designated applications, I'm pretty sure it's not about an embedded one :)

Improve this answer
19
  • 6
    You can point also to the Steelman requirements which guided the final language selection (in the contest), especially requirement 1A - the very first requirement: "Generality. The language shall provide generality only to the extent necessary to satisfy the needs of embedded computer applications. Such applications involve real time control, self diagnostics, input-output to nonstandard peripheral devices, parallel processing, numeric computation, and file processing." LISP just doesn't fit there.
    – davidbak
    Feb 5 at 23:00
  • 5
    P.S. Note that that "Language Evaluation" report was co-authored by Peter Wegner. He certainly knew about LISP and would have included it in the report if there was anything to consider!
    – davidbak
    Feb 5 at 23:05
  • 2
    @MarkMorganLloyd Whirlwind was already obsolete and out of service at the time. Also, citing highest end systems isn't really paking a point for a language that should be usable on all systems, the majority of them way below anything mentioned. Even an extreme high end system like the Apollo had only 2 KiWord RAM (and 36 Ki ROM), so not exactly a LISP environment. Computers in Missiles and engines was already a thing when above WG was active. And airline booking is neither embedded nor military use. Last but not least, I citing CG as reason would not only be cheap but also misleading.
    – Raffzahn
    Feb 7 at 11:09
  • 3
    @MarkMorganLloyd - sorry, disagree: it was totally obvious in the mid-70s to anyone working in embedded systems or anyone familiar with the language landscape at all. We weren't clueless back then. In fact, it was even more obvious back then in an era of extremely limited resources. These days you could kid yourself that it was possible and then attempt an evaluation; back then: no way. Ada itself, as it finally turned out, was already quite a stretch, requiring, as it did, dynamically sized records with full constraint checking, records that could contain tasks, etc. etc. etc
    – davidbak
    Feb 7 at 17:12
  • 2
    @Raffzahn: COBOL supports base-10 arithmetic at the language level. If a processor has an instruction to add two N-digit decimal numbers, a COBOL compiler given ADD LINEPRICE TO ORDERTOTAL would likely generate code to do that directly, while a compiler on a more modern platform would likely invoke a library function to do that. If the fields are eight digits each, a COBOL compiler for the 8088 might possibly generate a loop or a 32-instruction sequence that exploits the processor's AAA instruction, but a compiler for the ARM could do the task with a call to a library function.
    – supercat
    Feb 8 at 16:06
9

(Here's something nobody has mentioned:)

The DoD's goal wasn't to get the best possible language for programming their embedded systems.

It was to get the best possible common language for programming their embedded systems, and for two reasons:

  1. So that they didn't have to let a contract to some compiler house to write yet another compiler just because they spun up a new project.

    • e.g., some piece of avionics gets an upgrade and the 10yr old code base needs to be ported to it. The upgrade includes a newer machine architecture (which were created every other week or so). So: old language - probably one of the dozen dialects of Jovial! - for new machine.

  2. So that the really limited critical resource - programmers! - could work on different projects without learning new languages, especially as these projects lasted years even before you considered life cycle maintenance (which, for these applications, was a long life cycle) - and programmers and entire contracting companies would come and go.

They wanted a language that was just like all their other languages except good enough that no contractor was going to spend time and effort and lobbyist influence trying to get a waiver away from it from their DoD program manager, and it had to be enough like all their other languages - all standard procedural (except for the various assembly languages, of course) - that the army of programmers doing military projects would still be able to do them.

(FYI: None of those guys doing the programming for these systems had gone to MIT and taken 6.001.)

Improve this answer
1
  • 2
    BTW for those of you who are not sure that procedural programming languages were just the right thing for those military projects - consider that all DoD projects used the waterfall method of project management, and though they recognized it had some minor issues, that was the way it was done. I myself wrote B specs and C specs and D specs for a major Ada compiler project that was cancelled, after several years of work by several dozen people, before the D specs were done. And of course, before a single line of code was written because: waterfall!
    – davidbak
    Feb 7 at 23:26
3

Lisp has its niches. NASA uses Spike to schedule observations by space observatories (ISAS in Japan has also used it). Spike is written in Lisp. One of its defining requirements was that it had to be efficient enough to deal with the intricacies of Hubble scheduling faster than real time.

T-LogoQube was a (tiny) satellite satellite that successfully used Logo for its (very simple) embedded avionics programming. Logo is Lisp with some "syntactic sugar".

However, Mark Johnston, designer of Spike, once told me that if he were writing it all over from scratch he would not use Lisp. The Sonoma State group behind T-LogoQube seems to be pivoting toward embedded Python for the future.

Improve this answer
9
  • 1
    P.S. - where do you get the idea that a Spike requirement was to be "scheduling faster than real time"? Interesting, I'd like to know more - their own page (you link) seems to show that in product the "fastest" it is run is to produce plans nightly. With an 8-day horizon, given an already scheduled long-range plan.
    – davidbak
    Feb 7 at 17:20
  • 3
    Ah, so "faster than real time" doesn't mean as the telescope is slewing around from one target to another they're choosing the next optimal move - it means the thing has to run faster than the earth revolves .... seems like a reasonable goal!
    – davidbak
    Feb 7 at 17:26
  • 3
    'sidereal-time reponse'
    – another-dave
    Feb 7 at 18:26
  • 2
    @Raffzahn - The Computer Contradictionary, a little outdated now but still funny. Alas, no entry for 'real time'.
    – another-dave
    Feb 7 at 18:30
  • 1
    @JohnDoty yes, I did understand that. And in some way understandable. It's just extreme funny when used in that context. Real time usually means reaction to sensor input right away to produce control output. Spike is simply not a control system, but a production planning system - an area where the term 'real time' is usually not seen :)
    – Raffzahn
    Feb 7 at 19:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .