Here is the brief version of that essay:
* Programming is about building theories/models of the problem. Source code largely has no value by itself [1]
* It is very difficult, if not impossible, to transfer these models/theories between humans (see the essay I linked below for details)
* Because of this difficulty, programming is essentially teaching (when writing program code, we're teaching other people of the problem domain, and models that fit that problem domain)
* Another way to phrase this: All programming is building user interfaces. When you're writing, say, a function, you're writing a more abstract UI for the next programmer or yourself
* The tools we have for writing these UIs are terrible - taken the above example of writing a function, what are the tools you have to communicate this idea to the next person? A single string of characters (the function name). In a typed language you get a bit of extra info because of the type information (I believe this to be the main advantage of type systems).
* The big question is: What would a better UI for communicating abstractions look like?
* I don't know the answer to that question but I have a hunch that it has to be bi-directional. If you've ever worked with a GUI library that has a visual editor, you know how awful they are, unless there is also a representation of the same GUI in code. This bi-directional mapping of code and GUI makes it very easy to understand the two different ways of looking at the problem. I think something like this is needed down to the very lowest levels of abstractions.
* Another way to phrase this: Imagine two different scientific models for the same problem. For example, for the model of an atom, its protons and neutrons, there is the more simple Bohr Model, which is completely wrong, given our current knowledge, but still very useful in many modern calculations. But in certain situations, a more accurate model is needed, which takes quantum mechanical effects into account. I see an analogy for programming here: In most cases, a simplified model suffices, but as more performance is needed, a more complex model is required. The question is, how can we easily teach someone the more difficult model, once they've understood the simple one? And the other way around (which is often also not easy, since simple is not the same as easy).
If you have any thoughts on what I've written, any at all, I'd love to hear from you (I'll watch this thread, or find my email in my bio).