 |
 |
>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