Yep, this article is definitely asking the right questions!
So more about the experience of the PET 2001 and why its graphical characters had a coolness that I think we’ve lost. I booted up the Masswerk emulator and, well, this image sums up my experience.
There’s a bunch of things that work together really well to draw you in, which are often missing from the interactive programming experience. And some things which don’t work and could be improved on.
-
The free-roaming cursor and the immediate ability to type on the screen and see characters, even before you press Return to execute. Like a “pre-immediate” mode. Essentially, the PET boots into a text editor / sketchpad (that can’t save, which could definitely be improved on!) Not all of the 1977 trilogy of micros had this immediacy.
-
The graphical drawing shapes right there on the keyboard, visible, and laid out in sensible sets. This invited kids (and adults), once they could see that the cursor moved and echoed keys, to start drawing. This was particularly important because at the time, not many people had even seen a typewriter keyboard, so drawing was something you could do even if you didn’t understand “Qwertyuiop”. The boxes included rounded corners (something that Steve Jobs also intuitively realised was important for the Mac) - these soften the harsh mechanical feel of lines and made a machine feel “touchable”.
-
Reverse mode meant you could get double the use out of graphical block chars. It also allowed easy highlighting for menus and selections. It wasn’t implemented well on the 2001, but it’s still a good concept. (On the C64, reverse wasn’t needed because foreground/background selection could do the same job - I think this means they could expand the character range and finally allow upper and lower case together, which is a necessity now).
-
Characters on a grid are super easy to navigate, even for a kid. You just move around, overwrite, and change things. Everything stays where you put it. If you have bitmap or vector graphics and variable-pitch text, suddenly you need a whole grid-like or table-like mechanism for laying out and spacing elements, and windowing frameworks and HTML all had multiple opinions on this (Java and .NET and HTML have arguments with themselves on the subject, even).
There are also many things the PET/C64 did terribly. The top and middle and diagonal lines were good. The weird other lines - useless, distracting and a waste of valuable key and char space. Those cursor keys - nope. Volcanic, boiling nope. Definitely need a T-pad. BASIC wasn’t the right language at all. The machine should boot up into a text editor that saves the screen to a disk block - a Forth could handle this. (Course we couldn’t afford disk drives outside the USA in the 1980s, but still - some way of saving the screen was needed). Pressing “Return” to execute was also a mistake; Return should just move the cursor, something else should execute. And so on.
But that initial “scratchpad” interface of the PET/C64 was the “wow” factor. It’s what sold kids like me on “hey, I can understand this machine! I can make it do things! Now I just need to work out how to bring this image to life.” And it’s the part we’ve mostly lost today.
I’m absolutely looking forward to trying out the Spritely projects as they mature, and to seeing them advance the state of the art.
It still seems important to me, though, not to let the perfect be the enemy of the good. It’s not clear to me @natecull what use cases motivate your search. I personally have at least some use cases that I can address today with existing, mature, well-engineered software. Ones that improve on a C64’s textual graphics, ones that just require interacting with graphical objects on a screen in a slightly granite-ish manner
. Ones that don’t need to run untrusted code, or ones with a small amount of unchanging code that I can slowly inspect and convince myself to trust. Or ones that require running dynamic untrusted code, which I can reliably do but the way I do it looks kinda ugly and hackish.
So I’ve been trying to bite my tongue and I’m failing, and I hope y’all will take it in the spirit of love I say it, but I feel some impatience with this thread. I’m less interested in coming up with the perfect tools that make doing any abstract thing a pleasure, and more interested in getting on with the doing of concrete things in rigorous even if unaesthetic ways.
Then again, maybe it’s just that I’ve been out all day wrangling eldritch Indian bureaucracy ![]()
This is a perennial trade-off, and I see people argue for both sides..
My use case is trying to analyse a particular user interface that I enjoyed interfacing with, and trying to understand the spark of “flow” that I felt when using it, and how to further develop that feeling. It’s much the same use case, I think, that you’re aiming at with Lua Carousel. Just coming from a slightly different direction.
I’m less interested in coming up with the perfect tools that make doing any abstract thing a pleasure
Our tools don’t need to be perfect. But you should be interested, I’d think, in noting from personal experience when a tool causes pain or frustration as opposed to joy, and trying to figure out what about that tool causes the pain and what about it causes the joy, and then trying to slowly and iteratively make the tool less painful and more joyful?
And I’m literally doing that here and now. But I’m sorry for doing so on this thread in a way that makes you bit your tongue and feel impatience.
Apologies.
nothing here, just satisfying Discourse's minimum size limits
Something like a display list?
i.e. a list that contains all the graphics commands to be executed in order?
Two recent comments on a different thread feel extremely relevant to this thread as well:
- This comment by @Apostolis beautifully smacks down my ragequit above from yesterday.
- This comment by @cxres could belong equally well on this thread.
Thanks all. We’re inventing a Theory of Everything here.
If Discourse were more malleable, you would have augmented its “Reply” feature to let you construct a DAG rather than a tree.
That idea illustrates why malleability is fundamentally hard: what you need to change to do this is modify the central data structure of the Discourse message graph, not just add a button to the UI.
At the same time: the affordance of “type whatever you want” and “link whatever you want” has been flexible enough to allow expressing the idea, if imperfectly.
That’s the power of plain language, the original malleable medium of our species ![]()
I usually refer myself as a “cybervegan”, in the sense that I choose proactively to not have big corp tech “fast food computing” in my life. No Google, Amazon, Meta, Apple, Microsoft (I’m forced to use that last one for my work at the university, but from my NixOS office machine, at least).
In our case, at our grassroots collectives in the HackBo local hackerspace and the Setas Libertarias edible mushrooms collective, we are trying to assemble our own tech stack while rebuilding some parts of it, like the computational notebooks or the wiki engine, as our diffractive genealogy for convivial computing has been long informed in movements related with critical literacies, computing and autonomy, including the Free Software movement and even its depolitized counterpart of Open Source.
As said in other parts this diffractive genealogy contrast with the “solo” approaches to convivial computing where the convivial part is abstracted in the generic “user” and “community” or even where communities are explicit, like in the communal computer of Dynamicland, but the community is volatile. In this other genealogy, specific local communities are a core concern in a long lasting relationship where we explore the relation between computing and agency for the needs of such communities.
I use diffractive genealogies in the similar sense of Janeke Adema uses it in her Living Books publication, accounting for how there is not a single past for the book and we can imagine multiple futures too. Something similar applies to computing. Despite Bret Victor says that there are not local cultures of computing, I know particular examples of how computing is used and developed in local contexts that are not following the trends or using the stacks or approaching the problems pushed from the Global North as the only ones.
In that sense, I find the malleable systems collective pretty resonant to what we are doing over here, and I find the diversity of topics and approaches pretty refreshing, while I still see the communities and conviviality kind of abstracted away. Maybe because there is this strong cult of personality in the North figures like Stallman or Toldvards (or Kay or Jobs) are put constantly in the center, while the communities that make their work possible are constantly made invisible. Putting that in the foreground is an important needed excersise to think about how we can build (inter)personal, communal and convivial computing.
A thoughtful comment, thank you. The nudge away from abstracted and generic users, tendency for individualism and cult of personality - toward collaborating persons and collectives, grounded in specific places and practices. It’s a good reminder to put ideas in context.
About how group thinking often organizes around an individual, it seems these figures become common nouns and signifiers more than actual persons, like characters in a story. When we talk about Stallman (RMS), the individual is not as relevant as the narrative and constellation of concepts that formed around the name. It’s a mental shorthand to be able to point in that direction. Of course there are actual charismatic characters (and anti-charismatic which may be more effective in terms of memetics) - leaders, dictators who shape the narrative by force or charm. They too turn themselves into symbols in the discourse of history.
local cutures of computing
There are many subcultures of computing, large and small, down to the individual, the primitive unit of culture/personality. Some monocultures grow around a programming language, a framework or tool; and others based on technical practices or niche interests - people who broadcast their explorations, find each other, discuss, and organize activities to promote and further their field.
..Oh I see, “local” here means the local physical area. Right, DynamicLand is an example of a local culture happening in that building, city and country. In this sense I find hackerspaces like HackBo very interesting, I haven’t participated in such communal computing culture at a specific location sharing the same physical space.
What comes to mind is the BBS (bulletin-board system) scene back in the days before the web. There were lists of local phone numbers that your modem can call and connect to a server, usually a computer at somebody’s house. I remember one in Kyoto with mostly motorcycle enthusiasts who met up occasionally - they were surprised when a foreigner kid (I was 13 or so) showed up once. That was super niche, stories of good places to ride bikes, shooting fireworks by the river, sharing games and software for NEC PC-98 and Sharp X68000 which were in style at the time.
The Chaos Computer Club (CCC) is famous in the region where I live for now, but I haven’t gone in person. Elsewhere DEFCON and Burning Man are adjacent, though thoroughly infiltrated by the mycelial tendrils of the mammon matrix. These are events not communities or cultures. But I see that communities express themselves through events, even on the web, like the Autumn Lisp Game Jam 2025. Instead of a physical place, it’s local to a specific time period.
..while the communities that make their work possible are constantly made invisible. Putting that in the foreground is an important needed excersise to think about how we can build (inter)personal, communal and convivial computing.
So true, I’ll be thinking about this and how I see my own work, explorations and experiments in that context.
Fast food is a suitable metaphor, not only about computing but the quality of media and information, mass produced without concern for nutrition and public health.
Janneke Adema in her Living Books: Experiments in the Posthumanities
There’s a whole series of books I’ve been chewing on for months that revolve around the idea of posthumanities, with titles like: The Cyborg Manifesto, The Poetics of DNA, Alien Phenomenology, Bioaesthetics, Insect Media, Junkware, and Hyperobjects: Philosophy and Ecology after the End of the World.
Oh I see, Living Books is part of the series I haven’t read yet.
In this book, Janneke Adema proposes that we reimagine the scholarly book as a living and collaborative project—not as linear, bound, and fixed, but as fluid, remixed, and liquid, a space for experimentation.
She presents a series of cutting-edge experiments in arts and humanities book publishing, showcasing the radical new forms that book-based scholarly work might take in the digital age. Adema’s proposed alternative futures for the scholarly book go beyond such print-based assumptions as fixity, stability, the single author, originality, and copyright, reaching instead for a dynamic and emergent materiality.
Sounds like hypertext!
Interestingly there’s another “scholarly book” I started reading - Beyond the Age of Machines, as @khinsen mentioned on the limitations of mathematical modelling - that presents itself as a work in progress, a public open-ended experiment.
What you see here is the process of writing a book made visible. It is this process, much more than the outcome, that generates insight. .. This site is under construction. It will be for a while. Possibly forever. That’s a feature, not a bug.
The evolving table of contents links to those chapter drafts that already exist. Those at early stages of writing are labelled with a construction icon. The content of any chapter, and the table of contents as a whole, are still subject to revision and wholesale rearrangement.
You can read the chapters in any order you want. They refer to each other with links in the text so you can skip back and catch up on the background you may have missed.
Aha, so it’s a hyperbook. Depending on how such a document is allowed to get closer to an application.. We arrive at the UI as a Book, or the book as user interface. Why not, the tablet is a primitive form of UI for communicating ideas across individuals and generations.
The word book is a weird one, how it sounds.
The word book comes from the Old English bōc, which in turn likely comes from the Germanic root *bōk-, cognate to “beech”. In Slavic languages like Russian, Bulgarian, Macedonian буква bukva—“letter” is cognate with “beech”. The word букварь (bukvar’) refers to a primary school textbook that helps young children master the techniques of reading and writing.
It is thus conjectured that the earliest Indo-European writings may have been carved on beech wood. The Latin word codex, meaning a book in the modern sense (bound and with separate leaves), originally meant “block of wood”.
So it is code.
code (noun) - From Latin codex meaning “system of laws, law-book”. In Old French caudex (“book” or literally “tree trunk”), a book made up of wooden tablets covered with wax for writing.
DynamicLand is, at least for now, a community built around a toolbox. I wouldn’t even count that as conviviality, it’s a form of collaborative research. The real challenge for conviviality is supporting communities for which the tools are just a means towards a non-tech end.
That’s also a source of disagreement I sometimes have with free software advocates (the variety that opposes “free” to “open source” in insisting on the goal of empowering users). They point to vibrant developer communities that welcome everyone to join, and consider that to be conviviality. But most people don’t want to join a developer community. Interact with it, yes, why not, if that’s what it takes, but from a distance. Ultimately they want to use software, not develop technology.
From a cursory look at that book’s Web site, it looks like what she describes has been around for a long time, but we don’t call it “books”. The totality of the scientific literature, i.e. all journals put together, forms such a body of knowledge with multiple pasts and futures. It’s the result of a very loose collaboration. Maybe what she advocates for is a more focused collective work, resulting from more intense collaboration. There’s indeed not much technology support for that, as all existing collaborative technology I know focuses on converging towards a consensus.
From Multi-level Selection and Cultural evolution. (My opinion on multi-level selection has changed, since then.)
In essence, I am searching for a digital language that describes the rules of a group / community , that will have the same functionality as the DNA in organisms.
A. The DNA is interpreted so as to determine the structure of proteins
This language will be compiled to create communication tools that permit the behaviors that the rules allow.
B. DNA can be copied and transfered into another organism.
The digitization of the rules will permit a group to copy the institutional rules of another without any errors.
C. DNA contains information about the organism that is subject to the effects of evolution.
Similarly, each group will be able to mutate its rules and will be subject to a fitness function.What I hope with this is that the complexity of the rules of community institutions will increase to the point that their effectiveness will surpass that of the state or the undemocratic corporations.
This digital language is hoped to increase the speed of the cultural evolution of institutions.
My point here is that apart from enabling the coevolutionary development of the digital tools around a specific community, we also need to enable another community to copy their tools for their own needs.
Malleability alone does not help if the evolutionary changes can not be shared or copied easily.
That sounds like a request for modularity. Which I think malleability requires anyway, if it’s supposed to work for non-trivial use cases over longer times.
What made me react was, however, the reference to DNA. An important aspect that CS people tend to downplay or outright ignore is that DNA doesn’t determine anything completely. Not even protein structure. At best, protein sequence, but even the translation process from DNA to protein sequence is heavily regulated by processes independent of that piece of DNA.
The machinery employed by cells uses DNA but is not defined by it. Cells are not deterministic machines. Most processes in a cell are governed by physical constraints in addition to informational ones. And they are controlled at different structural levels, from the atomic scale to the scale of multi-cellular organisms. And if one organism copies another organism’s DNA, it often interprets it a bit differently.
Human rules (laws etc.) work much the same. They don’t define a formal system either. They are formalized bits and pieces whose interpretation depends on larger informal structures.
Software does not behave like that. Machine learning systems come a lot closer. What societies need to work out is how much formal/deterministic rules they want in their organization, compared to how much informal interpretation. I don’t see much discussion of that question so far.
I don’t think that being part of a developer community counts for conviviality neither, particularly because of Illich critique of specialists and their exclusionary relationship with knowledge. And I think that people want to develop and adapt technology constantly, but not as a software developer does, particularly people want that in places where there is a strong repair culture in opposition to buy/use/damage/buy cultures that I have seen mostly in wealthy countries, where repair is a more marginal and less cost-effective cultural practice.
But to clarify myself better, first I need to explicitly state what we understand for conviviality.
In the mindmap where I presented our genealogy to convivial computing, I took the ideas from Illich and connected them to our local practices:
Conviviality would be the characteristic of those tools that, when used, make their users more autonomous, more capable of transforming the world according to their own needs and desires, and freer and more creative in doing so.
I call a convivial society one in which modern tools are at the service of individuals who are integrated into the community, rather than at the service of a body of specialists. A convivial society is one in which [the person] controls the tools.
And I pointed to three demands made by Illich for such tools – for Illich the concept of tool is pretty broad (includes institutions, material/social artifacts, etc.):
- they generate efficiency without degrading personal autonomy.
- they don’t create slaves or masters.
- they expand the radio of personal action.
Later I connected that to our local practices regarding malleable metatools, like Grafoscopio, pocket infrastructures and art expositions in our local hackerspace, related with computing but not reduced to it and acknowledging the bridge between our analog and digital practices:
So, we are constantly building and/or adapting technology and reflecting about that as part of our art, work, hacktivist, research and/or day to day practices. But, at the same time, we are trying to deconstruct the relationship of specialists with technology not only by creating welcoming diverse communities, but also by actively putting metatools, i.e. tools that are able to describe/modify other tools and themselves, thus easier to disassemble/reassemble for our particular purposes. Which is related not only with an embodied critique of the exclusionary specialists cultures, but also with the three demands made by Illich to convivial tools.
On these three demands, it’s is particularly interesting the relationship between tools and scale regarding conviviality. For Illich, a bike is a convivial tool for mobility while a commercial airplane is not. Which make me think not only about the unfulfilled promise of “bikes for the mind” of personal computing (and the good marketing phrase of Jobs, despite not knowing, again, about what he was talking about), but also about other things like our own Pocket Infrastructures and its resonances with movements like permacomputing or frugal computing and how systems like Pharo/GToolkit made the reading of complexity easier, but that would be for another post.
Finally, I would like to come back to the relationship between research and communities we make research with (not about). Using the proposed shortcut of author/ideas that rightly @eliot points, we can see that there is a deconstruction of specialization in Kay’s Dynabook, Victor’s Dynamicland or Freire’s pedagogy of the oppressed (BTW recently the Informática do oprimido was published and launched). But there is a contrast in the longevity of the collectives they work with. Dynabook’s children will grow up; Dynamicland’s space and resident visitors are, well, visiting; but Freire’s farmers in rural Brasil will continue to be so, even after the critical literacy practices that empower them. And I find this long lasting relationship with grassroots communities strongly related with conviviality in digital and analog tools, in the sense that research with(in) communities and not about them, recognizes their agency and transforms research itself, its methodologies, practices and objectives. A primary question in poly-center research of this kind is what gives communities more agency in their own terms? And that make us renegotiate even how the core concerns of malleable systems are embodied for those particular communities.
There are two different processes, though. In the first case, you are able to adapt your software as you go,
one commit after the other. In the second case, you are able to merge parts of two projects that have diverged.
In any case, building custom software for a community entails the danger of noone else taking advantage of the new algorithms / ideas.
You are right that the language I use on the article is not correct. DNA does not determine the structure of the proteins. But the same is true for some types of software.
A program that is used by one community can exhibit different behavior when used by another community. At the same time, it imposes constrains on the community and maintains those constrains.
On another note, formal systems may not be effective at capturing what is necessary for a community to function. This is similar to how we might define a description of how the DNA works, that might not capture the whole picture of the actual physical process.
This is an entirely new problem that does require thinking, it has multiple dimensions. Two things come to mind.
- To be able to change the formalization when there are errors.
- To formalize at a higher level where a formalization might be appropriate.
I personally agree with Konrad. We cant all be developers and most actually don’t want to. I believe that there will always be a class of people that will try to provide answers to specific subjects and would help the community understand the choices it has.
There is a very specific definition of what autonomy means from a biological point of view that can be generalized. It means that a system/community is closed to efficient causation, or closed to constrains.
Given that developers are efficient causes, since they have inputs and produce a new version of the software, a community must be able to reproduce the developers, thus a community must be able to educate a new developer to replace the old ones that retire.
If not, the community is not autonomous, because an external force dictates the way the software is updated. For example, grants by universities and education by universities.
It is for this reason that I agree with Konrad that developers need to be part of the community and be sustained by it, reproduced.








