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™”. 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…