Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Participants: Derya Akbaba * Ben Allen * Natalia-Rozalia Avlona * Kirill Azernyi * Erin Kathleen Bahl * Natasha Bajc * Lucas Bang * Tully Barnett * Ivette Bayo * Eamonn Bell * John Bell * kiki benzon * Liat Berdugo * Kathi Berens * David Berry * Jeffrey Binder * Philip Borenstein * Gregory Bringman * Sophia Brueckner * Iris Bull * Zara Burton * Evan Buswell * Ashleigh Cassemere-Stanfield * Brooke Cheng* Alm Chung * Jordan Clapper * Lia Coleman * Imani Cooper * David Cuartielles * Edward de Jong * Pierre Depaz * James Dobson * Quinn Dombrowski * Amanda Du Preez * Tristan Espinoza * Emily Esten * Meredith Finkelstein * Caitlin Fisher * Luke Fischbeck * Leonardo Flores * Laura Foster * Federica Frabetti * Jorge Franco * Dargan Frierson * Arianna Gass * Marshall Gillson * Jan Grant * Rosi Grillmair * Ben Grosser * E.L. (Eloisa) Guerrero * Yan Guo * Saksham Gupta * Juan Gutierrez * Gottfried Haider * Nabil Hassein * Chengbo He * Brian Heim * Alexis Herrera * Paul Hertz * shawné michaelain holloway * Stefka Hristova * Simon Hutchinson * Mai Ibrahim * Bryce Jackson * Matt James * Joey Jones * Masood Kamandy * Steve Klabnik * Goda Klumbyte * Rebecca Koeser * achim koh * Julia Kott * James Larkby-Lahet * Milton Laufer * Ryan Leach * Clarissa Lee * Zizi Li * Lilian Liang * Keara Lightning * Chris Lindgren * Xiao Liu * Paloma Lopez * Tina Lumbis * Ana Malagon * Allie Martin * Angelica Martinez * Alex McLean * Chandler McWilliams * Sedaghat Payam Mehdy * Chelsea Miya * Uttamasha Monjoree * Nick Montfort * Stephanie Morillo * Ronald Morrison * Anna Nacher * Maxwell Neely-Cohen * Gutierrez Nicholaus * David Nunez * Jooyoung Oh * Mace Ojala * Alexi Orchard * Steven Oscherwitz * Bomani Oseni McClendon * Kirsten Ostherr * Julia Polyck-O'Neill * Andrew Plotkin * Preeti Raghunath * Nupoor Ranade * Neha Ravella * Amit Ray * David Rieder * Omar Rizwan * Barry Rountree * Jamal Russell * Andy Rutkowski * samara sallam * Mark Sample * Zehra Sayed * Kalila Shapiro * Renee Shelby * Po-Jen Shih * Nick Silcox * Patricia Silva * Lyle Skains * Winnie Soon * Claire Stanford * Samara Hayley Steele * Morillo Stephanie * Brasanac Tea * Denise Thwaites * Yiyu Tian * Lesia Tkacz * Fereshteh Toosi * Alejandra Trejo Rodriguez * Álvaro Triana * Job van der Zwan * Frances Van Scoy * Dan Verständig * Roshan Vid * Yohanna Waliya * Sam Walkow * Kuan Wang * Laurie Waxman * Jacque Wernimont * Jessica Westbrook * Zach Whalen * Shelby Wilson * Avery J. Wiscomb * Grant Wythoff * Cy X * Hamed Yaghoobian * Katherine Ye * Jia Yu * Nikoleta Zampaki * Bret Zawilski * Jared Zeiders * Kevin Zhang * Jessica Zhou * Shuxuan Zhou

Guests: Kayla Adams * Sophia Beall * Daisy Bell * Hope Carpenter * Dimitrios Chavouzis * Esha Chekuri * Tucker Craig * Alec Fisher * Abigail Floyd * Thomas Forman * Emily Fuesler * Luke Greenwood * Jose Guaraco * Angelina Gurrola * Chandler Guzman * Max Li * Dede Louis * Caroline Macaulay * Natasha Mandi * Joseph Masters * Madeleine Page * Mahira Raihan * Emily Redler * Samuel Slattery * Lucy Smith * Tim Smith * Danielle Takahashi * Jarman Taylor * Alto Tutar * Savanna Vest * Ariana Wasret * Kristin Wong * Helen Yang * Katherine Yang * Renee Ye * Kris Yuan * Mei Zhang
Coordinated by Mark Marino (USC), Jeremy Douglass (UCSB), and Zach Mann (USC). Sponsored by the Humanities and Critical Code Studies Lab (USC), and the Digital Arts and Humanities Commons (UCSB).

Code Critique: Axes by Margaret Hamilton

Programming language::Axes/001Axes
Name of author/s: Margaret Hamilton and Saydean Zeldin
Year circulated/published: 1976

To follow up on our conversation about Margaret Hamilton, I'm interested in the Axes or 001Axes and its legacy. What became of this software? How did it change into Universal Systems Language? What if any impact has it had on computing. In one article, she calls it, "001AXES—actually a meta-language—has mechanisms to define mechanisms for defining
systems. "

I'm interested in this programming language because it seems to carry on her work on error prevention, Development Before the Fact, Systems Oriented Objects, et cetera.

I came across this article by Dijkstra: "Judging “HOS” from a distance" [Higher Order Software, Inc., which produced Axes]. In typical Dijkstra fashion, he proceeds to criticize four publications tied to HOS, including some of the specifications of Axes. He casts serious shade on the endeavor.

I have yet to find a code snippet for this language, but have found a number of diagrams, Function Maps or Type Maps, I will post one below. Is this a primarily visual language? Or is that the output of the 001 tool?
Judging “HOS” from a distance

The code is dependent on 6 axioms that I will post below. Help me hunt for the code and its impact.

Hamilton, Margaret H., and William R. Hackler. “8.3.2 A Formal Universal Systems Semantics for SysML.” INCOSE International Symposium, vol. 17, no. 1, June 2007, pp. 1333–57. Wiley Online Library, doi:10.1002/j.2334-5837.2007.tb02952.x.

Hamilton, Margaret, and Saydean Zeldin. AXES Syntax Description. Defense Technical Information Center, 1976.


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

  • 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

    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.

  • 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.

  • 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.

  • 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.

  • edited January 2018


    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.

  • 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).

  • Hamilton Technologies has a website where you can still license AXES: . 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.

Sign In or Register to comment.