New Subtext screencast

We’ve published the final videos from the Future Programming Workshop. We will also be publishing a final report about our experiences and lessons from the workshop.

Included in the videos is my latest screencast about Subtext: Two-way Dataflow. The abstract:

Subtext is an experiment to radically simplify application programming. The goal is to combine the power of frameworks like Rails and iOS with the simplicity of a spreadsheet. The standard MVC architecture of such frameworks makes execution order hard to understand, a problem colloquially called callback hell. I propose a new approach called two-way dataflow, which breaks the program into cyclic output and input phases. Output is handled with traditional one-way dataflow, which is realized here as a form of pure lazy functional programming. Input is governed by a new semantics called one-way action which is a highly restricted form of event-driven imperative programming. These restrictions statically order event execution to avoid callback hell. Two-way dataflow has been designed not only to simplify the semantics of application programming but also to support a presentation that, like a spreadsheet, provides a fully WYSIWYG programming experience.

Comments welcome.

15 Replies to “New Subtext screencast”

    1. Thanks for your interest Philip, but no not yet. I need to write a paper first, and maybe that will explain enough to make the code possibly comprehensible but at the moment it definitely isn’t.

  1. Thanks Jonathan. Good to see the discussion on batching-up of changes and assertions. Are you imagining you could use batching as a form of transactional concurrency? In a multi-user system, your initial copy of the server’s todo list could be stale by the time you come to commit. In standard transactional concurrency this would mean discarding the transaction. In your system maybe it would be feasible to propagate the server-side changes into your transaction to re-sync it, rather than discarding it.

    1. Sorry for the delayed reply Roly. Google was spamming my notifications. Yes batched updates are meant to be atomic transactions, with all the usual serializeability problems. There are some possible twists like resyncing the transaction as you suggest but I’ve been putting off thinking about this stuff.

  2. I’m also wondering if there’s any code available. I’d really like to poke around with what you have, even if it’s just demo code.

  3. Both videos are very convincing!
    Are you planning to release only an IDE, or as well a portable commandline interpreter. I think an alternative syntax for IDE-UI concepts is useful, and sometimes more flexible, and often not that hard (e.g. classes in smalltalk).
    And yes I would love to play with the prototype as well!
    Good Luck and happy coding!

      1. But no threads, otherwise I would have gone with typescript (like Dart) for my own work :(. I wonder for a language that is designed to make concurrency simple, if its a good idea to use a platform that doesn’t support multi-threading.

  4. This is fascinating work! One quick question: how does two way dataflow handle the case where the function from input to output is either non-reversible, or the reverse of the function doesn’t give a unique solution e.g. sqrt? There was a hint in the video about this area, but I didn’t properly understand it.

    1. Thanks for your question. All functions are deterministic in both directions. The documentation of a function specifies what its reverse semantics is. It can reject some changes and report an error. It can be unidirectional and report an error on any change. In all of these cases you can override the function’s reverse behavior with your own custom code.

      1. If I might add, SQRT is actually reversible if you include “i” in your answer, e.g. SQRT(-4) = 2i, Square(2i) = -4, but now you have to represent imaginaries in your number format for something that probably won’t be useful to most people. It is a better idea to have an error condition: SQRT(-4) = error, and do not define reversibility for errors if possible. Likewise, 4 / 0 = positive infinity * 0 = 0.

        The key to reversibility is that all operations should lose no information, which is also the key to zero-energy computing 🙂 This is impossible in practice, especially for non-trivial programs, but its a nice exercise to think about. See Janus (scroll down to the second entry, the page describes two languages).

  5. Inspiring work. A pleasure meeting you and Sean at SPLASH recently. To me the most interesting part is the restrictions on upward flow. Do you describe these restrictions and their implications somewhere? Thanks!

Comments are closed.