← notes

No Silver bullet

• Source

#todo @Promising Attacks on the Conceptual Essence Page 12

For reference, this paper is from 1986 and it has aged like a fine wine.

Notes

There is currently, no process, tool, paradigm, rule, etc, that ensures the reliability of software. And even though there are attempts (and I would add, cargo cults) around the problem, there's no actual solution.

The difficulties are divided in:

• Essence: Inherent in the nature of the software.
• Accidents: Difficulties that attend its production but that are not inherent to the problem.

The essence for software is representing any conceptual construct with abstract concepts. Some properties of this essence are:

• Complexity: A software entity size, the number of components and interactions between them, has constant change and growth
• Conformity: Most software interfaces with established infrastructure (be it hardware like CPU, software like an OS or regulations like PCI)
• Changeability: The successful usage of software demands extending it beyond its original capabilities (new use cases)
• Invisibility: Software has no physical representation. Diagrams help understand components/parts, which we may compose and try to see in layers (looking at you c4model.com), but it is not possible to see the entire system in a single diagram

Some attempts trying to fix the accidental difficulties:

• High-level languages: The abstraction of concrete machine concerns (bits, registers) allowing developers focus on abstract concepts (data structures, operations)
• Time-sharing: Being able to perform more than one operation with the CPU
• Unified programming environments: Extrapolating, I think this includes package managers and using open-source software and libraries.

As for the proposed solutions to fix the essence so far:

• More high level languages won't solve the problem, they just simplify the abstractions for data flow and structures
• Paradigms do not solve the problem (if they did, there wouldn't be a discussion between using oop or functional or whatever)
• On artificial intelligence, expert systems and automatic programming, I'll quote verbatim this: "the hard thing about building software is deciding what to say, not saying it" and here's a demo that shows the status quo. How would it handle actual complexity?
• For graphical programming I guess the "state of the art" is Unreal Engine's Blueprint Visual Scripting but here is why I think that is a step in the wrong direction

• I don't have comments on the rest but to summarize
  • Program Verification: Automated testing? I dunno `¯_(ツ)_/¯ In my experience the only helpful thing from tests is avoiding regressions.
  • Environments and tools: The newer tools seem to be going backwards, adding even more unnecessary complexity
  • Workstations: Computers are way more powerful than we know. We just got used to lousy and slow software.