Paul Cantrell
RE: https://kolektiva.social/@beka_valentine/116845909858983452
These thoughts are important. BASIC and HyperCard were both borderline miraculous in their way — limited, yes, still tricky, yes, but as an entry point, as an invitation? Magical.
My addition to this list: SmallTalk. The lessons of its aspirations and its limitations are as relevant as ever.
1/
Paul Cantrell
SmallTalk wasn’t just a language; it was a philosophy of the human-computer relationship. At its heart was the idea the computers should be user-malleable: reshapable by each person to be the machine they wanted it to be.
SmallTalk’s impact is hard to overestimate. Most famously, along with CLU and Simula, it gave us objects and OOP — not just in the narrow mid-80s “everything is an object!” sense, but in the broader sense of interface-implementation separation that groups related state and behavior into a tidy abstraction. Its fingerprints are alllll oooover modern programming.
2/
Paul Cantrell
(SmallTalk legacy cont:) It gave us message passing and late binding, which form the logical backbone of the entire Internet. That idea developed in many places, yes, but SmallTalk was a nexus for it.
The fact the web sites and browsers can be updated independently of each other? that you can visit web sites that didn’t even •exist• when you downloaded your browser? That’s sender-receiver decoupling at work: the Internet is built on messages, and senders and receivers can change independently as long as the message protocol stays intact.
In a far-removed but very real sense, that’s part of SmallTalk’s legacy too!
3/
Paul Cantrell
Still, for all that, there’s a part of SmallTalk — maybe the most important part — that’s kind of lost to time. Part of the original vision was to make every computer something that •the user of the computer could reshape•. Thus SmallTalk’s bizarre-to-us world where there’s no distinction between programming environment and runtime environment: every window on the screen is an object you can modify; every behavior of the system is open to tinkering; every part of the system you’re using a thing you can change.
That vision of the computer as moldable clay looks pretty distant at this point.
4/
Paul Cantrell
Alan Kay’s original “Dynabook” vision superficially resembles modern laptops and tablets — uncannily resembles in many ways! — but it’s the opposite in one important respect:
Our modern devices are beautifully designed, hermetically sealed products in which there is a strong vendor / user hierarchy.
The Dynabook, as I understand it, would be the opposite of hermetically sealed. It arrives not as a finished design, but as a starting point. Embedded in that “for children” ethos is the idea of play, tinkering, scribbling, making a mess and cleaning it up — and thus the idea of devices being •reshapable•.
(Image source, with lots of commentary from Kay: https://www.quora.com/American-computer-pioneer-Alan-Kay-s-concept-the-Dynabook-was-published-in-1972-How-come-Steve-Jobs-and-Apple-iPad-get-the-credit-for-tablet-invention/answer/Alan-Kay-11)
5/
Paul Cantrell
And no, my good people, that idea of the computer being “reshapable” is not only — not even primarily!! — about FOSS. Linux barely has this property any more than macOS or Windows does. Yes, it is technically possible to rewrite the window manager for yourself. But in practice? There’s a huge skills barrier — which is the result of a huge •customization interface• barrier — to wild reshaping by general users.
That’s an ethos far better embodied by closed-soucre Hypercard than by open-source Linux. It’s not about who has the source code or the legal right to change it; it’s about the range of tinkering affordances the software offers to everyone.
6/
Paul Cantrell
Note that when we developers write software for •ourselves•, we stuff it chock full of these tinkering affordances. The average CLI and programmer’s text editor is a funplex of absurdly general customization points — reshaping affordances that meet the system’s users (programmers) where they’re at (writing little snippets of code).
We offer very little along those lines to non-programmers who use computers.
7/
Paul Cantrell
There’s good reason for this. Lots of things quickly, accidentally turn into programming when you make them customizable — and It turns out that programming is always hard. And it’s not fundamentally hard because of syntax or p-lang constructs (which it turns out are there to •help• humans); it’s hard because giving unambiguous instructions to a machine runs against our human cognitive habits and has endless surprising consequences.
8/
Paul Cantrell
Throughout computing history, there’s an endless, endless parade of attempts to make it possible for non-programmers to do things that are essentially programming. This goes back to COBOL: the original plan was for businessmen (all men, of course) to be able to automate their business processes without having to rely on programmers!
I will not even attempt to enumerate here all the attempts since COBOL to make programming not be programming.
9/
Paul Cantrell
The hunger for tinkering affordances helps explain the ubiquity of spreadsheets in the business world. [long subthread left as an exercise for the reader]
It also helps explain the traction of the “AI Agent” marketing. I can’t think of a technology that’s simultaneously done a better job of removing barriers to user-designed automation and simultaneously done a worse job of helping people dealing with the consequences of automation. (Security and data integrity are two the big places where attempts at deep tinkering affordances have crashed and burned.)
10/
Paul Cantrell
And LLM-driven agents add a new wrinkle: they’re nondeterministic and have bizarre failure modes, so it’s all the “massive oops” dangers of deploying code but with an added layer of “random haywire at any time” on top of that.
We all hear the stories of people figuratively burning down their houses with agents — truly, these things are the “deep-fried turkey” of computing — yes still people are enthusiastic. The hunger for tinkering affordances is large, so large it outweighs the obvious danger.
11/
Paul Cantrell
There really is good reason to give people hermetically sealed, beautifully designed objects that aren’t very customizable but •just work•. And there’s no reason to think that we are anywhere close to solving the intrinsic difficulties that turn all computational automation into programming, and that make programming hard.
and yet…
12/
Paul Cantrell
…we want to be able to shape our machines, to make our computers •ours•, to make them clay not yet fired.
The hunger is there.
The noble humanist vision is more relevant than ever.
The societal need to get humans out from under the concentrated power of computing vendors is dire and urgent.
And the success of things like HyperCard in making the machine just a little more fungible, of inviting people into the magic of tinkering…well, those historical successes make me think we should keep pursuing that goal of the “soft clay,” even if it’s a utopia that will •always• be beyond the horizon.
/end
pinskia
It is why things like opendoc/pink would be better if it was adapted when it was there. Would have provided the tinkering to the masses even more as it provided a high level way of doing embedding of different apps all at the same time.
But Steve Jobs killed it.
emenel
@inthehands imo the language that did this best, and is always missing from these histories, is Logo... an amazing way to learn computation and computational thinking.
Paul Cantrell
I mean, it’s how human society in its entirety functions. And that’s not necessarily a bad thing! “Humans are the adaptable part of complex systems” (https://how.complexsystems.fail) and ambiguity is what gives humans room to adapt when adaptation is necessary. But it’s dangerous not to recognize the role of ambiguity in our many systems.
Murray - Paperposts
@inthehands we humans are not good at giving unambiguous instructions. after moving to the US i realised that an entire economy exists to exploit ambiguity
Paul Cantrell
Ruby is secretly very, very close to SmallTalk in a •lot• of ways that aren’t syntax! But the live environment doesn’t exist in any widely used language today. (Unity and Godot secretly flirt with it just a little, but not really.)
I recommend spending a week tinkering with Pharo.
Dan Drake 🦆
@inthehands I really, really will learn Smalltalk someday. I have read enough to understand that it's not just another programming language. It's not like you're in a world with Python, and then someone does Ruby. Smalltalk just works fundamentally differently and it's really interesting.
Paul Cantrell
I love LabView! And I am endlessly glad I’ve never had to maintain any code written in it!
See also MAX/MSP
rhempel
@inthehands One with a huge blast radius of difficult to manage programs is LabView.
Imagine a GUI native programming environment where you can't see the whole program at once (switch statements are visible case by case only) and where a block executes as soon as all the data is available, and where you can't diff actual source code.
Now imagine that being marketed as allowing "even lab techs to automate your test or factory process".
Now imagine maintaining it 10-20 years later ...
seedsignal
We do not need programming not be programming.
We DO need to understand that, quite literally, everything is code.
Not even programmers gets this yet, which is why they are terribad at translations between domains.
People like me are requisite until this changes, for all business and technology alike continue to insist on trying to eliminate us.
But we lack blocks for the commons to learn and grow from using. So that, too. Open systems not just open source.🪔
Paul Cantrell
> We DO need to understand that, quite literally, everything is code.
I deeply, fundamentally disagree with this. It’s a dangerous misconception programmers nurture that causes them to make all kinds of catastrophic faceplants in human society.
Programmers thinking that the law is code is perhaps the clearest example. It seems like it should be code! Lawyers act as if it’s unambiguous! And yet the fact that it’s fuzzy and constantly being situationally reinterpreted is a primary design feature — not a bug, a feature. A feature with horrible consequences when you have, for example, the current SCOTUS, but a feature!
seedsignal
I spent 30 years trying to help get the translation layer in place; but no one is interested in semantics for standardization -- they all think they're innovating -- it's maddening.
Candidly? Most of this is self-inflicted by the industry.
Someone needs to rip out the mismatch so we can educate (the thing we should have done, never did, and now suffer for not doing).
It's never going to be easier than now, and that has been true since first said.
Goal?🪔
Paul Cantrell
I’d quibble with the “100% successful:” many a spreadsheet has turned into a complex computing system that is in every real sense software with software maintenance problems / nightmares, and that •is• really computer programming. But spreadsheets certainly are a huge winner in the combination of low barrier to entry + useful mileage achieved after entry!
wrosecrans
@inthehands Spreadsheets are definitely the one thing in the history of computing where the urge to turn a workload
into "not really computer programming" was 100% successful.
In retrospect, it's surprising that Excel wasn't invented as soon as interactive terminals.
Paul Cantrell
@joe This post will have me mulling for a while. Seems like “compiler” here means something broader than just compilers?
Joe Groff
@inthehands compilers are the scar tissue that forms between the "user" and "developer" roles. there are competing pressures on code representations you want for modification and maintenance (clarity, modularity, etc.) versus what a distributor wants (compact, opaque, limited support surface), and the wider the rift between these roles the more build system software grows between them. the transition from treating the Web as a collaborative medium to treating it as an app platform is an example
Paul Cantrell
I don’t think that’s the whole story, or even the primary story.
But it’s certainly a significant part of it.
David Smith
@inthehands my, perhaps hot, take is that a tremendous amount of this conflict between clay-like and rigid computing is essentially an immune disorder in the response to fascism’s downstream effects.
Much of the difficulty of modifying a modern computer is because of the difficulty in distinguishing the user from the NSA, or from the organized crime that thrives in high-corruption low-quality-of-life environments.
Our defensive rigidity isn’t selective.
Luke Kanies
@inthehands totally agreed on its value, and its seeming craziness to the modern eye.
The Ink and Switch studio is doing research and writing on kind of the grandchild of this topic:
https://www.inkandswitch.com/malleable-software/
It’s far from what Smalltalk actually was. But tries to get at some of the same goals, for similar reasons.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.