Every 26.4 days, someone laments in public that there are just too damn many templating modules on CPAN. (The frequency may have increased since the last time I made up^W^Wcalculated that statistic a few years ago.)
This week at YAPC, Damian demonstrated a quick hack he cooked up called makeslides. What does it do? Pretty much the same thing every one else's makeslides program does: convert a text file into a presentation of some sort: HTML, Keynote, PowerPoint, Magicpoint, TeX, PDF or otherwise.
Why is it that there are some areas in Perl where everyone cooks up their own solution, or hacks their own customizations onto someone else's highly customized (but unextensible) solution? It's almost as if you can't call yourself a Perl programmer until you've written either (a) a templating system or (b) a slide generator at some point in your Perl programming career.
Don't forget an email-address parser.
Now I just need to write a slideshow-er...
That's why I wrote my own web server.
Re:One More
inkdroid on 2003-06-20T16:32:38
Yeah, I've noticed this one too. I can understand having a Class to create the DBI handle (no need to remember pwords, usernames, etc), but it seems that everywhere I've worked people want to replace DBI's methods with their own (which simply wrap the basic ones). DBI has everything I've ever wanted to do with a database, and then some. Using DBI makes it easier for new people to come in and know exactly what's going on, without having to understand someone else's idea of what database access *should* be.Re:One More
schwern on 2003-06-26T19:09:36
After you've written your 39823th slight variation on the basic SELECT, INSERT and UPDATE statements, it gets a little tiresome.Re:One More
barbie on 2003-06-30T17:32:29
There can be good reasons for it.The wrapper that I continually reuse, implements a keyword lookup into a Class::Phrasebook XML file. This has meant I have been able to move from MySQL to MS SQL Server 7, by only changing the XML file. Plus my wrapper creates the DBI object for you, but only if you require it. I have seen several implementations of CGI scripts that create a connection, even when the request never uses it.
Although Class::DBI may be growing in popularity it doesn't suit all purposes, and sometimes writing a wrapper (hopefully a simple one to understand) is better than recreating all code to access the DBI calls.
If I've misunderstood and you are talking about people rewriting DBI.pm in their own fashion
... then please forgive me. They must be complete mad!
Re:another rite of passage...
jdavidb on 2003-06-26T18:18:48
Did that.
:) And Randall did it a long time ago in one of his columns, but back then it was retrieving Dilbert from usenet, I think.
Others do it simply because their idea of the concept can be quite limited and they want to understand better either the language or the methodogy behind what they are doing.
There are also the people who have a different take on a particular problem and feel they can do it better. Templating systems are a good example here. If Andy hadn't been inspired enough to write another templating system, Template Toolkit would never have seen the light of day. There were plenty around at the time, why write another? Because he had another way of looking at the problem.
If only one app was ever allowed to be written to perform a particular task, I doubt Larry would have been given the go ahead to write yet another programming language.
So I'd written up a big detailed hypothesis about why database object abstraction layers (Class::DBI, Tangram, Alzabo... stuff on top of DBI) keep getting reimplemented because they share a lot of the same attributes and I know something of the POOP (Perl Object-Oriented Persistence) world, being guilty of reinventing that wheel myself with some success. Unfortunately, in a fit of false laziness, I wrote that on my Win98 machine (its only for games, I swear) and it crashed after writing it.
Reason #19388 why I hate web-based applications: No autosave for textarea boxes.
Anyhow, since I'm not going to write all that again, here's the gist. Essentially, both POOP and templating modules have a very deep, very wide scope that touches almost every part of a system's design. Unlike most modules, which are essentially just a collection of functions and their effect on your program is limited to the area around the point of call, the design philosophies in POOP and templating modules can effect the entire structure of your program. Since they are so pervasive, they can also be a major effect on performance, causing people to avoid an existing module because its too slow. Finally, the problem is superficially simple, anyone can write a very basic tempating or POOP module, but the details are horribly complex to get right. So everyone figures they can knock off a new templating module that does "just what they need" in a few hours.
Here's some specifics to POOP modules.
So that's POOP modules. Analogies can be drawn to templating systems, they share the wide scope, the idiomatic designs (especially WRT templating language design) and pervasive design choices. Wide, deep design choices can often turn someone off from an otherwise wonderful templating modules. For example, I hate XML. AxKit is all about XML. So I don't use AxKit. Text::Template requires/allows web designers to write Perl, often unacceptable and even dangerous.
Also, by far the most defining charateristic of a templating module is the templating syntax. And Perl programmers love their syntax! So of course they're going to keep reimplementing their own mini-languages that suit their own needs. I think if someone invented a really solid templating module which allowed language plug-ins, they might have a category killer.
That's how I see it.
