Discover more from Mary Rose Cook’s Newsletter
A software maker doesn't need to define their software exhaustively
Exhaustive definition is not necessary
Now, if the spec does define everything about how the program is going to behave, then, lo and behold, it contains all the information necessary to generate the program! And now certain geeks go off to a very dark place where they start thinking about automatically compiling specs into programs, and they start to think that they’ve just invented a way to program computers without programming.
Now, this is the software engineering equivalent of a perpetual motion machine. It’s one of those things that crackpots keep trying to do, no matter how much you tell them it could never work. If the spec defines precisely what a program will do, with enough detail that it can be used to generate the program itself, this just begs the question: how do you write the spec? Such a complete spec is just as hard to write as the underlying computer program, because just as many details have to be answered by spec writer as the programmer.
The quote says there are some people who believe you don't need to use code to define the behavior of software. They believe you can use a spec, instead. And they believe writing this spec is less effort than writing code. The quote argues that these people are wrong and, in fact, the spec would need to specify every detail of the software in order to produce the intended behavior. So no labor would be saved.
This is wrong.
The spec writer would not need to specify all the behavior of the desired software. They could employ context - definitions, structures and conventions created previously - in the spec. Just as a programmer can employ a library - for example, one that takes credit card payments - without needing to either write that library or understand its details.
To be clear, someone has to create that context or library. But this person needn't be the person writing the spec or the code. So the labor required of this end writer/programmer is lower.
This is another angle on the idea I wrote about in Good stuff, faster: the fallacy that there is no "simpler" software making. That all programs must specify all the details. Seen from the perspective of code reuse, it becomes clear that this idea is absurd. As programmers, we've been doing this "simpler" programming through the use of abstraction right from the beginning.
Context is a powerful idea. It gets us away from the assumption that all software must be made in code. Context lets us focus on the idea that there are bodies of knowledge we can agree on that let us be briefer and more expressive.
For example, part of SquareSpace's context is that you're building a website. This limits the amount of things that SquareSpace needs to support. Another part is WYSIWYG, a representation. This brings a number of useful mappings. For example: if a user places an element in a location in the authoring environment, it will appear in that location in the viewing environment.
Abstractions can be better or worse
There's a kind of moralistic idea that you can never escape complexity. That an ignorance of how pointers work will, at just the wrong moment, leap out of the underbrush and gobble you up. That reaching for the easy delights of modules hosted on npm will eventually drown you in a sea of code you don't understand. Though these specific ideas are right in some circumstances, the broader idea is wrong. It is possible to pick good abstractions. Like event-driven objects for a world simulation. Or key frames and paths for animation.
The benefits of an abstraction really can massively outweigh the drawbacks. An abstraction really can lift us high into the sky.
There's only up and down, and down is very close to the ground. And I'm trying to go up.
— Bob Dylan