2024-11-10 17:30 • 506 words

Jonathan Edwards delivered a keynote adress to the Workshop on Live Programming, in which he talked about Software substrates. He defined them as a conceptually unified persistent store for both code and data, with a UI for direct manipulation on that and live programming within that state. In such a substrate there would be no division between development time and runtime. Using and the system and programming it would be only different ends of a spectrum, everything happens in the same "world".

He contrasts the idea of a software substrate to what he calls "the stack", as pars pro toto for conventional software engineering, and conceides that the idea of substrates has been thoroughly beaten by the stack since the 1990es. He asserts that substrates are better suitable for a class of problems, that lie in-between with regard to complexity, for which spreadsheets are not powerful enough, but which do not yet warrant building a conventional software system around them, as that would be too expensive. He sees low-code/no-code competing on that ground as well, but says that these are attempts to "template the stack", and therefore cannot establish themselves successfully and durably.

Edwars proposes a research agenda, on Data-first software, with the goal to generalize spreadsheets and make them more powerful. The ideas and problems to be solved include: trying out UI metaphors beyond the grid, version control for the data that is end-user friendly, building in support for changes in types and schemas, treating code as meta-data, which should be kept small, inspectable and malleable, adding interoperability with The Stack via HTTP-APIs, and providing a subset of the features of conventional database management systems.

I think that is a very interesting problem space. How could software look like that empowers the user without coercing them into becoming a software engineer. I think if you want to get there you need a great number of these "in-between" problems and folks from both ends of the spectrum with a desire and willingness to collaborate on the making of that substrate, with their egos so much in check that it does not become patronizing experience for either side. I think the RAD tools of 1990es like Visual Basic and Delphi were on to something there, they were certainly erring on the side of "the stack", but one could learn a great deal from them. The WYSIWYG approach to form building, with all its warts and limits, would have enabled designers without any programming knowledge to contribute an actual part of the actual software, which is in stark contrast to today's common approach, in which designers use software to paint (very credible) images of what a software might look like, that are not executable in a meaningful sense at all, which are then thrown over to engineering in order to be recreated from scratch.

If software substrates would enable an intellectual cohabitation, if you will, of end users, domain experts, designers and engineers in the same medium, it would be a huge achievement in my eyes.