Hi everyone
We all know that a good picture is worth a thousand words, but what we'd just as soon forget is that making a good one programmatically requires tweaking at least that many knobs and dials of various drawing objects to have them render just so. It never seems very complicated when sitting in front of a WYSIWYG editor like Inkscape or Visio, but writing a program to generate the same drawing sure is. Clearly, there's something far more intuitive about the application controls--something which better approximates our thoughts--than when we're forced to linearize our thinking into code. Your mileage may vary, but any sufficiently complex rendering layout I've undertaken seems to reflect the visual essence in no more than one quarter of the program. Another quarter is a hunk of boiler-plate to initialize various graphics objects, like colors, gradients, or a graphics context (whatever that means). And, worst of all, the last half is a slew of semi-ad-hoc algebraic calculations needed to bridge the chasm between my intentions for the visualization at hand, and that drawing tool's available primitives. I'm talking about things like: "for the center to sit there, where would the upper-left go?" Or, my personal favorite, "how big should this shape be to hold that text caption, and yet not be too much bigger or smaller than the ones nearby, each with their own caption?"

If visualizations weren't so compelling, I just wouldn't bother. But the high-bandwidth channel of our eyes is too rich to squander. A pair of beautiful 'little languages' are exceptional attempts to solve this 'death by a thousand calculations'. They are: pic(1) by Brian Kernighan, and (Graphviz) dot by Emden Gansner and Stephen North. Both know largely how to Do The Right Thing. Even so, since neither is a full-featured programming language, each projects unfortunate limitations on one's ability to both tweak The Right Thing to be correct in a slightly different way, or to package solutions for later reuse. In the end, I've addressed the latter by resorting to generating the little language (as text) from modules written in a high-level language. It's about as fun as it sounds, though fortunately the resulting drawings look a lot prettier than that code.

In the hacker spirit of "scratching my own itch", I've created 'Tie', a Scala graphics package for generating technical drawings programmatically. It consciously embodies the spirit of PIC and DOT, rather than, say, the Java AWT. Its functional approach of building larger drawings by composing and transforming smaller ones is also loosely inspired by Paul Hudak's inimitable tutorial, "The Haskell School of Expression".

Like PIC and DOT, Tie is also a programming language, one which is hosted within Scala. This means that it is not another 'little language', but a strongly-typed modern object-oriented language with first-class functions, anonymous classes, type inference, extensible pattern matching, and a collections library which encourages one to program in aggregates. So, whether you have data to visualize, a network to monitor, or a system architecture to model; any time you need to parametrize a part of your drawing, you could accept a function or perhaps a user-defined class instance as a value; just as any functionality you want to leverage later, could be defined as a mixin or a derived class--even a curry-able function. Naturally, laying out a nice drawing still requires a little geometry, but, thanks to these facilities for abstraction and modularization, most of the basics have been swept out of sight into the library, which, like the Scala Standard Library, has been written in user-space, and so may be reimplemented if the need arises. With the right abstraction then, the intent behind the visual layout actually becomes a separable concern from the mathematics to effect that layout.

While illustrations in Tie are format-agnostic, renderers exist for both SVG documents and PNG images. At present, roughly 90% of the non-animation portions of the SVG 1.1, 2nd Ed. specification (of June 2010) is supported. One may draw common geometric shapes, render images, write text, or formulate arbitrary paths by composing lines, arcs, and bezier curves. Then, transforming shapes by scaling, rotation, reflection, and more is made deceptively simple, for its power. Finally, beyond basic coloring, Tie has support for linear and radial gradients, repetitive tiling of patterns, and clipping and/or masking of one shape by another, all with precise opacity control. Essentially, with the notable exception of filter effects--which are on the way--if you can show it in SVG, you can write a program to render it for you with Tie.

The best thing, however--what makes it even cooler than SVG, which already expresses these kinds of drawings--is Tie's rich offering of state-of-the-art modularity constructs. From deep support for blending the best of functional and object-oriented programming, to the ability to build one language on top of another, Tie rocks because of its Scalatude!

Not surprisingly, there's a quite a bit to the project, and a lot of ideas and code to discuss. I'll begin with an overview of the language's domain model, and then move into how the constructs are expressed in actual code. In a few instances, I'll call out some of the Scala features and idioms which either made implementation exceptionally simple, or perhaps resulted in a more powerful interface than would have been possible under Java. Those last pieces would cater more toward the Intermediate Scala Programmer, but the talk should be well-understood by those who know little more than basic Scala syntax. Since drawing pictures offers such immediate gratification, perhaps playing around with Tie would a good vehicle for some fence-sitters to finally dig in and write more Scala. Throughout, there will naturally be a number of drawings for those, who merely want to drink beer and look at pretty pictures.

At the moment, Tie is under quite active development, to the degree that I need another day or two to finish testing some of the features I've crammed in during the run up to this initial public release. I'll get the bits up Thursday or Friday, so those, who would like a chance to play beforehand, may take an early look. Once I've done so, I'll send out a follow up announcement to the group. Bring your feedback--hope to see you there!