My pandemic project has been to get down to solving the hard research problems needed to make Subtext real. I started with the Update Problem, which is at the heart of the imperative vs. functional programming dilemma. My last run at the problem was in Two-way Dataflow. I now have a new approach and prototyped enough of it to believe it works. It has restricted “hygienic” forms of writing through aliased pointers and triggering callback cascades that are safe from many of the usual pitfalls in imperative programming (and equally their emulation in monads and effect handlers). The big win is having updatable views, which is cleaner and more compositional than the zoo of state management frameworks engendered by reactive programming architectures.
Unfortunately I’ve concluded that I can’t publish these ideas in their current state. Neither practitioners or academics will consider such radical ideas without proof that they work in practice on realistic cases. Small contrived examples don’t cut it. TodoMVC doesn’t cut it. They’re right: extraordinary claims require extraordinary proof. I need to build out a fully working programming system creating credible applications. Research, like everything else, requires proof of work. And I don’t have graduate students to do it.
I’m just not ready to do that work now, because there is another fundamental problem that needs to be solved first: the Edit Problem. This is really a cluster of problems related to making structured editing beneficial enough to displace text editing. Actually this is a more important problem: not everyone has to update data, but everyone has to edit code.
I guess the point of this post is to help me work through the research grieving process. I am very disappointed to find myself yet again believing that I have a new solution to an important problem yet unable to communicate it to anyone. Add it to the stack and move on.