Machine

Grant Recipient: Jonathan Manning, University of Tasmania

Report 1 - July 25, 2008

My project is Machine, a visual programming tool designed to make application design intuitive and accessible for casual programmers, while still being relevant to more experienced developers.

I had the idea for Machine back in 2006, when I was first getting into Cocoa development. The drag-and-drop method of connecting up all of the components of an interface really appealed to me, especially since I was a GTK+ refugee. I started to think about how this model could be extended to its extreme, and began to examine the academic field of visual programming.

Visual programming is not new. One of the first experiments with programming computers in a visual style was Sketchpad (Sutherland, 1963), which provided a simple constraint-based graphics system, and allowed the user to manipulate abstractions like the constraints on geometry. Sutherland then created a dataflow language that allowed for the visual creation, debugging and execution of these graphical programs. The field only really took off, however, with Pygmalion (Smith, 1975), which provided an icon-based paradigm, and generated a subset of Smalltalk as its output.

However, none of these research projects have either been useful outside of academia, or designed for use on the Mac. This changed with the release of Mac OS X Tiger, which included two important applications: Quartz Composer, and Automator.

Quartz Composer is a visual programming language designed for the very specific purpose of creating an animation. The components of the language are called 'patches', and communicate with each other to create the individual components of the animation. Flow control is provided with the concept of 'macro patches', which are patches that contain sub-patches, and perform operations on them (such as executing the sub-patches a number of times). Because each patch is isolated from all patches not directly connected to it, and there is no global data storage, QC is a very 'pure' language. QC programs are called 'compositions', and are designed to have exactly one program state: 'running'. There are no start-up or shut-down routines.  Because the visual complexity of compositions can quickly become overwhelming, QC suffers from a reputation of being rather inaccessible to those who just want to quickly make something pretty.

Automator, as its name suggests, was designed to automate repetitive tasks. The fundamental component of the language is an 'action', which accepts one (and only one) input value, performs an action with it (such as printing a given document, or taking a screenshot and returning the bitmap), and generates one output value. Automator programs are called 'workflows', and are designed to run, perform a task, and exit immediately. Some flow control is provided with a 'jump to start of program' action, and rudimentary functions are supported with the ability to run other workflows. Data storage is provided with 'get/set variable' actions. Overall, the language feels like a very high level, graphical version of assembly.

So there I was: I wanted to make applications as easily as I could in Automator, but with the flexibility of Quartz Composer. Happily, the AUC announced its seeding grant program, and I sent them my ideas.

The concept behind Machine takes the programming paradigm of Model-View-Controller to a visual extreme. Each of the three components occupies its own view: the View is an interface built from a library of components, in a manner similar to Interface Builder; the Controller is the connected set of programming 'components'; the Model is a Core Data entity graph. By cleanly separating the visual aspects of a program, this approach makes it much easier to better design an application.

In May, the AUC flew me up to UNSW for a short workshop on what they expected from this project, and to help me figure out exactly what I was expecting. I figured out my audience - casual programmers, and power users who want to get something reasonably complex done quickly with a minimum of fuss. I then got to work paring down the list of ideas that I'd come up with beforehand. This was a painful process, but it's necessary to do this in order to create a sane spec. Feature creep is a blight that I need to avoid, particularly when designing a language; there's simply too much scope for random ideas to worm their way in and slow down development, or ruin the usability of the product.

I ended up with three broad goals for what users can do: design an application's behaviour, design an application's interface, and run the application. This seems a very small and obvious featureset, but it's sufficient for me to work towards, and all of the other fancy ideas I had (like debugging, or data access, or concurrency) can be added at a later date.

At the moment, I am in the middle of implementing the first prototype of the language, after having sketched up drawings of the interface, and drawings of simple programs. I expect this to be done in mid-August, after which I will be working on the run-time library that this language will require. In late September, I go into testing, and will continue testing and refining until Christmas. I hope to make a final public release at the end of January.

I eventually plan on selling Machine through my company, Secret Lab, though AUC institutions will get free site licenses. If you're interested in its development, I suggest you subscribe to my blog, where I post fairly regular updates on what I'm doing.

Thanks for reading, and I hope you find Machine as exciting as it has been to develop it!