>I loved programming when I was first exposed to it.  I would make games
>for my friends, of course. :D
>
Ted Nelson and Don Norman have speculated that games represent the height
of programming prowess because it is one of the few areas in technology
where the creators actively use their creations. I have always been
fascinated by the relationship between gaming and coding, and once worked
on a game called StackQuest with my oldest son (as a side note, if you ever
want to test the bounds of your technical and communication skills, work on
a program with one of your children). The idea was that you were chased
around library stacks by a set of monsters and you had to find certain
books to throw at them to make them disappear. I had done some mapping with
VRML at the time and it seemed to be a way to get some milage from it all.

But, of course, gamers have high expectations, and at the time, the
technology just wasn't robust enough to satisfy my audience. I also have
worked with all three of my kids on mindstorms lego projects, and I have
always been amazed by how much effort you are willing to put into
activities that seem "fun". Programming can be both rewarding and tedious,
I always think that we have such an advantage in the library world because
we can see the results of our efforts fairly directly. I graduated with a
Computer Science degree in 1985 (Modula-2 was going to rule the earth at
that point, and LISP was the next big thing), and I knew a lot of people
that ended up babysitting large systems at companies. There have been days
I have felt that way with many of the ILS options I have interacted with
over the years, but I generally think that it is much more fun to be
programming in a library context because the problem sets are often so much
more interesting than in other organizations.

Still, I have been fascinated by the Apache Foundation notion of
XML-directed solutions for some time now, where a large part of building an
application is not procedural code, but knitting together XML-based
components with stylesheets. I have grown pretty convinced that procedural
programmers are the worst stylesheet writers on earth, or at least I am a
testimony to this assertion, but it could empower people who would not
normally be keen on putting together a program to fix an application or
solve a problem, and this is a very good thing IMHO.

Of course, you need the components to be there in order to plug them into a
solution, and these have to be programmed in a somewhat traditional manner
(with Perl in AxKit, Java in Cocoon, and somewhat awkward combinations of
others if either of those two languages offend). Eric Raymond once said
that part of the genius of Linus Torvalds is his laziness, and his ability
to recognize the value of the BSD tools rather than building it all from
scratch. In all this, I wonder if Eric (Lease Morgan)'s original question
about when to code or not to code requires some metric that speaks both to
whether the task can be done with existing tools, and whether the resulting
creation has an high probability of fitting into other applications. But I
know there's always going to be times when cooking up a script is going to
be the most potent solution possible, so even in my most "XML as the glue
for future applications" moments, I have little expectation that I am going
to be tossing out my O'Reilly Python/Perl/whatever books anytime soon.

art