SpimeScript

These days, I’m thinking a lot about 3D printers, desktop manufacturing and software to create physical things.

Last year I did some art pieces using software to generate drawings for laser cutters and 3D printers, and I’m continuing along the same line. I want to move this stuff into the browser, and the combination of CoffeeScript and Raphael.js is turning out to be pretty good for this. (Did I mention I really, really like CoffeeScript?)

I also dabbled a bit with Prolog, wondering whether it can be used as a high-level description language for machines or other complex objects. The really interesting question is if you can use the built-in inference engine of Prolog to help with the design. (Aside, here’s a silicon layout engine in Prolog) I haven’t got very far with that yet, but I’m now considering how Prolog can be combined with or made to output OpenScad (or PyScad) code.

A couple of days ago Simon Wardley posted on his blog that he was searching for a SpimeScript :

So, I want to return to … the formation of Spime Script. We’re entering a phase where hardware will become increasingly as malleable as software which leads to a problem of choice – if I want to change the function of something, do I do this in software or hardware? The tendency today is obviously towards software because its more malleable but the future is never the past. However this creates a problem of skill – will I need to become proficient in both software and CAD / electronic design?

In reality both CAD and whatever software language you use, compile down to instruction sets and the function of the device is the interaction of these instruction sets – one which is substantiated physically and the other which is substantiated digitally.

Turning this on its head then why not write the function of what you want, the function of the device? Compilers can therefore undertake the complex decision trees (which is what they’re good at) required to determine what element of that function is encoded as physical and what element is digital.

A future language is needed, something whereby the output is both physical and digital and I describe merely the function of what I’m after.

That’s a really exciting vision.

Now, here’s what I think is really important for a SpimeScript.

It should learn from HTML / CSS.

While HTML / CSS is a pain in many ways, there’s a very interesting insight in it about design. That design comes in layers. It’s partly about the separation of logical structure and visual style. It’s partly about the cumulative effect of the Cascade in Cascading Style Sheets. It’s partly about the fact that the browser has reasonable defaults for the geometric properties of logical structure. (Today, those defaults look rather out-of-date but there would be little to stop a browser manufacturer making their defaults look more like Readability or Twitter Bootstrap.)

So here’s the main feature request for a SpimeScript. It should be possible to define the logical structure of, say, a machine and have some layout-engine give it plausible default geometric properties. But it should also be possible for designers to layer optional design hints on top of that layout in the form of extra constraints and have the engine deal with fitting them together.

As with the silicon design case, there must be some prior art here, but I’m not quite sure where it is. Electronic Design Automation maybe.