Her Wikipedia page gives her due credit and shows just how much she and her team pulled off:
Also note the size of that printout of her program. Try to think about how many people make one like that which doesn't fail in the field even when parts of its environment and hardware are failing. Also while using low-level code with little to no tool support on 60's era, embedded hardware rather than a JVM, etc. Margaret Hamilton was the first in the field of high-assurance programming that I've seen. A lot of firsts.
So, I give her credit where possible. The industry should even more as she wasn't a theoretical programmer like Ada Lovelace: she engineered actual software, co-invented many of the best practices for it, deployed them successfully in production, and then made a tool that automated much of that from requirement specs to correct code.
While programmers and industry ignore her, at least NASA gave her positive mention as the founder of software engineering and ultra-reliable software along with the biggest check they ever cut to an innovator:
Where would our systems and tools be if more attention was put into her methods, even just principles, than informal use of C? ;)
Sadly, being behind the Iron Curtain was likely a primary reason for her relegation to obscurity.
I also like that they tried the automatic programming with algebraic methods. Their approach might be interesting. A few correct-by-construction software and hardware approaches developed here took that approach. DDD toolkit for hardware comes to mind.
Hmm, we need more info on her to see just how much credit she's missing and give it to her.
Inventor of the compiler, early advocate of machine-independent computer languages, creator of COBOL, originator of the verb debugging.
> On page 117 Isaacson credits Hopper as "the technical lead in coordinating the creation of COBOL," a hugely important standard language for business programming that was defined jointly by several computer companies. Standards committee work is a difficult thing to dramatize, which is presumably why Isaacson gives COBOL no more than a passing mention, but as historian of technology Janet Abbate recently noted, his omission slights several women who, unlike Hopper, were on the technical committee in question. Among them is Jean Sammett, who made the largest single contribution to the design of COBOL. Sammet has stated that Hopper was "not the mother, creator, or developer of COBOL," an idea Hopper reportedly endorsed by calling herself the "grandmother of COBOL" rather than its creator.
> [...] Sammet has not been forgotten, as a fellow of the Computer History Museum and a winner of the IEEE Computer Pioneer Award, but sits on the wrong side of a growing chasm separating the handful of women chosen for public veneration from those whose names are known only to specialists.
> This is an example of what sociologist of science Robert K. Merton called the "Matthew Effect," the tendency for the most famous person involved in any collaborative project, however peripherally, to be remembered by the public as the key contributor. He named it after a passage in Matthew's Gospel, noting that "unto every one that hath shall be given, and he shall have abundance: but from him that hath not shall be taken away even that which he hath." Over time the famous become more famous, while the moderately well known are forgotten.
edit: that is not disagreement with your point, but pointing out there may be a deficiency in Wikipedia that needs correcting.
(A moth in a relay in a truly large piece of big iron.)
I think it's interesting that this folk etymology has had such a long life; it's easy to debunk, and Admiral Hopper certainly doesn't need another feather in her cap, yet it persists.
That's how it works with humans - when you have a cap full of feathers, people keep adding more and more.
So, Hopper is the first, great programmer that women bring us. Helps lay the foundation for all HLL programming. Hamilton took it to the next step to true engineering practice. Kind of set the bar high. So, she's my main mascot. Hopper's is great, though. Should probably present them all as a group with their contributions to foundations.
P.S. Happy Ada Lovelace Day!
"P.S. Happy Ada Lovelace Day!"
Back at ya!
That print out is not the source code. I'm pretty sure it's a listing of test results. The Apollo computers couldn't store that much in either (the equivalent of) RAM or ROM.
> "In this picture, I am standing next to listings of the actual Apollo Guidance Computer (AGC) source code," Hamilton says in an email. "To clarify, there are no other kinds of printouts, like debugging printouts, or logs, or what have you, in the picture." It's just her and her code.
If I had to guess, maybe they printed out each revision of the program? Apparently there were seven different versions , so if the stack contains all of them, that would account for the difference pretty well.
No reason not to talk about both of them!
Thanks for the Svoboda reference as I didn't know about him. His is our vanilla approach for reliability so he deserves credit. Might look up his papers.
Should have been $32,768.
"Should have been $32,768."
No, it should be $37,200 because Ms Hamilton only accepts unsigned integers on her checks. Insists you pay her rather than the other way around. :P
Also interesting if you visit her company's website: http://www.htius.com/
It's a view into a software industry that is virtually never reported on in the news, at least not on HN. The client list is impressive. It's not really clear what they actually do? Seems to me like they maintain a developing environment and sell support contracts for it?
I think it might work out if they use a different language. Sugar-coat it, make it more flexible, or even build on an existing prover like Coq or HOL with a subset of its typical usage. It would make it easier for developers to pick up. It would make their end a lot harder, though, as the tool attempts to solve and integrate a series of Mega-Hard problems. Like EDA, but not binary.
That she and her crew got this far is impressive. It's the standard I hope to exceed someday with more usable tools that optionally perform better.
Speaking more generally, you need domain knowledge outside of computer science, so that you understand which applications to tackle and how to apply the engineering knowledge in a specific vertical.
I look at everything through the lense of software engineering. Because at the end of the day, even though I have many different hammers, I'm still pretty much just a hammerer. To make an actual thing, I need a domain expert.
And that's kinda frustrating when you think about it.
There was a lot of interest in formal techniques in the late 1970s and early 1980s, but the technology didn't go that way.
I encountered HOS back when I was doing proof of correctness work, and didn't really understand how it got beyond very simple problems. But I thought, at the time, that was my fault. In retrospect, it's an approach for a certain class of control problems dominated by required relationships between certain variables. That's what flight control systems are all about.
Control problems are typically expressed as a set of "laws", equations which define what's supposed to be happening given the inputs and perhaps past inputs. Some of these are equations, and others are constraints. Checking those laws for contradictions and turning those laws into code is partially automatable, and that's what HOS was trying to do.
HOS only seemed to work well with the founders driving it. Somehow, they were never able to express clearly what they were doing. Sometimes that happens. Norm Hardy, who came up with capability-based systems and created KeyKos, a capability-based OS for IBM mainframes, had that problem. The system worked great, but nobody understood what he was doing. He used to have an "explainer", Susan Rajunas. In both cases, the startups went bust.
Trying to get people to understand a complex formal system is very hard. Harder than developing one.
Add another one to that list: Exactly how this complex system benefits people
Those craft were quite likely capable of a _lot_ more than they were ever allowed to do by the astronauts - though I guess we'll never know!
>Once the code was solid, it would be shipped off to a nearby Raytheon facility where a group of women, expert seamstresses known to the Apollo program as the “Little Old Ladies,” threaded copper wires through magnetic rings (a wire going through a core was a 1; a wire going around the core was a 0). Forget about RAM or disk drives; on Apollo, memory was literally hardwired and very nearly indestructible.
I was at a talk by Richard Battin, also of Draper on the Apollo program, a few years back. One of the stories he told was of a number of the Apollo astronauts visiting Raytheon (where the core memory was being "sewn") and the general gist of the visit was "be really careful with your work or these nice young boys could die."
I wonder if any of that still happens these days. Probably way less now when American astronauts hitch a ride on the Soyuz.
Well, that's demonstrably untrue, but the narrative, it must be pushed at all costs.