Great essay by @Will: http://willcrichton.net/notes/gradual-programming/. Reminded me of the somewhat related: @tomasp's http://tomasp.net/blog/2018/programming-interaction/

What do you mean here by externalized?

Represented in the computer.

You mean as a separate artifact from the code itself? Like a UML diagram or something?

No, as part of the code itself. Perhaps the language could support incremental refinement. So initially you write the high level concepts, sequences and relations. Then you append the details. The motivation for the idea is that the high level conceptual representation should be directly accessible to the readers. Otherwise you have to read these low level logic and rebuild the high level model in your mind. Also it seems useful to have a representation where it is clear what level you are modifying - the higher level execution or some lower level details.

Yeah that makes sense. I think there’s two axes here: declarative<->imperative and empty<->complete. A conceptual representation usually starts off with the task you’re trying to accomplish. That’s kind of what all these specification languages are for, is declarative writing down tasks. And then you usually refine that with imperative commands until the task is accomplishable. The other side of this is that some part of your specification is often empty or ill-defined in an exploratory setting if you’re not sure what task you’re solving. So it would be important to represent that as well. At a low-level this is captured by structure editors (cc @Cyrus Omar) , but I think there’s an interesting question of handling higher-level underspecifications.

Indeed, I too believe the gradual refinement of computation is a critical aspect. Right now, developers read their way through the code and execution and, as @shalabh said, they are forced to create the meaningful model in the mind. This is inhumane. In our work, we see the support for creating higher level representations as being the responsibility of the programming environment, rather than of the programming language. We also think that for representations to be effective, they need to be contextual. It follows that it is critical for the tool to mold to that context.

One anecdote here… I was talking recently with a senior mechanical engineer at an oceanographic research institute. We were talking about programming tools, and he mentioned how CAD makes parts of his job so easy he feels like he’s cheating. Things that used to take a lot of careful calculation can now just be quickly whipped up and simulated--he’s effectively offloaded a lot of his mental model onto CAD.

Meanwhile I feel cheated having to take on new mental models and run them in my head. While computers are great at simulating physical systems, we're ironically stuck having to mentally simulate computers themselves.

The section on domain specific languages resonated with me. When there's a specific domain, it's easier to think of ways to make tasks in that domain easier. "the allure of programming language research, that the tools and theories we develop don’t affect just a single domain, but potentially everybody who programs" If domain-specific languages were more composable, maybe work can be done to gradually make each domain easier while still allowing a general purpose program to be constructed from those parts?