We all just got back from the AUC’s /dev/world/2008 conference! It was a roaring success. You can download Paris’ Cocoa Polishing presentation slides here.

The other presentation slides and further notes will be available right here within a day or two:

• Beyond AppleScript
• Embedding OpenGL in Cocoa
• Polishing Your Cocoa Application

We were recently featured in the Sunday Tasmanian (our local newspaper) as an example of local iPhone developers. The first article on us of many, we hope!

We are insanely pleased to announce the release of Culture for the iPhone. Culture is a puzzle/strategy game that will have your mind racing to think further than your opponent can and to claim as much territory as you can, before it’s swallowed up by the oncoming hordes.

Culture is available for purchase via the iTunes App Store, and costs less than a coffee at our office*. Enjoy!

* Starbucks has such comfortable seating..

In my last article, I covered the basics of what a DSL is, and what they’re useful for. This week, I’m going to talk about what a DSL to manipulate the desktop should be like, what solutions exist already, and what we could do to improve them.

Last time, I discussed how users have a set of tasks that they perform often - web, email, file management - and how those tasks can be broken down into a collection of ‘task primitives’. Let’s take a closer look at how the user actually works with them.

User tasks tend to fall into one of two groups:

1. One-shot tasks, where the tasks launches, does something, and stops. They don’t hang around when they’re not doing something useful. Examples include downloading mail, resizing photos, and generating reports from a database.
2. Persistent tasks, where the task hangs around and keeps doing useful things, as and when required. Examples include text editing, IM conversations, and RSS reading.

Apple’s Automator is a great example of how one-shot tasks can be made into applications of their own. Using Automator, it’s easy to string together a series of tasks that execute one after the other, performing useful work until the chain ends. However, it’s impossible to create a complex, persistent application, like a web browser or alarm clock. This is not a bad thing, though - for what it does, Automator is the best in its class.

Automator is able to do what it does because it makes use of the Open Scripting Architecture, which is the OS-wide scripting framework that allows applications to publish scriptable actions they can perform. In other words, there exists a huge library of one-shot tasks ready for use. Some of the more graphically impressive ones are photo manipulation: resizing, applying filters, adding borders, cropping, and so on. Chaining a set of these one-shot tasks allows the user to create powerful macros.

But what about applications that need to persist? Let’s extend the idea of one-shot photo manipulation and consider an application that, when launched, sticks around and processes photos as they come, not photos that it was initially told to work with. Such an application exists: it’s called Picturesque, by Acqualia Software, and it happened to win an Apple Design Award for its ease of use and simplicity. This app simply presents a drop area where users can drop photos, which expands into a picture manipulation workspace. Users make the changes they want, and then save the photo. The process repeats until the user quits the application. In the meantime, the application occasionally checks for updates in the background.

We can immediately see that there are two tracks of tasks going on here: things the user instructs the application to do, and things the application will do on its own. The things the user directs the application to do tend to be one-shot tasks, or a chain of them. One of the important one-shot tasks that every application needs is ‘quit’. When a task is complete, the application goes back to waiting for more information from the user, or stops.

What we’re seeing here is the essence of GUI programming: there is a main loop, foreground tasks, and background tasks. A persistent task is either a repetition of independent tasks, or it is the application as a whole. With this in mind, all that we have to do now is select the one-shot tasks that compose our application’s behaviour, and work out how our interface interact with the tasks. (I’m completely ignoring things like data manipulation, or the problem of designing very complex tasks, like creating a slideshow presentation. This is just a very broad overview.)

So now that we know how our application is going to be composed, how do we express this in a DSL? Well, one already exists. It’s AppleScript, and it works quite well: entire applications can be written in it, and it’s as powerful as any other language on the system, with the added bonus of easily getting other applications to provide services. But AppleScript has an issue: it’s text. And writing text that turns into an application’s behaviour is less intuitive than visualising the workflow of the application’s functions - that’s why Automator was written in the first place.

So what can we do? Next week, I’ll be looking at ways to visually design complex workflows, and we’ll see if we can design an entire application visually.

Further reading:

• Use Cases and interaction design
• Picturesque - A great example of a one-shot application turned persistent 
• Our own product, Secret - Another great example!

Domain Specific Languages for Desktop Apps

Domain specific languages have been popular for some time now, but for how long they’ve been popular is a fuzzy question, with an equally fuzzy answer. There’s considerable debate over what a DSL really is, and when a language crosses the line and stops being targeted towards a niche and starts being general.

The most broad definition of a DSL is a language designed to solve problems in a given problem domain. This is in contrast to a general programming language (such as C, or Python), which is designed to be applicable to all problem domains. The problem of defining a DSL appears when you need to define the boundaries of your problem domain: XSLT was initially designed to modify XML graphs, but over time its problem domain extended into string manipulation, filesystem interaction, and other areas.

This being said, a DSL is characterised by a few core elements:

• Solving a problem in the DSL’s problem domain is easier and simpler than using a general purpose language.
• DSLs are often less comprehensive than a general purpose language.
• DSLs are typically designed for use within a larger system.

Sometimes a general purpose language can become a DSL. Lua’s loose syntax and simple data structures (it only has one, the table) allow it to be used as a generic configuration file format, which can be read quickly and with little computational or programmer effort. The paper that introduced Lua showed examples of it being used as a DSL that defines GUIs, as well as configuration files for math programs.

Another interesting example is Ruby, which features an even looser syntax than Lua, but more complex data structures. A popular, simple example are the attribute functions, which define accessors for class variables. A class need only define somewhere in its body:

attr_reader :some_variable

And that class now has setters and getters for ‘some_variable.’ More complex examples are present in Ruby on Rails, in which entire data models are constructed through similar syntactic patterns.

What if we looked at the Mac desktop as a problem domain? It makes sense, when you think about it. While there are an infinite number of tasks that users can do with their computer, there is a finite number of tasks that users often do: checking mail, browsing the web, writing, communicating, and so on. These tasks can be decomposed into task primitives; for example, a simple RSS reader performs three things: it downloads a file, parses it, and presents it as a list in a window. A web browser is more complex, but can be reduced to the primitives of downloading a web page, displaying it, and allowing the users to select what to view next.

Could a DSL be written that allows users to express these tasks and recombine them, with the versatility and ease of use that DSLs offer? Over the next couple of weeks, I will be looking at how we can do just that, and how it’s leading up to the next great revolution in how human beings get things done on their computers.

Further reading:

• Creating DSLs with Ruby
• Lua - an extensible extension language

Welcome to the new home of the Secret Lab! Here we will dazzle you with displays of our incredible wit and charm as well as show off whatever we happen to be working on.

To start off with, you may marvel at the brilliant design of our site and take a moment to reflect on how you couldn’t have done it better if you’d done it yourself. For your grandmother. You’d like to do a good job for your grandmother. You’re a good grandchild.

Anyway, welcome to the site. We’ll be visiting Apple’s WWDC08 this week so there will be many amusing and incredible stories, NDA not withstanding…

Onward!