Subtext on Rails

My recent proposal to work on modeling capabilities fell flat, but elicited some good discussion of future directions for Subtext. Peter Marks wrote:

… I would rather see a complete re-examination of what lies underneath the World Wide Web. And then take the Subtext approach of banishing syntax, treating program as data, history, etc. … This would mean initially abandoning the UI demo and focusing more on the development of a system/infrastructure that works with and within the Internet.

Macneil Shonle wrote:

I wonder what “Subtext on Rails” would look like?

Some thoughts:

  • HTML/XML is a tree. It would be useful to have a language based on trees…
  • HTML/XML encodes a tree into a text string in a way that makes it awkward for both humans and computers. What if we treat the syntax as merely a serialization format? Give the programmer a tree-based UI, and give the program a tree-based semantics?
  • Templates suck. Every web programming language seems to be based on escaping code inside HTML. What a mess. You have to mentally juggle multiple syntaxes, multiple notions of context, multiple namespaces, multiple evaluation-times. What is needed is a uniform way to treat trees as both data and code at the same time…
  • The primary method of constructing HTML is copy & paste. Sometimes explicit inclusions are used. What is needed is a powerful and principled basis for copying and varying trees…

I haven’t really thought this through – I am just throwing it out for discussion.

5 Replies to “Subtext on Rails”

  1. Have you looked at Wheat? I don’t see any progress in the last year, but IIRC, it is roughly a language based on trees built for the web. I imagine a subtext-y development UI would be possible.

    [Yes, Kragen Sitaker told me about it. He sometimes posts here, so maybe he will have more to say. – Jonathan]

  2. I believe Dave Winer’s outliner also powered a scripting language.
    It didn’t have copy-paste semantics though.

  3. I totally agree with your comments on copy-and-paste and templates on the web. Web development, especially for end-users, people who like to work concretely, and people who like to copy and paste, is the primary motivating app for the next generation of Linked Editing that I’m working on.

  4. Yes, templates suck. I believe Wadler’s Links is adopting this style of programming. See, for instance, this example: http://groups.inf.ed.ac.uk/links/demossrc/dict-suggest.links
    Granted it’s early in the Links project.

    Interestingly, there is a trend away from this mix of metaphors called templates or server pages. The REST ideas have contributed to this trend. With REST you deal with resources on the Web. Interacting with the resource is limited to the strict adherence to the semantics of HTTP, e.g. GET, PUT, etc. Doing a GET of a resource returns a representation of the resource. Most RESTful designs use XML as the way to represent a resource. The beauty of this is that the client can choose to use transformations to display the resource as a web page: XSLT and CSS to produce HTML. A client that is not a web browser can work directly with the XML document.

    Note that a Subtext tree could be a resource. Further, a node in a tree could represent a resource. The links between nodes of a Subtext tree could be implemented, in some cases, as URIs. The URI then becomes the value of the arc label.

    Representing and storing a Subtext program as an XML document would be straight-forward. (Actually there are people calling for the storage of all programs in all languages as XML documents.) Constructing (programming!) Subtext programs seems to require a tree-based UI like you’ve already developed. I was also thinking along the lines of tree maps (see http://en.wikipedia.org/wiki/Treemap ).

    There are many tools available for working with trees visually. What’s missing, of course, is the Subtext engine (if I may use that term) reacting to what is being built. I think you have a very good start in implementing this engine. It’s still missing certain integral facilities like history.

    You could spend more time adding additional functions like sine, division, etc. to Subtext. I think that most programmers reaction to seeing the good ol’ fibonacci function implemented in Subtext is “So?”. But I have a feeling that starting with a set of “primitives” in the application’s or program’s domain and using (copying) these primitives within Subtext (the program) might make for an interesting demo. After all, Subtext is not about what particular computational actions can be performed, it’s about how to construct a program using copying and how these actions interact with other actions and the environment… and more, of course.

  5. HTML and XML documents are not trees, they are directed graphs. Both HTML, SGML and XML allow references between nodes using (in DTD speak) ID and IDREF attribute types. The graphs are represented poorly as trees because the documents must be serialised and it’s easier to serialise a tree.

    Similarly, programs are also directed graphs represented textually as a tree structure with “second-class” references between nodes.

    So, to me, a Subtext that could manipulate directed graphs would be a good way of working with XML data *and* programs (maybe even itself).

    [Actually, Subtext consists of trees strung with links, where the links are copies. Copies are either variants, instances, or references. So this is still similar to XML. I wonder if XSLT does anything smart about preserving ID and IDREF links? – Jonathan]

Comments are closed.