Home » forums » LtU Forum

Subtext 2 Video

For those who haven't seen it, Jonathan Edwards has released a video demonstrating a prototype of his (live, dataflow based) Subtext 2 programming environment. Following up from his OOPSLA07 paper which was discussed on LTU recently.

By SamK at 2007-12-04 17:27 | LtU Forum | previous forum topic | next forum topic | other blogs | 8025 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Having watched the first 10

Having watched the first 10 minutes of the video, I can't help to think that what is really new here? The first 10 minutes of the video just show how to present pattern matching with guards semi-graphically with a bunch of boxes.

By Vesa Karvonen at Tue, 2007-12-04 21:00 | login or register to post comments

Keep watching the video.

Keep watching the video.

In my mind its not so much that this stuff is new, its that he does it well. Thats a very different (but at least as worthwhile) target.

By Joseph Gentle at Wed, 2007-12-05 13:00 | login or register to post comments

The rest?

I wonder if you watched the rest of the video, and whether your opinion changed at all? Anyway, also see some of the comments on the paper (start here) for some idea of what has impressed people. I'd say it's the convergence of a number of different interesting ideas, some of which are new and some of which are just well-executed or combined in a novel way.

By Matt Hellige at Fri, 2007-12-07 05:31 | login or register to post comments

hear hear fwiw

(in the great tradition of /. i haven't RTFA yet)

...thank goodness somebody out there isn't willing to sit still with the status quo. i think we need more possibly-hare-brained schemes like these as an occasional shot-in-the-arm, fire-under-the-ass.

By raould at Fri, 2007-12-07 19:45 | login or register to post comments

One of the main differences

One of the main differences is that it offloads a lot of the work onto the computer. Whereas pattern matching as seen in Haskell etc will check cases sequentially. In other words, it ensures that functions are total, and that there are no overlaps between cases (it provides automatic resolution when it is introduced). Each column may be viewed in isolation from the others (assuming the tree within doesn't depend on other columns with disjoint conditions).

There are also some other very cool ideas involved. Writing code for a particular example case, such that it is evaluated right in the IDE as you work on it. Function tree expanding to debug. Function names as comments not identifiers. Probably more, even.

I would like to see him use this on more complicated, user defined predicates, though. That would really be something. It would require some voodoo to have all the capability of the integer/bool types, I think.

By Michael Sloan at Mon, 2007-12-10 07:51 | login or register to post comments

Epigram and LOOP

I was reminded of the way Epigram calculates the possible patterns,
and you just have to request a case analysis. Coverage is definitely not decidable for the dependent case, and it doesn't have a nice interface for modifying your cases, but I think a lot of the interface elements might actually carry over pretty well.

The scope rule in Olin Shiver's LOOP macro would handle interesting
sharing of subcomputations like the examples with the graphical syntax,
but I don't think it's packaged as a separate "bdr-let".

By Brandon Moore at Wed, 2007-12-12 12:01 | login or register to post comments

Polymorphism part was slightly confusing

He's right of course that virtual function tables are essentially just branching based on type, but the innovation in it is that you define how a Dog should sound in the Dog class, and how the Duck should sound in the Duck class, rather than having a giant switch in an all encompassing MakeNoise function. In the video he seems to make the giant switch, but tries to justify that this is OK because of Subtext's 'focus' feature. Based on what was shown it looks like he could also have specified how the function should behave for classes totally outside the Attack class hierarchy. Also, the Ranged class didn't automatically inherit the power value from Physical as would happen in Java. I'm not sure whether these are bugs or features.

By dataangel at Wed, 2008-01-02 08:54 | login or register to post comments