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.

This entry was posted in General. Bookmark the permalink. Both comments and trackbacks are currently closed.

15 Comments

  1. philip andrew
    Posted December 2, 2014 at 9:44 pm | Permalink

    Hi Jonathan, is there any code available?

    • Posted December 11, 2014 at 12:30 am | Permalink

      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.

  2. Posted December 3, 2014 at 2:02 am | Permalink

    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.

    • Posted December 11, 2014 at 12:28 am | Permalink

      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.

  3. Posted December 9, 2014 at 1:55 pm | Permalink

    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.

  4. Paul Tarvydas
    Posted December 11, 2014 at 11:46 am | Permalink

    I’ll be most interested in following this. I like where it’s going.

  5. ben nun
    Posted December 12, 2014 at 7:45 am | Permalink

    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!

  6. ben nun
    Posted December 13, 2014 at 2:26 pm | Permalink

    I am wondering, why you implement it in dart.
    http://www.theregister.co.uk/2014/11/04/improving_javascript_google_throws_atscript_into_the_mix/
    More functional languages like rust or swift seem to become mainstream.
    And the new java-vm seems to be llvm.
    http://blog.llvm.org/2014/07/ftl-webkits-llvm-based-jit.html

    • Posted December 14, 2014 at 12:01 pm | Permalink

      I chose Dart because it runs in the browser and I prefer its development experience, for example collection classes and refactorings.

      • Posted December 14, 2014 at 7:15 pm | Permalink

        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.

  7. Posted December 14, 2014 at 4:22 am | Permalink

    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.

    • Posted December 14, 2014 at 11:48 am | Permalink

      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.

      • Posted December 14, 2014 at 7:43 pm | Permalink

        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).

  8. Dave McCabe
    Posted December 22, 2014 at 3:20 pm | Permalink

    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!

    • Posted December 23, 2014 at 8:44 am | Permalink

      Thanks Dave. I plan to write this up in an Onward paper this spring.

  • Subscribe to Blog via Email

    Enter your email address to subscribe to this blog and receive notifications of new posts by email.