I forgot to mention that I coauthored a paper with Joel Jakubovic, a grad student of my collaborator Tomas Petricek, published in The Programming Journal. We got the Editors’ Choice award. Tomas made a nifty website about it.
Abstract
Programming requires much more than just writing code in a programming language. It is usually done in the context of a stateful environment, by interacting with a system through a graphical user interface. Yet, this wide space of possibilities lacks a common structure for navigation. Work on programming systems fails to form a coherent body of research, making it hard to improve on past work and advance the state of the art.
In computer science, much has been said and done to allow comparison of programming languages, yet no similar theory exists for programming systems; we believe that programming systems deserve a theory too.
We present a framework of technical dimensions which capture the underlying characteristics of programming systems and provide a means for conceptualizing and comparing them.
We identify technical dimensions by examining past influential programming systems and reviewing their design principles, technical capabilities, and styles of user interaction. Technical dimensions capture characteristics that may be studied, compared and advanced independently. This makes it possible to talk about programming systems in a way that can be shared and constructively debated rather than relying solely on personal impressions.
Our framework is derived using a qualitative analysis of past programming systems. We outline two concrete ways of using our framework. First, we show how it can analyze a recently developed novel programming system. Then, we use it to identify an interesting unexplored point in the design space of programming systems.
Much research effort focuses on building programming systems that are easier to use, accessible to non-experts, moldable and/or powerful, but such efforts are disconnected. They are informal, guided by the personal vision of their authors and thus are only evaluable and comparable on the basis of individual experience using them. By providing foundations for more systematic research, we can help programming systems researchers to stand, at last, on the shoulders of giants.
Congratulations, Jonathan!
Glad to see you are on a “publication streak”.
Are you planning to present this work at 2024?
Best
Enzo
Thanks Enzo. Joel presented it this year in Tokyo. Cheers
Hi Jonathan,
Not having too much free time, I only skimmed over your article, and peeked into the site, nice one! I see a lot of similarity in the background, but I had an issue that you probably don’t hear too often. I think your abstraction is not deep enough. Although a generation younger, I have been building information systems from requirement negotiation to deployment and maintenance in the past 25+ years with a different core vision.
We cooperate with and via information systems that themselves are cooperating networks of various modules. This cooperation means learning and changing the state of the system through their modules and that goes from copying files, deploying existing modules, to changing their configuration or behavior – that is what we call “programming”. Thus, the “programming system” is just another module responsible to interact with the internals of a module, including itself of course. In this context, the ultimate module is the runtime that allows all the other modules work and cooperate in a particular environment: programming language and ecosystem over an abstract runtime or an operating system.
This approach allowed me to create a framework (the runtime and what I think you call a “programming system”) that I needed to implement other target systems (sometimes in hybrid environments). Testing it with your questionnaires:
Self-sustainability, 1: Add items runtime – yes. 2: Programs generate and execute programs – partial (as much I needed it). 3: Persistence – yes. 4: Reprogram low level – partial (metadata yes, runtime: code generation and build yes, “save algorithm as code” no). 5: Change GUI – yes.
Notational diversity, 1 Multiple syntaxes – yes (if you mean multiple programming languages and persistence methods). 2 GUI over text – yes. 3 View as tree – NO! It’s a free graph without such limitations. 4 Freeform – yes.
This was back in 2018, since then I learned that 1: the hard questions come after you have a working system on this level, and 2: a working prototype is an excellent cause to be rejected. This is too heavy for a pet-project, so I abandoned the main research and use bits and pieces in paying jobs (at this moment, creating a hand-coded knowledge base over the European XBRL filings for academic research). However, your research overlaps my playground, so here is another message in the bottle… 🙂