Emacs supercharging other programs, Ada is great, and more space software!
We learn how we can use Emacs to supercharge other programs that are suboptimally charged on their own. We learn how Ada excels at low-level programming, and we reflect on one of the things that are really cool about being in software: that we get exposed to the guts of other industries.
I have an awful fever and writing this is a little difficult. I hope you excuse any rambliness that comes as a consequence of that.
New articles
Opening any CLI in Emacs
Finding new ways of using Emacs to power up computer usage: non-readline CLIs can be converted from sprintf^Ax ^E"d^H2d"^C^C^C^D to ergonomic with comint-mode.
Full article (1–3 minute read): Opening any CLI in Emacs
So You Think You Know Ada?
Spoiler: many of the things that result in undefined behaviour in C are compiler errors in Ada. More people should use Ada for low-level code.
Full article (5–12 minute read): So You Think You Know Ada?
Flashcard of the week
This week's flashcard returns to a classic: the Apollo guidance computer, which navigated astronauts to the moon and back. It was one of the first fully software-controlled digital systems, and nobody realised before the project that software design was going to be an actual task that someone needed to do.
In other words, they asked for the computer to be built, and then sort of just assumed that it was going to do the right thing, even though nobody had been given the task of writing the code for it. We can see why that happened: that's how all other previous machines had been built – their purpose was sort of baked into the design. Not this time.
At the point when MIT engineers started writing code for the AGC, nobody really knew exactly what the requirements for the software was.
What did the fuzzy specifications for the AGC result in?
The MIT engineers ended up talking to rocket people and hunting down NASA staff just to figure out what in the world the computer should do.
The software engineers did a bunch of the early mission planning in order to find out what code they actually needed to write.
To be able to write any code at all, they needed to know what the code should accomplish. At that time, nobody had quite figured out the shape of the missions yet, so the software engineers had to be a part of determining that, even though it was really only to be able to perform their actual work.
This is one of the cool things about being in the field of software: we get to see the internals of many other industries, and we get to pick apart how things actually are connected together in those industries.
Premium subscription
I'm gauging interest in additional, monthly premium content[1]. For a limited time, a premium subscription to this newsletter will cost just $1 per month to see how large the interest is.
To upgrade, click the subscription link at the top of this newsletter and fill in your email again.
[1]: To be determined more precisely, but ideas include
- links to other articles,
- book reviews,
- previews of future articles,
- voting on topics for me to read/write about, etc.
Your opinions
As always, I cannot improve without feedback. Reply to this email to share your thoughts on any of the topics above, or anything else!