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.
[update] Here lies Subtext 10
Why does the edit problem need to be solved first?
It is central to my goals. I’ve been deferring it for years to work on other things. It is time.
Can you point to a reference that provides an example of the edit problem?
Hi Dan,
The edit problem is just my term for the issues surrounding structured editing. You can find lots of references to the later. There is recent work by Chugh, Hempel, Omar. Also check out Jetbrains MPS.
Are you still working on the ideas you submitted to the Salon? Drop me a line
If you have a clear concept and a prototype, why not present them at a venue that accepts work-in-progress works? You can then shelve the work for now, but it is also preserved through a clear description you wrote, that can be useful to you later, and possibly to others.
I’ve tried that before. You pour your soul into a piece and then get no feedback.
I agree that moving beyond plain text editing is an important next step in programming. But it sounds like a lot of work, even more so than writing a new traditional editor. And the prior attempts haven’t seen much success. One of the best attempts I can think of is Leo, which is a good demonstration of how hard it will be to get the UI right.
Take you time. Let it stew. We’ll still be here RSSing.
Have you seen the concept of intentional programming?
There is short video showing it:
It’s very interesting how in this concept the problem of editing code is radically different.
IntentSoft was maddening. They had all this great stuff – the version control stuff hasn’t been matched AFAIK. But it was all treated as proprietary secrets and they never published about it or released it. Simonyi bankrolled the whole thing out of his billions. But he couldn’t share it.
Paul Chiusano and the folks at https://www.unisonweb.org/ will be very interested in your work. Some of the earliest work on the unison language actually was on the edit problem. They’ve since shelved it, but are still planning to get back to it.
Maybe you’re also interested in the MPS Projection Editor: https://www.jetbrains.com/mps/concepts/
I believe I understand the “Update Problem” somewhat, having “encountered”, ahem … stepped into, some of the traps of state management while adding effects to a (mostly) functional reactive computing environment. Your update added to my fears of the yet unknown monsters lurking ahead. 🙂 Thank you!
But I really came here to interrupt my own expedition into the unknown, wishing you, and all the researchers here, a Happy New Year.
Thanks, Enzo