Computers are, reduced down to a single concept, reproducible data manipulation machines. Like the physical embodiment of an Excel macro.

Yet because our goals are more high-level than just checking a box on infinite tape, we made equally high-level abstractions in the pursuit of accomplishing them. This dialogue between human and machine, where the instrument unfolds as you interact, make computers function as a meta-instrument.

A computer is the most incredible tool we've ever seen. It can be a writing tool, a communications center, a supercalculator, a planner, a filer and an artistic instrument all in one, just by being given new instructions, or software, to work from.

Today with the advent of inexpensive computers, for the first time the average man is presented with a powerful medium through which his ideas con attain a life of their own.

A computer program is a creation: unusual, appropriate, in a very real sense a work of art, perhaps more so than computer "scientists" like to admit. Many programmers have felt a sense of creative excitement watching their programs execute on a computer without needing their intervention, particularly if they can watch the programs progress with their own eyes.

Surprise, stimulation, satisfaction and savoring are the rewards of creativity.

This dialogue required users to learn a language – a way of expressing how existing instruments composed into new ones to raise themselves up to their work's abstraction layer.

But languages have grammar, quirks and dialects. A designer wanting to draw an XBM icon has one hell of an abstraction crater between knowing what cdr, C-x C-e and JMP is and their high-level goals – and this has only gotten harder as time goes on. Users would need to go down the layers before they can go up.

In Lisp, you don't just write your program in the language; you build the language up toward your program, and build your program down toward the language.

The skilled programmer is necessary only because the distance between the computer implementation of a task and a person's mental conception of it is too great.

A good case can be made that to achieve satisfactory results the ultimate user must have a say in the development of the design systems themselves.

[…]

The designer can no more rely on the computer specialist to develop design systems appropriate to his needs than a wood carver can allow other people to sharpen his tools. The computer specialist does not have the knowledge and cannot acquire it without becoming a designer himself.

Suppose we remove words from their meanings and limit them to their actual shapes, i.e. examine language as language. The perceptual dimensions of language – its sounds and written appearance – are unstructured. Little information can be communicated to someone who does not know a language just by presenting him with spoken or written words.

[…]

For instance, one can define a word such as 'plank' in terms of other words, such as 'straight', 'parallel', 'wooden', etc., but eventually one has to say of some words, to a person who claims not to understand them, 'You'll just have to learn how things of that sort'.

In his thesis – which you really should read – he talks about what thought and creativity is, its medium and explorations on how to best represent in a computer.

He builds on Seymour Papert's Turtle, which lets "children as young as four or five years old" write "bug-free programs the first time" thanks to the mental model created by the instant feedback and iconic descriptions of what each button does – the birth of the icon.

Programming In Pygmalion is a process of designing and editing icons. The Pygmalion programmer is an "iconographer" – "a maker or designer of figures or drawings."

The programmer of the future will be as well skilled in design as architects and artists today.

Icons define the "Pygmalion machine". Everything that can be done to information is done through icons.

December 1979, Steve Jobs and part of the team get a tour of Xerox PARC. They got demos of the mouse, GUIs, early LANs, and Smalltalk's OOP and live environment.

They showed me really three things, but I was so blinded by the first one that I didn't even really see the other two.

One of the things they showed me was object oriented programming, but I didn't even see that. [Another] one of the things they showed me was a networked computer system… and I didn't see that either. I was so blinded by the first thing they showed me, which was the graphical user interface.

One key part of their system, the live environment aspect, was largely ignored or retrofit with systems like HyperCard and AppleScript. Only some odd folk like Emacs and Smalltalk users got to experience it.

The difficulty of software development meant software was dead, not alive, and economics started shaping computers to become meta-appliances instead of meta-instruments.

But what we're trying to get is- we're trying to get away from programming. We've got to get away from programming because people don't want to program computers, people want to use computers.

And so our strategy right now is, let's write some programs that are generic. We'll write 90% of the program and you fill the last 10% of the blanks.

[…]

Now, let me give you an example of how this can work. We have a million Apple ][s out there – a million. And people have paid about $2k for them. So if they can buy a new program, one of these new diskettes for $100 that lets their computers do something totally new that it never could do before, that's a good deal.

Simply put, economies of scale caused the split that lead to the modern-day software industry, and the two branches were established.

And while there were some attempts at getting back to the meta-instrument philosophy – the Dynabook, OLPC and so on – they largely didn't pan out.

The death of the appliance?

The economics that defined that split no longer seem to hold. As flawed as LLMs can be – and ignoring the elephant in the room regarding sustainability and ethics – it is the closest we've been to the Seymour Papert vision: bringing the computer to people instead of the other way around.

For the industry

What this means for the software industry that was built on the meta-appliance, I don't know. For the SF-brained startup world, they mostly knee-jerked into producing more instead of better – as expected – though instead of microservices now it's claws, loops, graphs, orchestrators, lights-off software factories, orbs and whatever else.

Sometimes to the extent of carpet-bombing their brand image and just converging into the same stuff like "Freepik is now Magnific", "Vercel, agentic infrastructure", "Cloudflare: build for the agent era", "Notion, where teams and agents ship together", "Slack: All your people and AI agents working together".

I don't think that brings much value to the world, but I understand why distress causes that reaction on people. I can empathize with them – these are weird and existential times.

For open-source communities

Open-source software was always a counterweight to black boxes and proprietary standards that kept people and their work anchored at the mercy of the providers. While the implementation details of such software doesn't always make it live in the Smalltalk sense, you can still tinker, ask and learn, which is a form of meta-instrument.

It empowers people. Because open-source has always been about the community of builders and users.

For these I don't expect things to change all that much beyond being forced into adopting serious stances on containing slop so contributors don't burn out. I personally like the Mycelium AI Policy, but I can see the reasoning behind stronger ones like Codeberg's.

For users (everyone)

Current AI systems – also known as harnesses – turn models into agents by providing them with tools to interact with an environment. We now have the concept of human agent (that's us!) and AI agents, potentially coexisting on the same place (or them being sandboxed into their own to limit blast radius).

We're sitting in yet another timeline split caused by economic incentives, this time we choose between augmentation and automation.

Cognitive offloading is in practice choosing to surrender our human agency in order to maximize AI's newly granted agency, stunting our own growth by avoiding friction. Inference is slow (read: not instant), so they do multiple threads at a time. People get tired of the resulting context switching and manual approves so they turn on YOLO mode. Code spirals into 30k line PRs you can't make sense of, so you ask the agent to add tests and just send it.

The fragile mental model that the Turtle project by Papert fought so hard for people to have has no real hope of forming, regardless of how many eye-rolling markdown files and mermaid diagrams gets made. Hydrogen Bomb vs Coughing Baby.

In a way, we're taking the meta-appliance route and turning up the dial to 11. Particularly true if using proprietary harnesses, which, let me be honest for a second, is kind of crazy we think is acceptable at all on the first place.

Turns out this approach gives an existential crisis to some developers, not the kind I mentioned earlier about the SF-style ship-meltdown, but the kind of developers who love computers as meta-instruments.

I propose we go the other direction.

Instead of surrendering developer's agency, we extend it to users through the same technology. Instead of reinventing primitives like loops and tool calls (read: functions), we integrate it into live systems and share it with users. Instead of inventing AI specific tooling for collaboration, we create standards that also work for humans.

You could think of Pi.dev and Autolith as having some hints of an alternative vision, though they're too slot-machine-shaped for my taste still.

Please, please, please. Let's keep the vision of the Dynabook alive and execute it better than ever.

And goddamn, don't tell people they don't need to learn to code anymore, regardless of what shape it mutates into over time. It's not about the symbols and expressions but about self-determination.