Dijkstra On the foolishness of "natural language programming"

That's a really deep question. Obviously there are types of creativity that don't require words, like painting or sculpting, or improvising music, but I'm having real difficulty imagining programming without something at least resembling natural language. The closest my imagination gets is Scratch/Blockly, but even then you're essentially creating an AST composed out of statements and expressions, even if they're pictorial.

Can you imagine the (intentional) creation of a program entirely without language?

Or, I suppose, if you're ok with it not being intentional, you can program via an evolutionary algorithm - is that what you have in mind?

I think you're the kind of person who has an internal voice talking in their head, and can't imagine any other kind of thought?

Math is all about abstract shapes and properties, for me. So is much of programming.

Yeah, just chiming in to say the same. Essentially all of my thinking is geometric in nature. The only time I have any internal monologue is as a mnemonic device to remember a sequence.

Yeah, I suppose you're right and I'd love to understand more. Do you imagine a modality of programming a computer in an abstract (pictorial? diagrammatic?) way that fully bypasses the current need to form statements?

Let's try this as an example.

    fn foo() -> Result<u32, MyError> { ... }

    let x = foo();
    match x {
        Ok(num) => println!("foo is {num}");
        Err(error) => eprintln!("no foo for you: {error:?}");
    }

So I have in my head a thing that has the name "x" and a spatial connection to that area of the source code where foo is called.

x is a Result<u32, MyError> and in my head that's a vague abstract shape with the "potential" to be either the uint32 shape (in my mind, a "brick" of a certain size) or a MyError shape (vague blob and since I know it's an enum it also has its own "potential" to be multiple shapes; it kind of has the branchiness of a tree without being tree-shaped; this is all abstract and concepts, not concrete shapes).

When "x" meets the "match" the "x" shape splits into its "potential" shapes, and "num" has the uint32 brick shape.

None of this has anything to do with visual programming like Scratch. It's just that I never say in my head words like "x has value of what foo returns" or "num is an uint32"; those just are.

Does that make any sense to you?

Hmm... that's interesting. It sort of gives me a glimpse, but I'm still very confused about what the "process" of programming is for you. You mention in your explanation that these things in your head are somewhat "vague" and "abstract" - so how do you see the action of converting a general idea in your head into working code in the computer?

Just to recap, the way I see this is that the non-verbal neural processes are insufficient to fully define a computer program and it is only at the point where a person converts their abstract thoughts into verbal statements/expressions that the program is fully generated.

So is it that you have some process whereby you feel that you can generate a specific program in your head (e.g. with those shapes you mentioned) that exits in fullness without any equivalent of statements? And if so, can you foresee a future human-computer interface that would allow you to program directly via those shapes without having to type statements?

The connections between the abstract entities are the connections between the source code elements. That thing goes to `match` which gives me either this or that. It's more that the program is sort of graph-shaped (all about connections) than that I have linear grammar sentences in my head.

I could "serialize" the same mental model into various alternate syntaxes, e.g. assign to temporary variables or not, based on what feels right and has a good amount of things to think of at once (the good old no more than 7 rule).

I could write it out in multiple different orders, as long as data dependencies are fulfilled.

I definitely don't write programs as sentences like how I am writing this text right now. For example, I might first decide that I assign a placeholder `todo!()` to a local variable of a specific type (I know the "shape" it will be, no more), then use that value and return from the function, and then go back and figure out where that "something" could come from. Sometimes I have a couple of such sections and I "search" for the connections between them. My prose is much more linear.

I don't think I have much better means of expressing what goes inside my head than what that gives me. After all, language is the tool we're learned to communicate with. IDE-level helpers like rename all instances of this variable (now that I understand how I intend to use it) are useful, so I can literally name things a, b, c to describe a chain of processing and once I understand what I need to do, go back and easily rename them to something more descriptive.

Better code navigation and on-screen layout would be great. Like, what if functions aren't just sequentially in a file, but each one lives separately and can be opened in neighboring panes easily, to pick what you're looking at, instead of jumping around a "file". IDE "jump to definition" and API doc hints are related but not quite the same.

Outside of programming, being able to point at things to manipulate things and make connections is really powerful, but very hard to invent great UX for. I could see that sort of stuff being useful. Even in a text editor, I often wonder why exactly can't I drag a paragraph or a Markdown section (heading+everything under it) to move it. In gg the VCS GUI, you can drag commits between histories and changes between commits: https://www.youtube.com/watch?v=cD9L3Mi1Vy4 . In general, structural editing can be a great way to munge source code, there's definitely ways to improve over emacs paredit. I feel like there's some sort of untapped power in the combo of structural editing and a touchpad with haptic feedback, but maybe it'll take AR to make it intuitive enough. Think "gesture intents" popping up from the trackpad like long press pops up character variants on phone keyboards. Think swipe left/right and more for blocks of content, with UI feedback to confirm the action before release.

Thanks for putting that in writing. It's funny how I was expecting you to tell me about something very different from my approach to coding, but your explanation actually really resonated with how I think of it. My mind isn't as visual, but it's also very nonlinear, with me often dragging (option + up/down in VS Code) chunks around until they best fit with the code "story" I have inside my head. And I also tend to spend a lot of time to figure out just the appropriate variable naming, and sometimes change the names after moving the code around, attempting to have the code make more sense when read in order.

I quite like your idea of jumping across functions living independently rather than in files, and agree that a future AR approach for this is likely the way to go. I'd be very interested in something that's like the Minority Report interface, or even better, being able to visualize the code as being in a fully 3d space that I could navigate around (rather than having it come to me).

The git editor you showed looks neat, but I can't imagine myself using it. On a related note though, I quite liked the interface of the game TIS-100 and am wondering if there could be a professional version of that.

But zooming back out, I still can't seem to imagine programming as an activity being done entirely without text (or a pictorial equivalent), and would thus still argue that it is during this act of "translation" of pre-verbal neural activity to language that the program is created, perhaps especially because of how non-linear this process is.

P.S. What's the "no more than 7 rule"? I don't recall ever hearing of that, and can't seem to find any online sources. Is it about the 7±2 chunk limit on short-term memory?

> Is it about the 7±2 chunk limit on short-term memory?

Yes.