“If a system is to serve the creative spirit, it must be entirely comprehensible to a single individual. Human potential manifests in individuals.” https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk....

“Experts and beginners both want to use the same tools. Children want to learn saxophone, not kazoo.” - Rich Hickey

The ginormous computer companies don't target programmers, they want ever more users aka consumers. Apple is a good example, their products are increasingly difficult to program yet increasingly polished to appeal to the under-informed buying public.

We only need to look at how BASIC (MS) and HyperCard (Apple) were eliminated in order to remove easily accessible end-user programming. wrt spreadsheets, only a tiny minority of operators use the macro or language binding features.

I shudder at new motor vehicles being ever more software based. On this basis of any recognized bug to lines of code metric, hundreds of faults are lurking therein.

The divergence between users and programmers became more pronounced over time. When command line interfaces were dominant they naturally made programmers out of users, even if they didn't realize it. CLIs made “using the computer” and “programming the computer” effectively the same activity in a lot of cases. A command someone entered to run a program was itself a program. Entering the previous command again and modifying it, for instance to pipe the output of the first program into another program, was also a program. Once the desired result was achieved, that final command could be saved and used again later. Or shared with someone to be used as-is, or to be tweaked a little bit for their own use case.

Each interaction with a CLI results in a valid program that can be saved, studied, shared, and remixed. That's a powerful model for the same reasons the spreadsheet model is powerful: it's immediate, not modal, and successful interactions can be saved as an artifact and resumed later. Can we do the same things for GUIs? What is the GUI equivalent of pressing the up arrow key in a shell, where I can recall my previous interaction with the system and then modify it? Can I generate artifacts as byproducts from my interactions with a GUI system that I can save for later and share with others?

Amazing that there's no mention of AI in this post. People have been trying and failing to blur this line since the beginning of computing, and the only real success story has been excel. And it's because rigid computing systems have to draw a line somewhere between user and developer, and if that line is in the wrong place, people will either get hampered or lost. And the correct threshold is different for every user and use-case

AI is going to finally be the realization of this dream. I don't think it could have happened any other way

Malleable software is hard not just for technology reasons; probably the most difficult part of designing software is thinking through and cleanly handling the implications of every decision. It's easy to imagine that one could 'just make it work like this instead of that' without understanding the implications of the change or the reasons why the system is like that in the first place. Making software has never been easier than it is today, but it's still hard because designing coherent systems that work correctly in all scenarios of usage is hard.

Yes, configurability is good and scripting is a great way to safely add functionality to a system but there will always be a distinction between people who use software and just want it to work perhaps with minor tweaking, and those who build systems. It makes no more sense to throw everyone in the same bucket than saying that being able to change the oil in a car makes everyone a mechnical engineer.

Also:

> Many, many technologists have taken one look at an existing workflow of spreadsheets, reacted with performative disgust, and proposed the trifecta of microservices, Kubernetes and something called a "service mesh".

Yes, over-engineering is a thing, but piles of interlinked spreadsheets are usually thrown out precisely because the people who created them didn't have the skills necessary to build a system, and these ad-hoc systems eventually outgrow their usefulness and become unwieldy horror shows. Maybe Beryl in accounts knows the eighteen cells across three files that need to be updated when the interest rate changes, but if she leaves then we're all screwed.

I love this so much, and eager to see what comes next in the "multi-part series".

This approach is rare, but when it works, it works really well.

I built this for myself. I call in imtropy and it is awesome.

Getting it prod ready for others takes too much time and money I don't have.

> i would go one step further: the dream of malleable software is to unify users and programmers, such that there are just “operators” of a computer, and “writing a program” doesn’t sound any harder than “writing a resume”

People are on average very stupid, very lazy, don't want to think about anything deeply, and may in fact not only not only not know how to get from origin to destination may on average not even know what their destination ought to be.

Making something more accessible means enabling people who will still be called developers do more whilst knowing less it won't ever make everyone a developer.

A computer operator is someone who maintains the operation of a computer system and schedules programs submitted by users.

It’s mostly a dead profession that has been automated by operating systems.

Honestly neither programmer or user have negative connotations to me. They both imply an active role when interacting with the computer. The term I _really_ hate that’s getting way too commonly thrown around lately is consumer.