Beautiful Software

There are three strange facts that force me to consider good software to be (among other things) beautiful and natural, compelling us to examine closely what these words mean.

1. People can tell the difference between something that is natural, that is, not man-made, and something that is a human artifact.
2. However it's measured, nature makes more complex products than we can. Of course, the human species is an 'artifact' of nature, so we can never win that game.
3. Among the products of nature and humans, we judge the best to be 'natural and 'beautiful'.

Regarding (1) -- of course it is possible to fool people: with a photograph, for example. But when we do so, we are merely re-emphasizing that there is a perceptual faculty, in the brain, that reacts to impressions of natural structure.

Regarding (2) -- there are many wonderfully complex natural products, perhaps all of them, that are complex that we cannot comprehend how they were constructed. And yet, we know that good software must be comprehensible. This puts into the question the value of pursuing an understanding of nature's methods, since we will not be able to exactly produce things the way that nature does. However: a) we do not even understand the way that we produce things, from the point of view of the natural sciences, but we try anyway, and find it helpful; and b) the natural sciences exist in order to become more enlightened about nature's nature, in part to discover more about our own nature, which can in turn be used to improve what we do, if applied responsibly. We don't need to copy nature exactly. We just need to do better than we're doing now.

Regarding (3) -- there are many human artifacts and processes, even very popular and 'successful' ones, that are neither beautiful nor natural. Over the decades, I've found this to be a good indication of a harmful product or process. Popular and dominant is not necessarily good, but, unfortunately, by habit, and power projection through our society, these bad habits are often called 'best practices'. Learning to question these dogmas is one of the most important skills one can develop in life -- along with an ability to piece together those qualities that should replace the dogmas. This process of enlightenment, in the broad sense, should never end.

Finally, even the most beautiful and natural software will do harm if it was not created freely and coöperatively, for the purpose of healing and helping people and the ecology. Responsibility is rarely practiced in the creation of any technology, but we won't survive unless we become truly, doggedly responsible.

We'll be examining these ideas and practices in a global educational and research initiative, consisting of conferences, classes, discussions, and publications. You are all invited.

https://beautiful.software

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.