4 ms·

The right analogy is not to literature, but schematics of the architectural or mechanical kind. Those can also be beautiful, works of art, and objects of study

by retrac 3y ago

The right analogy is not to literature, but schematics of the architectural or mechanical kind. Those can also be beautiful, works of art, and objects of study. Sometimes a clever blueprint will allow seeing some aspect of construction that isn't otherwise obvious. But the prints are not usually the centerpiece for a discussion in their own right. The object depicted - a building or whatever - is the main focus. Going back to the literature analogy, reading groups are for fun (usually). Spark ideas and discussion. Code is too low level. It's like discussing the author's grammar and word choice -- sometimes necessary to understand the meaning of the text! - but most would prefer to discuss high level themes in the work.

agentultra 3y ago
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. [0] https://cacm.acm.org/magazines/2015/4/184705-who-builds-a-house-without-drawing-blueprints/abstract https://cacm.acm.org/magazines/2015/4/184705-who-builds-a-ho...
- jll29 3y ago
  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."
temac 3y ago
Another way to view things is that if code seems too low level, it is not abstracted correctly.

by retrac 3y ago

agentultra 3y ago

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. [0] https://cacm.acm.org/magazines/2015/4/184705-who-builds-a-house-without-drawing-blueprints/abstract https://cacm.acm.org/magazines/2015/4/184705-who-builds-a-ho...

jll29 3y ago
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."

temac 3y ago

Another way to view things is that if code seems too low level, it is not abstracted correctly.