No Assembly Required

Building a toy for my children suggested an analogy with programming. Many toys come knocked down, requiring assembly, with instructions of the form “insert peg A into hole A, slide tab B into slot B, …”. This is just like the way we use names in programming languages, indicating parts that need to be attached by labelling them with the same name. The function call A is to be attached to the function definition A. Programming with names is like creating a program as a big pile of pieces with labels attached, and leaving it to the compiler/interpreter to assemble the pieces into something that works. Textual programs are knocked down.

The problem is that this approach boggles the mind when used with thousands or even millions of pieces. Modern IDE’s like Eclipse strive valiantly to help us imagine how things will plug together, but this is an impossible task. Even my kids know that all the King’s horses and all the King’s men can’t put Humpty together again.

The goal of Subtext is to fabricate programs as working wholes. No assembly required.

Share this:

4 Replies to “No Assembly Required”

I just had the same thought about a month ago, watching my nephew trying to assemble one of his toys. Then I thought that a programming language could exist that each function has multiple exits, and functions’ inputs could be attached to functions’ outputs, just like in a toy, or in an electronic board. Such a language would not need a) conditional statements, since each value created in the program would be a possible ‘exit’ point of a monadic function, b) control flow statements, since control flow would come natural by attaching outputs to inputs. An output would be activated as soon as a value was present at that point (i.e. when the output value or values are set), causing execution of attached function.

This comment is slightly off topic but I took this description of assembling things by attaching components one step further: I would want to see data flowing through these components. This, in turn, reminded me of Flow Based Programming (FBP), an idea that has been around a long time (http://www.jpaulmorrison.com/fbp). FBP programs are constructed by linking together functional blocks. One recent discussion in the FBP Wiki centers around its relationship to the programming language Erlang (http://erlang.org). Erlang, FBP and also one of the Oz languages defined in the “Computer, Techniques and Models” book (CTM) (http://www.mozart-oz.org/papers/abstracts/VanRoyHaridiBook.html) share a common characteristic: all interprocess communication is performed using asynchronous messaging. There is no such thing as a Remote Procedure Call (RPC) or a Remote Method Invocation (RMI).

It might be nice for Subtext to have interprocess communication at some point. (My apologies if I have missed this function in the OOPSLA paper). What should it look like? How will it behave? Following the lead of the systems mentioned above, it could be implemented using asynchronous messaging. This is usually made available to the programmer via the use of ports. Ports in one process can be attached to the ports of other (remote) processes. A message (data) is sent out an output port and upon its arrival at an input port of a process that is designed to recognize this message, the process will be executed.

Perhaps Subtext can be given a built-in type: a Port which is a type of Value in the program tree. If the value of a port changes then those functions that are using the same port for input will “awaken” and begin executing. They react the same way any function reacts when one of its arguments is given a new value. The difference is that the port value may have originated at a remote function.

[Before I can do asynchronous I/O, I need to first figure out synchronous I/O, which is what I am working on now. – Jonathan]

But, wouldn’t this be close to compile-time inlining. I think run-time name resolution leaves just enough space for the essential OOP of polymorphism. That is, unless you could explain polymorphism in Subtext to me.

IMO pcmarks’ comment wasn’t off-topic at all – Jonathan’s remarks about the difficulty of having to force all events into a single time-line could have been taken almost word for word from my book “Flow-Based Programming”. With FBP, you view an application as trsnaforms being applied to streams of data, and suddenly programming becomes *much” simpler!