Galactic Premiere of Subtext 2

Here I am live-blogging myself at OOPSLA. I guess you know you have arrived when you get heckled by Guy Steele. Actually the talk seemed to go over pretty well.

I have posted a video of essentially the same talk. As always, comments welcome.

12 Replies to “Galactic Premiere of Subtext 2”

  1. Let me be the first to congratulate you – this is some fantastic work.

    I have worked in “visual languages” before (LabVIEW, Simulink, Stateflow), but have always resigned myself to saying that they just don’t scale up.

    You have just shown a method that could actually scale. Thank you.

  2. Sigh. I was expecting Star Wars – Return of the Jedi theme music at the beginning…

    I have to admit the force is strong in this one after the first episode(or is it third?) intrigued but left me wanting more. You’re tempting me away from the dark side (and fun of AI theory) with a few insights there…

    Still, I can’t help but think the interface feels awkward especially as columns radically jump about and rearrange the graph, in the process rapidly changing context for this beginner. A definite UI no-no. I think if you created some transition animations along with dialog from point A to B, that much of the disorientation could be reduced there. It all happened too fast and I felt a little lost. Also; personally I’d like something along the lines of better visualization of the flow graph. I’ll have to watch the video again sometime and explain why I feel dirty visualizing program flow as easily as you do… can’t quite place why yet. Bad habits possibly.

    I also have a real bone to chew with the performance of any form of live programming on current sequential processors without seeing any actual hard results. I can’t help but think of the scaling issues in numerous other functional object reactive languages I’ve seen as complexity in programs grow. Self and the SuperGlue paper I read recently comes to mind. I’d appreciate your perspective on the performance aspects of live programming, and especially if I’m unfairly labeling Subtext2 as functional reactive programming. What do you call it? Functional Logic gets mentioned a lot. Does using objects make it a FORP or a faux pa? 🙂 Please don’t take me too seriously… I’m only a hobbyist programmer that hates programming as I learn it, and keep looking for alternative architectures & interfaces. I just think the way we’re programming now is fundamentally flawed; trying too hard to ‘design’ systems, rather than ‘evolve’ them. Why I like the dynamic nature of the schematic table of Subtext2 and feel that aspect is where we need to head, only presented in a manner that’s more intuitive. What you’ve come up with thus far interface wise is excellent though. Lots of ideas to explore there. I just feel the architecture underneath needs to evolve before these kinds of live programming interfaces can flourish at scale.

    The problem I see with sequential processors is that one process relies on another process to have completely executed before it can. That relies on yet another process, and endlessly down the tree. This just introduces latency because you can’t guarantee when a process will have time to think and others waiting on it are then blocked. We’re back where we started then; having to develop complex layers of software algorithms inside of compilers and more layers of hardware cache in order to cope. I just find the thought process behind that maddening and why I think the concurrency and real-time issues really need to be solved first. But then again if you build something better maybe they will come… so I applaud your efforts.

    Thinking, thinking, thinking… a Darth Vader voice-activated, eye-tracking mask with heads-up display would be an ideal control device for this. 😉 I could rule the Empire! Muwhahaha. Only kidding. Or so I want you to think.

    Were there any other live programming languages at OOPSLA this year?

  3. Great presentation. Concise and intuitive. It’ll be interesting to see if Subtext can move from proof-of-concept to something that can be used for real work.

  4. I agree with the other comments, this is great work! I am interested in hearing what Guy Steele and others at OOPSLA were thinking about your work?

  5. Excellent presentation – i also am looking forward to more info about the feedback you have received from the talk!

  6. Exciting and inspiring stuff. What impresses me the most is the close alignment of the actual, working prototype with your paper prototype. It’s a testament to the importance of upfront design and should serve as a healthy antidote to the current tendency to prefer code-and-refactor to good old-fashioned thinking. (The ability to change a design on the fly is of course important too, but too often that seems to be taken as an excuse for not having a design at all.)

    Schematic tables look like a neat idea, although they invite a lot of foundational questions that I don’t yet feel equipped to explore. It’s not obvious to me, for example, that they belong in a programming language at all, even if they are as neat as they seem. But hey that’s the whole idea: this sort of work forces us to confront some of these questions rather than just plodding along with our blinkers on.

  7. The sudden reordering of expressions in the schematic did take me by surprise, and surprise is the key concept in Craig Overend’s report above. Disorientation and awkward program feel is a resulting effect, but the cause is probably a violation of The Rule of Least Surprise. In other words, it is not the complexity of reordering expressions that is likely to lose users’ focus, but the sudden change. It’s not the policy violating Raskin’s golden rule. Most push-button refactoring of textual code is sudden, yet the user generally doesn’t feel disoriented. A search-and-replace feature is also similar to push-button refactoring, yet it’s not disorienting, either. Subtly, I am suggesting there is nothing wrong with the policy of reordering expressions, but perhaps the mechanism could use some reworking?

    The policy of automatic expression reordering is what impressed me most from the demo. Jonathan, if I may suggest, you could improve your 30 second elevator pitch to illuminate this advantage. The 5 minute “Schematic Tables in a nutshell” seems dead-on, but the 30 second elevator pitch might include something like, “I’m not looking to manage your labor, I’m looking to eliminate it.” This quote is often uttered by a friend of mine who shares your interest in the creative act of programming. My friend uses it to make clear that his software reduces a common maintenance bug pattern. His concern for easily excluding and augmenting code to correctly match evolving requirements seems to convey the same message you started off your presentation with.

    I have more thoughts about schematic tables, and I’ll try to share them when I have more time to form a cohesive thought.

  8. Nice presentation. It doesn’t present many new concepts for those who have read your paper, but its great to be able to see schematic tables in action. Your point about the convergence of switches, if statements, and polymorphism was particularly striking. I also really liked how it was immediately able to derive that the function was undefined for all input values >= 2.

    I didn’t find the the sudden reordering of expressions to be too disorienting. Part of the issue might be due to the general unfamiliarity of working with code this way, but transitions might also be beneficial to help correlate the elements from the original state to the new state (I realize that could be really tricky). For me, it was actually the focusing that was a little harder for me to wrap my head around at first.

    So far, all the schematic tables we’ve seen have dealth with simple variables (ints and booleans). Have you figured out how this idea would be extended to work with more complex data structures?

    —–

    Kevin,

    Thanks for the comments. Everything is a tree in Subtext, so that is what complex structures are. I had a bit of this in the paper, but didn’t get to implement it. The idea is to replace the standard A.B.C path names by expanding the row containing a reference to the structure into a tree of indented rows.

    What I have since realized is that dereferencing (the traditional “.” operator) should implicitly make a conditional test on membership in the class defining the field. Then I get a bunch of stuff like in functional pattern matching. Ironically, I could do this in Subtext 1, but this time I tried a different model of field definitions that is not well suited to this purpose. Going to take some work to fix this.

    Thanks again for your help with WPF.

    Jonathan

  9. I just caught up with the whole of your blog so far. I read all your wranglings with the UI. Looks like you have really made a breakthrough here. Subtext as shown in this video has (is?) an excellent user interface. A massive improvement on the earlier version. It’s so nice that I really want to play with it! I don’t suppose it is portable off Windows though.

  10. There is to little IT in the programming, and to much programming in the IT.
    Subtext 2 can prove it – or is it Context 1?

    Why not add typing to the mix?
    But not in the values (dynamic typing) or in the variables plus the interfaces (static typing).
    Do it instead in the logical place – in the communication you are describing in the table. When it is needed you can add some logic for dynamic (or static)convertions in the right places.

    You can also do abstract typing (meaning and valid operations instead of representation) that can variate under the program.

  11. Jonathan,

    The idea of programs as graph has been around since the 70s at least and your incarnation is certainly bringing it up to date. You are exploiting all of modern technology from the neat graphical interface to the logic and math that is done behind the scenes!

    I want to do a similar tool for my PhD, although for proofs not programs, and you’re raising the bar for what it means to be user-friendly and fuzzless to the core of the problem.

    One suggestion I want to make is to add keyboard support very soon. You are in that the actual typing of code takes up a lot less time than debugging, adapting and reviewing, but if you start from scratch then there will be no code to debug or adapt unless someone types it in. And you need to type in quite a lot of code in order to make debugging and maintenance realistic.

    I think that adding keyboard support could really be quite easy: use tab to jump between the red question marks. Open up the search window as soon as someone types over the question mark. That’s it. And you could add a Shortcut like Ctrl-Click on a line to splice it. I think this would already suffice to make typing as fast as in a text editor. And of course: you absolutely need copy-and-paste 😉

    I am looking forward to your next great version!

    Robert

    ——-
    Robert,

    Thanks for your comments. I agree that it should be straightforward to do everything from the keyboard. The arrow keys are a natural for traversing a grid. And since you are not in text-editor mode most of the time, single keystrokes can be commands.

    Or voice! OSX and Vista have speech recognition built-in these days. I so want to do a hands-free demo.

    So much to do, so little time.

    Regards,
    Jonathan

Comments are closed.