Author: Jonathan Edwards

To: the crazy ones, the misfits, the rebels, the troublemakers, the ones who see things differently
Subject: you should write an Onward! paper

I and many people I know who are doing interesting work have been repelled by the bullshit parts of Academics: the gatekeeping, the compartmentalization, the performative rigor. Many of us have chosen to not play those games and instead make our own way as independent researchers. I’ve been in this fight for 20+ years now and I’m going to give you some advice you probably neither expect nor want to hear: publish.

Publishing a paper is the only proven way to engage with other researchers over the long term. Many people post demo videos and “web essays”, and if those meet your needs then by all means use them, for they are a lot easier and less risky than publishing papers. But they reach a different audience, mainly professional developers looking for something inspiring beyond the stagnant state of our art. They are not so effective in engaging with other researchers working on deep hard problems. Only papers have the time and space to explain our work in sufficient detail for others to learn from it and criticize it. Only papers painstakingly unravel the connections with other people’s work that we are building upon or improving upon. Only papers contain these burdensome elements because the peer-review process demands it, and for good reason: they are what carry a conversation between researchers iterating and refining new ideas. That is how progress actually happens, “by standing on the shoulders of giants”.

We need to ask ourselves a tough question: are we trying to add to human knowledge, or are we providing entertainment for jaded developers? The latter can be valuable, like science fiction, setting aspirations for the future. But to get to that future someone needs to solve hard problems in ways currently unimagined, and then communicate those discoveries to others who can appreciate them and improve upon them. Peer-reviewed papers are the best way we know to make progress happen.

I’m the program chair for Onward! Papers 2024. Onward! is expressly designed for people like us working on the fringe. You will not find a more welcoming place to publish computer science research. Onward explicitly reduces the need for rigorous evaluation and encourages interdisciplinary early-stage work with big aspirations. That said, you will still need to explain your ideas in concrete detail and convincingly argue their benefits over alternative approaches. Check out some of the recenty accepted papers. See the conference website for more details. Onward! gave me a crucial boost when I was getting started as an independent researcher. You should write an Onward! paper. Get in the arena.

The submission deadline is April 25, so you need to get started now! It is hard. In the worst case you are rejected, but at least you will get constructive feedback on how to convey your ideas more convincingly. As chair I will do my best to see that the reviewers provide helpful feedback. In any case just having put in the effort to write a paper will inevitably refine your ideas and your ability to explain them. In the best case you get an archival publication of your work, and you connect with a community of other researchers. My DMs are open.

Onward! and upward,
Jonathan Edwards

P.S. Thanks for helpful comments from Tomas Petricek, Stephen Kell, Geoffrey Litt, Mariano Guerra, and Richard Gabriel.

Too much Twitter has distracted me from this blog. I even forgot to mention my last paper: Live & Local Schema Change: Challenge Problems, with Tomas Petricek and Tijs van den Storm.

Schema change is an unsolved problem in both live programming and local-first software. We include in schema change any change to the expected shape of data, whether that is expressed explicitly in a database schema or type system, or whether those expectations are implicit in the behavior of the code. Schema changes during live programming can create a mismatch between the code and data in the running environment. Similarly, schema changes in local-first programming can create mismatches between data in different replicas, and between data in a replica and the code colocated with it. In all of these situations the problem of schema change is to migrate or translate existing data in coordination with changes to the code.
This paper contributes a set of concrete scenarios involving schema change that are offered as challenge problems to the live programming and local-first communities. We hope that these problems will spur progress by providing concrete objectives and a basis for comparing alternative solutions.

If you have any other good examples of schema change problems please let us know.

Pretty soon we will all be connected to the internet all the time. Satellites will fill in the last remaining dead zones. Cheap ubiquitous connectivity is going to break many assumptions of the software industry. Afterwards it will appear to have been inevitable.

Continue reading “Ubiquitous connectivity and duplex applications”

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.

Excerpted from: Future of end-user software engineering: beyond the silos [PDF].

For example, consider “Frieda“, an office manager in charge of her department’s budget tracking. (Frieda was a participant in a set of interviews with spreadsheet users that the first author conducted. Frieda is not her real name.) Every year, the company she works for produces an updated budget tracking spreadsheet with the newest reporting requirements embedded in its structure and formulas. But this spreadsheet is not a perfect fit to the kinds of projects and sub-budgets she manages, so every year Frieda needs to change it. She does this by working with four variants of the spreadsheet at once: the one the company sent out last year (we will call it Official-lastYear), the one she derived from that one to fit her department’s needs (Dept-lastYear), the one the company sent out this year (Official-thisYear), and the one she is trying to put together for this year (Dept-thisYear).

Using these four variants, Frieda exploratively mixes reverse engineering, reuse, programming, testing, and debugging, mostly by trial-and-error. She begins this process by reminding herself of ways she changed last year’s by reverse engineering a few of the differences between Official-lastYear and Dept-lastYear. She then looks at the same portions of Official-thisYear to see if those same changes can easily be made, given her department’s current needs.

She can reuse some of these same changes this year, but copying them into Dept-thisYear is troublesome, with some of the formulas automatically adjusting themselves to refer to Dept-lastYear. She patches these up (if she notices them), then tries out some new columns or sections of Dept-thisYear to reflect her new projects. She mixes in “testing” along the way by entering some of the budget values for this year and eyeballing the values that come out, then debugs if she notices something amiss. At some point, she moves on to another set of related columns, repeating the cycle for these. Frieda has learned over the years to save some of her spreadsheet variants along the way (using a different filename for each), because she might decide that the way she did some of her changes was a bad idea, and she wants to revert to try a different way she had started before.