TITLE: "Does Not Play Well With Others"
AUTHOR: Eugene Wallingford
DATE: March 31, 2010 3:22 PM
DESC:
-----
BODY:
Today I ran across a recent article by Brian Hayes on
his
home-baked graphics.
Readers compliment him all the time on the great graphics
in his articles. How does he do it? they ask. The real
answer is that he cares what they look like and puts a
lot of time into them. But they want to know what tools
he uses. The answer to that question is simple: He
writes code!
His graphics code of choice is PostScript. But, while
PostScript is a full-featured postfix programming language,
it isn't the sort of language that many people want to
write general-purpose code in. So Hayes took the next
natural step for a programmer and built his own language
processor:
... I therefore adopted the modus operandi of writing
a program in my language of choice (usually some flavor
of Lisp) and having that program write a PostScript
program as its output. After doing this on an ad hoc
basis a few times, it became clear that I should abstract
out all the graphics-generating routines into a separate
module. The result was a program I named lips
(for Lisp-to-PostScript).
Most of what lips does is trivial syntactic
translation, converting the parenthesized prefix notation
of Lisp to the bracketless postfix of PostScript. Thus
when I write (lineto x y) in Lisp, it comes out
x y lineto in PostScript. The lips
routines also take care of chores such as opening and
closing files and writing the header and trailer lines
required of a well-formed PostScript program.
Programmers write code to solve problems. More often
than many people, including CS students, realize,
programmers write a language processor or even create
a little language of their own to make solving the
more convenient. We have been covering the idea of
syntactic abstractions in my programming languages
course for the last few weeks, and Hayes offers us
a wonderful example.
Hayes describes his process and programs in some detail,
both lips and his homegrown plotting program
plot. Still, he acknowledges that the world
has changed since the 1980s. Nowadays, we have more
and better graphics standards and more and better tools
available to the ordinary programmer -- many for free.
All of which raises the question of why I bother to roll
my own. I'll never keep up -- or even catch up -- with
the efforts of major software companies or the huge
community of open-source developers. In my own program,
if I want something new -- treemaps? vector fields? the
third dimension? -- nobody is going to code it for me.
And, conversely, anything useful I might come up with
will never benefit anyone but me.
Why, indeed? In my mind, it's enough simply to
want to
roll my own.
But I also live in the real world, where time is a scarce
resource and the list of things I want to do grows
seemingly unchecked by any natural force. Why then?
Hayes answers that question in a way that most every
programmer I know will understand:
The trouble is, every time I try working with an external
graphics package, I run into a terrible impedance mismatch
that gives me a headache. Getting what I want out of
other people's code turns out to be more work than writing
my own. No doubt this reveals a character flaw: Does not
play well with others.
That phrase stood me up in my seat when I read it. Does
not play well with others. Yep,
that's me.
Still again, Hayes recognizes that something will have to
give:
In any case, the time for change is coming. My way of
working is woefully out of date and out of fashion.
I don't doubt that Hayes will make a change. Programmers
eventually get the itch even with their homebrew code.
As technology shifts and the world changes, so do our
needs. I suspect, though, that his answer will not be
to start using someone else's tools. He is going to end
up modifying his existing code, or writing new programs
all together. After all, he is a programmer.
-----