Code Critique: Axes by Margaret Hamilton

Comments

• ebuswell

  January 2018

  Here we go: http://www.dtic.mil/dtic/tr/fulltext/u2/a095988.pdf
• ebuswell

  January 2018

  "Although it is not a programming language, AXES is a complete and well-defined language capable of being analyzed by a computer."
• markcmarino

  January 2018

  Thanks, @ebuswell, Okay I'm going to offer for our code critique a passage from Axes, aka Universal Systems Language, that Hamilton and Hackley included in the article: Universal Systems Language for Preventative Systems Engineering. I'll include some snapshots of diagrams they have included as well as their descriptions.

  First the Primitive Control Structures:
  

  Although a system defined in these structures has properties for systems in general, the properties have special significance for real time, distributed aspects of a system (that every system ultimately has): each system is event interrupt driven; each object is traceable, reconfigurable, and has a unique priority; independencies and dependencies can readily be detected (manually or automatically) and used to determine where parallel and distributed processing is most beneficial.

  Next a system:
  

  Figure 4 shows an example of scheduling with a performance pass of a function, F.

  Past, present and future related indicators are used to identify when a line of control or action (i.e., a function instance) occurs; or when an object state exists. Subfunctions, A and B, are concurrently executing in interval 1, with object states, a and b, respectively. In interval 2, A(a) is still active and F's control jumps ahead to include activating E(b1) concurrently. B is past, having produced b1, and C(a1) and D(c) will be future actions. In interval 3, E(b1) has completed, producing e, an output event in partial completion of F, while F continues with C(a1).

  Now a specific part of that system:
  

  Figure 5 shows an interrupt structure that performs the functions, I? and/or F?, that are to be defined when interrupt is used in another FMap. The key to understanding interrupt is the primitive operation, is:present(i). is:present is evaluated asynchronously when the value of s0 is available. If the value of i is available, then I? is performed; otherwise, F? is performed and this process is repeated. Figure 6 shows a set of execution snapshots (EMaps) depicting the performance of interrupt.

  In the first snapshot, since s0 is available and i is not, is:present returns False and continue invokes F?(s0). After the first F completes, the interrupt leaf function checks the state of i again (still not available), selects continue, invokes another F, F?(s1) with a revised state of s0. This process continues until i becomes available. Interrupt granularity is based on the time it takes to complete F. Figure

  And once more:

  

  I'd like to read these diagrams in reference to the Apollo 11 code and Margaret Hamilton's work on error prevention, particularly in relation to software engineering and the system for prioritizing operations of the Executive.agc file.

  For more details on this system, see the article: Universal Systems Language for Preventative Engineering
  http://www.htius.com/Articles/36.pdf
  
  The larger question is how does USL and Axes extend the legacy of Hamilton's work on Apollo 11 by creating a system for software design that addresses issues (error prevention, prioritizing tasks, etc.) that she was wrestling with while working for NASA.
• markcmarino

  January 2018

  Todd Millstein adds:

  USL is what we would call now a "modeling language" -- it is not itself executable code, but rather a language for expressing the overall architecture of the system along with the relationships and constraints among the system components. Typically these languages have some kind of graphical interface as a core, to describe the system components and relationships. Fig 3 in the first paper and Fig 2 in the second paper give examples.

  Well-known examples of such languages are UML and Statecharts.

  So the idea is to model your system in such a language, for clarity of thinking. Often there are associated tools to check properties of these models and to generate stub code in a programming language like C or Java, which could then be used as a starting point for a full-scale implementation of the system.
• jeremydouglass

  January 2018 edited January 2018

  I forget that Dijkstra can be a real jerk. His critiques in "Judging 'HOS' from a distance" are a mix of over-the-top ad hominem attacks, valid points about things that are unclear or inelegant, sniffing about how much subscript use is fashionable in mathematical writing, and really oddly specific opinions that he presents as facts, like the idea that flowcharts will be uncool forever because none of the young professors use them in teaching anymore. He also disdains both experience-based design and private industry -- for reasons that he takes to be self-evident.

  Dijkstra could be pointing out some serious concerns about fuzzy concepts and hype in HOS / Axes -- he has considerable authority on computing in general, and his point about GOTO as a best practices is a real reason for him to feel personally aggrieved, as he is the author of "GOTO Considered Harmful" from 1968 (which in 1979/82 they apparently hadn't read). However he comes off as such an unmitigated ass in this piece that it is very difficult to know which parts to take seriously.
• oncomouse

  January 2018

  I think a key to what is going on b/t Dijkstra and Hamilton/Zeldin is a line in Dijkstra's essay: "The overwhelming impression is that the authors have had more experience than education." Much of Dijkstra's incredulity in that paragraph and the one that follows is that people in industry still make errors that academics told them was wrong 25 years ago. It seems we could flip Dijkstra's attack and apply it to him: "the overwhelming impressions is that the author has had more education than experience."

  I've been tracing in my research what I'm thinking of as a top-down / bottom-up dichotomy in the history of early computing, in which there's a strong divide between the mathematicians who are working out the algorithms and the machine operators (who were mostly women in the 30s, 40s, and 50s) who are figuring out how to implement the math on the machine. My bigger claim from this is that the divide between functional and iterative programming paradigms roughly maps to this divide (functional programs describe a solution and leave the computer to figure out how to solve it; iterative programs explain each step the computer must take to solve the problem; FP abstracts the implementation while IP often abstracts the problem). However, I read Dijkstra as approaching people attempting to solve "bottom-up" implementation problems from the perspective of someone who has been on the "top-down" side of computing for much of his career.

  For someone who spends more time on the logic of computation than the implementation (which is only based on my impression of Dijkstra from his work), trying to check for errors that were warned against 25 years ago would be a hopeless waste of time ("everyone knows that's wrong!"), but for someone who spends their days managing the large-scale implementation of software systems, the need to protect against all kinds of obviously bad errors is still important. Just because someone knows something is bad doesn't mean they won't keep doing it.

  I do think it's interesting that a lot of what AXES seems to be trying to do is being implemented around the same time (mostly at the University of Edinburgh) in some of the early strongly-typed functional programming languages, such as ML, NPL, and Hope. Strongly-typed functional languages have the advantage of being able to verify at compilation a lot of the things Hamilton and Zeldin seem to want to test for, but with the added advantage of not being a separate language. So, I think this system is addressing, despite Dijkstra's objections, some very real issues with large-scale system design.
• jeremydouglass

  January 2018 edited January 2018

  @oncomouse:

  Iterative vs. functional, top-down vs. bottom-up, and logic vs. implementation -- these do seem like productive ways of thinking about this disagreement over the value of Axes and similar approaches!

  Relating this back to the week topic on Gender and Programming Culture, I wonder if/how these perspectives relate to labor and gendered work -- for example, specifying or directing what one should do in principle vs. ("merely") doing it. Are ways of checking for correctness at design time being treated like "women's work," -- like the braiding of the braided memory?

  I also wonder how this might relate to Todd Millstein's observation that "USL is what we would call now a 'modeling language'". So one way of contextualizing Axes/USL historically is with e.g. the emergence of strongly typed functional languages such as ML in the early 1970s. Another way might be to think about the use of diagrams in the Booch method, the Object-modeling technique (OMT), and then Unified Modeling Language (UML) in the 1990s. In 1983, Dijkstra is certain that thinking about software with diagrams as an "obsolete technique," and believes that it has been obsolete since the late 1960s! Yet within a decade after that writing there is an explosion of work in diagrammatic program specification, some of it tied to the rise of object oriented programming as a dominant software development methodology in the 1990s. In that light, Hamilton's work is not out of date, but cutting edge.
• gregorybringman

  January 2018

  It is also interesting to note that after the surge in interest in visual modeling languages like UML, one type of software development in industry has moved towards writing specifications in the form of unit tests, with a language like Cucumber, Spock, or RSpec, making use of human-readable language.

  This seems both a continuation of Hamilton's work and a move away from it. A textual specification - one sentence or phrase that in a nutshell defines how a method or function should behave can be easily tied to business use cases, but does not require a visual apparatus. In the sense that the Apollo mission had concrete use cases, a spec testing framework foregrounds the use case in the implementation of code.

  It is also very intriguing that a language written to solve business problems turns towards a very high degree of abstraction and must be generalized in order to allow it to model business use cases, which seem tied more to specific tasks that do not necessarily have an apparent connection to informatics and computing.

  While specification testing frameworks attempt to foreground business goals, they require that the programmer writes code to tie assertions about the software to human-readable language if only superficially. In some ways, this is only a gesture for keeping software implementations close to their business intention.

  This can still help with clarifying programming "logic", but Hamilton's approach, in contrast, attempts a meta-modeling that could be seen as prescribing or engineering a "correct" way to program based upon some form of logic, one that eliminates errors. At the same time, it has none of the impulse of Dijkstra's work and is intriguing for the very reason that it architects an approach in a distinctly different way than other formations in computing history (despite aligning with bottoms-up, iterative approaches).
• adamhaile

  January 2018

  Hamilton Technologies has a website where you can still license AXES: http://www.htius.com/ . There are examples, screencasts, and even an hour long talk about AXES that Hamilton delivered at Nasa in 2012 (!). May we all hope to be 1% as sharp as her at 76.

  There's even -- no kidding -- a page of poetry submitted about the 001 system. She was the daughter of a poet, Kenneth Heafield, and his chapbook is linked from the poetry page.

  Dijkstra is, as always, an ass, but he is also usually worth reading. I looked at the 1976 report @ebuswell linked, since it seemed to be the most contemporaneous to Dijkstra's sources. About his claims of obfuscated and overblown language, here's a sample from the report:

  

  That author is trying very hard not to say only the last five words. (It's not clear who exactly wrote this report -- it lists both Hamilton and Zeldin as authors, or could have been someone else in the lab.) It reeks of #iamverysmart-ness. What to make of that?

  And about subscripts, here's another sample:

  

  There are sub- and superscripts, and left and right varieties of both. Subscripts can have subscripts, and even superscripts, meaning they snake across the page up and down from multiple corners. I've never seen a notation like that.

  I think he's wrong about flowcharts, though. Flowcharts were a representation of operational semantics, which was out of fashion at the time in CS departments, largely at Dijkstra's own urging. But the AXES trees aren't representing operational flow, they're representing data flow and are closer to dependency trees or even AST trees.

  It's also not right to compare AXES to UMD or other modelling languages. Those languages generally specify high-level entities but leave the guts of how those entities work unspecified. AXES goes all the way down. You could build an AXES compiler; in fact, they did, just targetting C and Ada instead of machine code. This confuses Dijkstra: if "defining the program" leaves it fully specified, then isn't it just programming? It seems to be a question of semantics: the AXES literature calls it "Programming Before The Fact" (PBTF, TM HOL Systems), and seems to consider the "Fact" the laying down of something close to machine instructions.

  I think it's a great observation that Dijkstra's response here is unusual, in that he doesn't call them stupid. He has something at stake in his letter: he spent his life defining what "really professional software development" would look like. The Apollo lab followed none of it, yet they sent us to the moon.

  But then it gets interesting: compared to how the Apollo software was written, AXES has come substantially Dijkstra's way. USL is a structured, functional (he calls it "Applicative"), strongly-typed language. It's a heck of a long way from "GOTO + 3" programming.

  But despite moving towards more formal CS, the AXES literature talks as though it were developed in a vacuum. They use some conventional terminology but invent much of their own. They cite almost no one but themselves. They couldn't have been a complete island, as there's enough in common that someone must have been reading some literature somewhere.

  That seems to be the core issue for Dijkstra: the AXES group, he feels, was re-inventing recentish CS history, badly (his opinion), while claiming great things.

  One last thing: that 1976 paper has a quite bizarre first chapter. I have to assume it had a different author than the superscript passage I cited above, as it's a fairly elementary introduction to what it means to write about a language rather than in the language. And it features "Jimmy the peanut seller":

  

  (Must be a Carter joke: 1976, and Jimmy also "sounds funny in contrast with Northerners.")

  I'm tickled the drawing made it into a report to the US Military. But what was the intended audience of this report? Bizarre.