Even then I would say code is not the blueprint but an artifact. Specifications of the precise, formal variety are more akin to blueprints [0]. They allow us to see the design of a system at a high level while eliding unnecessary details.
Source code for programs are limited in that they can only express ideas about their local state. Barring high-level languages with dependent-type systems it is nearly impossible to model and check that your transaction consensus protocol works as intended without getting into a ton of gory detail... much more so if you want to check global properties of the concurrent system you're designing.
I think Sussman was right: we often start with a pure model of what we intend to design but the artifact we produce, the source code of the actual program, is usually full of details that only matter to get the program to produce the expected behaviour when executed... and all that extra detail tends to drown out the core ideas.
Along these lines, the perfect programming language would be one that eliminates all boilerplate that can be eliminated, one that leaves behind "pure design".
"The result of the execution of the blueprint is the building."
Source code for programs are limited in that they can only express ideas about their local state. Barring high-level languages with dependent-type systems it is nearly impossible to model and check that your transaction consensus protocol works as intended without getting into a ton of gory detail... much more so if you want to check global properties of the concurrent system you're designing.
I think Sussman was right: we often start with a pure model of what we intend to design but the artifact we produce, the source code of the actual program, is usually full of details that only matter to get the program to produce the expected behaviour when executed... and all that extra detail tends to drown out the core ideas.
[0] https://cacm.acm.org/magazines/2015/4/184705-who-builds-a-ho...