Lost me at:

Programming sucks.

Won me back over a bit at:

There are so many conflicting software stacks ... and annoying libraries. The work of the average software developer has been reduced to gluing libraries together rather than developing interesting code.

and:

We don't have to give up automation if we give up LLMs.

A "culture of automation" is a hella-good thing. But LLMs aren't that.

But lost me again somewhat at:

The urge to automate the process of writing code has shown us we need to abstract the need to write code at all. We need another layer of abstraction that allows us to think about software even to the ways humans—not computers—naturally think.

We need less layers of abstraction, not more. The Java ecosystem is just rife with abstraction layers on top of abstraction layers to "fix" what's underneath. (Web programming in raw Java was hard, so they made an abstraction layer called "Servlets" which has its warts but works, but using Servlets was hard, so they made Spring, which sucks more and now in order to make it act the way you want it to act, you have to understand both Spring and Servlets, which sucks, so they "fixed" it... with another abstraction layer on top called "Spring Boot" which is even worse than Spring and Servlets alone. God help you if you try to upgrade your Java version. It's like trying to install a new foundation under a 30 story building without damaging the rest of the building. Believe me, they'll make another "abstraction layer" on top of Spring Boot one day.)

It really feels like the OP article just almost grazes the point they should have drawn but then veers away in exactly the wrong direction. If the problem is "conflicting software stacks" and "annoying libraries" and "developers [being] reduced to gluing libraries together rather than developing interesting code", to me that screams "too much abstraction".

It's that classic problem that NPM and Rust have such a reputation for. "I imported something for doing this one tiny little thing and it pulled in 100 dependencies." It's abstraction layers on top of abstraction layers all the way down.

The Go ecosystem tends in the opposite direction. "A little copying is better than a little dependency".

Don't pull in abstraction layers. Eschew them. The fewer the better. Some are quite necessary. (High-level programming languages are abstraction layers, after all.) But where you can, keep them segregated out into tiny little edges of your codebase, not all up in the guts of your codebase. Make it a tiny library for reading/writing this file format here and a tiny library for interacting with VT100-style terminals there. Not something that every third line of code in your whole codebase is tightly coupled with. And every time you do add a dependency, hate yourself just a little more. Your dependencies should keep you up at night. If they do, your own code won't.

We tell humans what our program does and then we tell the computer what it is supposed to do. This is a concept known as Literate Programming.

I've heard James Bennett refer to this as "Documentation-Driven Development". And it's something I think every developer should know about. I don't think it's strictly necessary to always write documentation before code. "Shu Ha Ri" isn't only applicable to Agile. But you should always be thinking kindof in the "Literate Programming"/"Documentation-Driven Development" way.

bi-directional tangler

I've been reading and searching for a bit at this point and I have yet to understand the purpose of this. I might do more study. But writing code in Markdown files sounds... weird... and I don't yet know what benefits they're purporting to get from doing so.

But we can go further. Not only can we document our code—we can destroy it.

Oh god. I'm going to hate this section, aren't I?

Code is a concept from a bygone era.

Yup. I hate it already.

I believe one important aspect to replacing code is embracing the Graphical User Interface (GUI).

First, off: 🤮

Second, when has there ever been a "GUI programming interface" that wasn't a "toy"? I admit to having nostalgic feelings about pre-.NET Visual Basic, but it was basically "Fischer Price My First Programming(tm)". And the GUI parts don't deal with code. Just building GUIs. The code is still... code. In a text editor.

I'm investing hard in quite the opposite approach. I've written two domain-specific languages for doing traditionally GUI-based workflows: codecomic and Glot3. And I've written quite passionately on the topic that we need more ways to make GUI-based workflows into code. (Not the other way around.)

This is a long article. I might come back and edit my comment here later to add more commentary, but I've run out of time for the moment. So far, I'm really not on board with much of what the article says.

Update: Ok. Continuing.

GUIs allow us to reason about concepts in more complex ways than text-based interfaces

[Citation needed]

What do they even mean by this exactly?

...while also often being more approachable to new users.

For programming, though? I mean, of course new users are going to feel more empowered right out of the gate if they have a nice GUI for writing music or doing image editing or whatever.

I mean, one-off little macro kind of automations or BRMS systems are fine to do through a GUI. But none of that is a replacement for more "traditional" ways of programming. What are you going to make a AAA video game or an eCommerce application by dragging if-statement-equivalent diamond icons onto a canvas and drawing little lines between them?

I'm guessing their answer would be something like "no, if statements are too low-level; you'd be connecting up much higher-level abstractions". But... how? Each one could have inputs and outputs, sure, and you could feed the inputs of one into the outputs of another, but you can't just take preexisting abstractions and connect them together and expect them to be talking the same language. You have to have something to glue them together. That is if the abstractions that you need even exist in the first place and you don't have to invent your own.

I'm trying hard to think of some way in which something like what the article's talking about could work for real. I'll probably give it more thought. I do think that BRMS systems could stand to be used more. For rules that a BSA or a product owner can come up with and formalize sufficiently, it doesn't make sense to have developers frequently go back to the same part of the codebase to implement yet another multivariate testing scenario or change the rules for deciding which warehouse will ship the product to the customer. Make a way for the BSA or product owner to do that themselves. But replacing development... how is that supposed to work at all?

Like, I think the author just doesn't know how coding works. They call themself a "physics and computing student", so maybe I'm full of shit, but I... I really can't see how this is different from a non-structural-engineer saying "why don't we just manufacture the bridge and then transport it here in one piece and set it here across the Golden Gate? Easy peasy. That's how all bridges should be made." Obviously, there are a billion and one different reasons why big suspension bridges aren't made that way and anyone who would say something like that just has a hugely naive surface understanding of what a bridge even is, let alone how one can be designed and built.

I dunno. I'll have to go back to bi-directional tangler thing and see if I can better figure out what she's advocating for.

I will admit that some of what's mentioned in this article reminds me of this lecture about Femminism in Programming Language Design. But I think the video I just linked was a lot more grounded.

I dunno. This is giving me cognitive dissonance, and I probably should delve more into it and try to figure out what they're really talking about and make sure I'm not just flippantly disregarding something that could work in practice, but I definitely don't "get it" yet. I might come back to this when I feel like I have a better grasp on it.

Update: I think I have a better understanding of Literate Programming now. It's maybe a step beyond what James Bennett called "documentation driven development". As Timothy Daly said in this video, "If you talk to a programmer about this, they're going to hear 'oh, I'm documenting'. Here's the mindset change. You want to communicate human-to-human. Not 'oh there's some documentation in the code'. Programmers can't get past the code. You need to think about it like you're writing a book and they're writing a little section of the book. You're writing a book to explain... what this thing does. That's a mindset change." In a way, DDD and Literate Programming are very very closely related. In another way, they're a paradigmatic shift away from each other.

He describes literate programming as you write "a book" explaining to other developers "why you're doing the thing and what you're trying to accomplish". And then you include the code in the book in various sections and have a build process that pulls the code from the book and runs it through a compiler to get working software.

But!

There's still code involved. And the article goes (or attempts to go, but doesn't really explain at all) a step further. No code involved. And then... throws GUIs in there. How do you "write a book" in a GUI better than you'd go about writing a book with Latex? I hate Microsoft Word, but it's commonly used...

I fundamentally disagree with the idea that "programming sucks" but there are some neat thoughts and tools in there.

This bit in particular:

We don't even have to give up code! The GUI version of a program could merely be one of several human-editable representations. Just as some people love text-based interfaces to their operating systems, some people will continue to enjoy code-based interfaces to software editing. It just doesn't have to be the default—or the only—option anymore.

I've often thought about the idea that to an extent a programming syntax does not have to be married to a language. We could potentially have editors and syntaxes designed so that each developer can interact with the code in the syntax they're most comfortable with, independent of the language. I don't know how realisable this is, it may be underestimating how tightly coupled syntax and language is.

I'm not a big fan of graphical programming in general, but there are times when I would like it just for a single function or class, for signal processing or control systems or state machines. I usually think of this in terms of editor plugins or external code gen tools rather than whole environments. Although every code gen tool I've used to date sucks.

Imagine this: instead of reading other people's code and then trying to parse their intentions form [sic] it, you read the documentation to understand their intentions and then you read the code. You no longer have to strain yourself trying to understand what someone wrote for another audience (the machine). They've already explained it for you.

The best implementation of this I'm aware of is the Entangled bi-directional tangler. A tangler extracts code from your documentation and distributes it across the appropriate source code files. It's [sic] bidirectionality means you can use it to write code embedded in documentation, but then also edit that code normally which it then propagates back into the code blocks in the documentation. This allows programmers to use existing tooling for testing, refactoring, and code formatting without special support for literate programming.

The best built-in implementation for this that I've seen is Rust's doctests. You write a block of code in your documentation. Then you run cargo test. The code gets compiled and executed as part of your tests, and panics get reported as failures. You can also mark code blocks as should_panic, compile_fail, ignore, etc if needed.

I'd love to see tools like this in other languages. Write the docs next to the code, but compile the docs as well and make sure they actually work. This is sort of what Entangled seems to do, but ideally more entangled with the build process.

But GUIs too; they are frameworks, because we are stuck with hardware patterns from the 80s, made for servers. They are workarounds. Same for the whole Unix stack running a desktop-emulator (X, Wayland).

This also reminds me of the spatial computing project DynamicLand