Mechanical

Swiss Army Chainsaws

Perl has been described repeatedly as "a Swiss Army Chainsaw" because of how incredibly flexible it is (hell, I built a predicate logic engine using regexes. It really is flexible). Unfortunately, some people want to extend that "general purpose nature" to special purpose code. As a result, we get "frameworks". Frameworks are nice, but only when they're nice. When they're not nice, developers have a nasty habit of figuring out more and more ways of making them nice. And nicer. And adding more blades and engines onto every nook and cranny of that chainsaw until eventually you just know it could do everything you need, if only you could wade through the manual -- assuming there is one.

I hate that. I really, really hate that. Here's what I want:

Solve the 80% of the problems with the 20% of the code and then figure out how to expose just enough to the programmer to let him or her solve the rest they way they need to. If they need to.

Case in point: in trying to resolve a particular issue at work, I needed to understand the inheritance hierarchy of some code which uses DBIx::Class, an object-relational mapper written in Perl. It's a fantastic tool. It's a great tool. It's a Swiss Army Chainsaw of ORMs.

Uh oh.

We have a "clip" table. With the exception of two fields which should be managed by the database (but aren't -- they're handled by the 'AuditedObject' class you'll see below), we really only need to save 6 pieces of data in this table. Got that? One table with six columns. Here's the class hierarchy:

(Click on the image (and then click again) to see the inheritance heirarchy in all of its glory)


Bad, bad, bad inheritance hierarchy
Bad, bad, bad inheritance hierarchy
Absolute Nightmare of An Inheritance Hierarchy



Yeah, there are some problems in our code, but once you get into the DBIx layer, it's a twisty-little maze of passages. Good luck debugging that.
There are days that I'm envious of you, since you get to work in Perl for a living.

Today is not one of those days.
gosh. and people wonder why i've been playing with non-relational databases lately.

sanity is not actually overrated.

considering that i specialize in data warehousing, fully relational databases are definitely not where i want to be anyways.


No, even though you may not know it (it's not well known, so it's not your fault), you still want a relational database. What you don't want with your warehouse is data normalization. Not the same thing :)

Update: Just to be clear, you do want data normalization (with view overlays), but our current technologies generally aren't fast enough to support this for data warehouses.

Edited at 2009-01-30 10:05 pm (UTC)
correct. i do *want* normalization, but given that i tend to have to flatten even a snowflake schema down to a star on a regular basis, it's just got going to happen any time soon.

besides, these days it's faster to have a non-relational parallel system and simply map/reduce.
Though I have to say I recently moved to DBIx::Class, and am really loving it.