Questions for 2014 : #4 Visual Design

Part 4 of a series of questions for 2014 …
4) Can I learn to be a visual designer?
My visual design isn’t good enough. It would be wonderful to find a designer I could work with. But I’ve never yet met someone who shared my tastes sufficiently. Either for me to want to recruit them, or for them to want to work with me.
I’ll be honest. I haven’t … er … respected … visual designers in the past the way that perhaps I should have done. But then again, perhaps I just have very strong opinions about how things should look.
So is it possible I could learn visual design? Well enough to make a decent job of some of the things I need to do? (Perhaps no more crazy than the thought that I could be a visual artist.)
Do I have the patience to try that?
Previous parts : #1, #2, #3 … next one soon.


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.

Here’s a question … why is Erlang so ugly?

I don’t mean that in a pejorative way (not much, anyway). I mean, I really love what it does. I’m totally impressed with Erlang’s power and simplicity. I’m writing simulations which are about a quarter of the size of the Python equivalent. So this is not to be taken as a criticism of Erlang which I’m definitely committing myself to, this year. Rather this is some random speculation about programming language aesthetics.

Erlang is wonderfully concise. And yet, somehow, unlike Python, unlike Haskell, it just doesn’t come across as beautiful. It’s confusing. It looks cluttered.

A couple of lines look fabulous. But the simplicity doesn’t scale.

At first guess, there seem to be three issues.

a) As people have noted, the record type is ugly. It is. And counter-intuitive to use in patterns (although I may just be stupid).

b) In general I think it’s good and brave thing to take a stance *against* objects. But I haven’t figured out how to do encapsulation (data-hiding, abstract types)

Sure, I can define polymorphic functions (one clause at a time per input type) which is a lot shorter and more powerful than overloaded methods in Java. But it has the effect of jumbling all my data-types together. Which just feels *wrong* to me. (Of course, maybe that’s some residual OOness in my thinking.)

But I think that may be part of the bigger issue :

c) erlang doesn’t seem to have resources for “programming in the large”. And, ironically, because erlang is so powerful, that problem becomes visible at a smaller scale – precisely because in erlang “large” programs are actually “small”.

Or rather, the only resource is “modules” (which means breaking up into multiple files – always an extra overhead.)

But if you avoid breaking things up into files, the opposite problem becomes apparent. I can do the equivalent of a small Java class (let’s say something around 50-80 lines) in about 6 to 10 lines of Erlang. But 10 lines of erlang is too small for a separate file. So I’ll add the next 10 line packet of functionality to the same file. By the time I’m up to 4 or 5 packets that would be handled as different classes in Java or Python I may have written only about 50 lines of code … but it’s all running together!

There’s no higher level of organization to distinguish and separate the code. In Python I often put 5 or 6 small-medium classes in a single file or around 300-500 lines. But the indentation and editor make these reasonably distinct and identifiable. In contrast, my equivalent 200 lines of Erlang have no visual cues to break them up. I can’t use functions as a visual element because pretty much every line is a new function (except when I’m doing I/O, which has its own “issues”).

I’m left with using comments but my editor (Komodo), excellent in many ways, doesn’t actually know Erlang and so doesn’t colour them differently. And, in general, because functions are powerful, they *are* short : one or two lines. But those lines are typically much denser than Python. Even if a dedicated editor would colourize them, I’m not convinced that’s such a big win at this density. On the other hand, I don’t want to artificially scatter them out into multiple lines. I’m not trying to recreate Python with a slightly less appropriate syntax. I want to take advantage of Erlang’s power and conciseness.

But I wonder what the right aesthetics for a language as high level, dense and abstract as Erlang is. Haskell looks cleaner to me – maybe because it does abstract data-types right. But can it solve the problem of organizing your larger-scale things? Lisp is no role-model. ML and its offspring have always repelled me visually. (Nothing can be more ugly, dispiriting and patronizing in a programming language than an explicit “begin” statement.)

Suggestions, anyone?