Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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.

    • Effects class and object structure. POOP modules essentially take over how classes and objects are implemented. Everybody has their own idiomatic way they want to write objects in Perl, therefore their ideas about how objects are implemented might not mesh with the POOP author's design.
    • Reimplementing a language. POOP modules must eventually do just about everything SQL can do. And do it portably. And smarter. That's a lot to ask for. Most succeed, so somebody tries again.
    • Performance critical. Somebody's always going to want to ram 10,000 queries a second through your POOP system and have it run just as fast as a straight DBI prepare/execute/fetch loop. The more flexible a POOP module, the slower it is (in general) so somebody that needs high performance over features is going to reimplement a thinner, less flexible but faster version. Of course, soon they need more features...
    • Portability. Let's face it, SQL isn't very standard. Its really, really, really hard and time consuming to generate portable SQL. Most POOP modules don't bother and just cover whatever databases they care about (usually MySQL and one or two more). Somebody's going to need to be more portable than that, so they have to write their own.
    • Flexiblity. Because POOP modules have to do so much, somebody's always going to want to do it differently. Or make it do something more. Or make it go faster. So they have to be flexible. But flexibility takes time, thought, effort and often cuts into performance. Often, a POOP module just isn't flexible enough for what someone wants, or adding their new feature is too convoluted or too slow using the existing architecture. Or the POOP module isn't well thought out, being an overgrown "I'll implement what I need in a few hours" module. So, you've got to write your own more flexible version (which might wind up being too slow for others).
    • Doesn't fit your table design. Some POOP modules have strong ideas about how RDBMs should be layed out and only fit certain database designs (guilty). Others want to be able to set up the system from scratch. Still others want to be able to add their own administrative tables and columns. These constraints might not jive with what a user needs, so they write their own.
    • Inadequate docs. Since the scope of a POOP module is so large, they often have inadequate docs for the task. Often they're missing a simple "get me started" guide and the user is overwhelmed with that simple task of just setting up a basic table abstraction. This is primarily why I wrote Class::DBI, the existing solutions just bowled me over.
    • Complex dependencies. Many POOP modules have a very large number of module dependencies (guilty) which would make one blanch away from having their application depend on it. Someone reinventing the wheel would write their own which has fewer dependencies.
    • Complex installation. Similarly, if the POOP module is difficult to install, you dont' want to depend on it. If it asks a lot of questions, requires databases to be set up in a certain way, doesn't install nicely from the CPAN shell, is overly large, etc...

    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.