Since my last paper was rejected I have been thinking about what to do next. To tell the truth, by the time I had finished that paper I had lost interest in the topic. It seems that for the last few years I have been lurching around in different directions. Here are some of my thoughts about a new strategy. Please let me know what you think.
Semantics instead of syntax
I have been focusing on non-textual programming. The name Subtext itself headlines that issue. I have demonstrated small-scale examples of how a non-textual language can make programming fundamentally easier. This just isn’t selling, for a number of reasons.
First of all, I get tarred with the past failures of visual programming. Small-scale examples are not convincing. More fundamentally, people just don’t want to admit that they aren’t smart enough. They are willing to admit that non-textual programming might help novices, but they don’t need it. And no one wants to write off their years of training in textual programming.
I need to change focus from syntax to semantics. I have to show how a new kind of programming language can offer higher-level concepts that make building certain kinds of systems dramatically simpler. Non-textuality might be acceptable as a requirement of those semantic benefits. Non-textuality can only win by hiding in a Trojan Horse.
One starting point is the model of hypothetical functional state that I demo’d at OOPSLA05. To make the idea more approachable, I should use a normal textual language if possible, even if only as a pedagogical aid. I may have to drop the name Subtext.
Top-down instead of bottom-up
The proper scientific method is to study special situations in which a new idea can be evaluated in isolation and detail. I tried that in my last paper, and it didn’t go over at all. Radical new ideas must first be strongly justified in order to be taken seriously. I need to take on a really big practical problem using a mix of new ideas. If the result demonstrates clear benefits to practicing programmers, that might provide sufficient motivation for the scientific process of isolating, evaluating, and refining the ideas. I strongly believe that such a communal refinement process is crucial, and that its lack is why so many of our languages, tools, and standards are half-baked.
The obvious domain to take on is web application frameworks. Basically what Macneil suggested some time ago: Subtext on Rails. Such web apps are really just the latest incarnation of the archetypal UI-to-a-DB application. I have repeatedly tried working on this domain, and repeatedly backed off because it is just so big, and so complicated by half-baked standards. But I have been making progress in little bits, and maybe have now gotten within striking distance.
Design instead of implementation
Subtext, or whatever it is called, will not have competitive performance any time soon. I need to position it as a modeling/specification/prototyping language. The big win comes from allowing a web app to be fully specified in a high-level declarative fashion without imperative semantics: no methods or events; and WYSIWYG live execution. A fully working prototype would be of great value even if it can’t scale into production. It could be used as as FIT-like specification tool, as an oracle for testing a production implementation, and as the source for transformations into production implementations.
Presentation; prototype; paper
My work flow has been to write a paper about an idea, prototype an implementation of it, and then present it. It might be easier to do it in the reverse order.