Software tools are lost in the weeds

All global software research and development -- on languages, paradigms for languages, native features on platforms, IDEs, services, frameworks, collaborative tools, approaches to collaboration, optimization, and analysis -- is far too obsessed with trivial, peripheral, and ephemeral details. There are big problems in the world of computing, which everyone experiences, but nobody works on. Instead, we unnecessarily take small journeys through slightly recombined sets of ideas about inconsequential concerns. Our industry is so deeply driven by puffery, that we are constantly buffeted by these small trivial changes.

If this continues, we will never begin to approach a set of tools that builds upon, and allows for, the comfortable expression of human ideas. Instead we will remain lost in an intellectual world that rejects conceptual progress, praises economic success and low-level implementation and efficiency. We will never come to agreement about the goals and concepts that should be represented and shared at the high and intermediate levels of any application.

What is the solution? It really doesn't take new tools.

What we need is for every programmer to focus on summarizing their application's purpose and structure in a brief, explanatory, comprehensible fashion -- at the top of anything that might be hard to comprehend -- and to use that summary to drive the actual, operational, implementation through a set of similarly comprehensible intermediate structures -- until the application works, and is modifiable at any of these levels, by any person. 

We've stopped looking at programs as examples of beautiful communication among software engineers. We need to focus on making them comprehensible from the top, and never stray from that goal. Unfortunately, we cross that boundary, and move beyond comprehensibility, all the time, for expediency, or to follow some technical pattern, or some conceptual orientation, or some sub-cultural jargon, or some framework ideology, or logical consistency, or other fashionable nonsense. 

Don't do it. When you begin to solve the puzzle of these initially-incomprehensible sets of new notations and definitions, or language or platform features, or dorky framework requirements, consider them less central than their designers do. They aren't your program. Push them down, consign them to some kind of container or wrapper for unimportant details ... an object or function or module or whatever you prefer ... making sure it does not conquer the readability of the operational top of your program, or any of the intermediate levels after that.

Briefly, it must be understood that a program written now is not automatically understandable later simply because a computer can operate under its direction. Denotation in any computer 'language' doesn't provide meaning in the sense of a natural language ... it's just a kind of agreement about parameterized symbolic substitution, and can be done completely opaquely, or with great compassion for other humans. The actual meaning of your program is in your head ... and occasionally in the heads of other humans you've successfully explained it to. The code on the page may 'work', but it's meaningless without this brain-provided context. 

Consequently, we need to work extra hard to express that meaning in the code, with the program itself -- with the next level up of notation and ideas that you'll provide to make the 'normal' code comprehensible. Not just in the comments. The program itself needs to explicitly express comfortable human ideas, and those highest-level-first ideas need to drive your program -- otherwise, you're creating write-only code, or your group is writing code that can only be read by an ephemeral clan of programmers. That's never going to get us anywhere. But that's what everyone is doing. Instead, try to look at programming as a social contribution for the ages. Make it beautiful. Express it clearly.