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

use Perl Log In

Log In

[ Create a new account ]

gav (2710)

  (email not shown publicly)
AOL IM: flufflegavin (Add Buddy, Send Message)

Hacker in NYC.

Journal of gav (2710)

Friday July 26, 2002
09:36 PM

baby talk

[ #6678 ]
I am a busy person at work. This is good. If I wasn't busy I wouldn't be getting paid. However this does come at a price, I don't have a huge amount of time to play with things to see if they can be used in future projects.

I try to sneak a bit of this playing into the beginning of each project. A couple of hours investigating some module that seems interesting to see if I can put it to good use. I was thinking about this today in relation to perl frameworks and the like. If I can't grasp the basics in an hour then sorry, it doesn't matter how cool everyone says your tool is, I won't use it. I just don't have the time and have to get things done, my clients don't care what I use as long as it is under budget, on time, and seemingly bug free.

One of the advantages of perl is that it allows you to write in "baby talk". This is a good thing, it lets you be productive from day 1. I don't care that I might not be using it i quite the best way, I tend to refactor as I go along (and client requirements change) so the first attempt is probably thrown away. HTML::Template is a good example of a module that lets you do great stuff 5 mins after you install it. I takes a bit longer to work out better ways of doing things with it, but hey, using it badly is better than the alternatives.

I made the switch recently from HTML::Template to the Template Toolkit because I thought that it would make implementing some parts of a recent project easier (and it did). TT has a great tutorial and after 5 mins or so I was spitting out some working templates. This is a good example of something that is powerful, yet you can use it in a simple way.

I don't really like mixing SQL and perl. I think it is messy. DBI is great and I couldn't work without it, but I thought it was a time to look into some other things. Alzabo looked promising. The problem was that it is has over a dozen modules and looks pretty scary. I then looked at Class::DBI. This looks a lot more managable, it is only one module and it has a simple code example at the top of the docs that I was able to take and write a test script by just changing the names. I ended up using Class::DBI. I'm not saying that Alzabo isn't good, it's just that it may be too good and powerful for my little brain to comprehend.

Two other examples of this "too big" problem are openinteract and AxKit. Openinteract seems like a good thing but it looks like I can't use just parts of it, I have to go the whole thing. Even the example program looks scary. Installing it looks even scarier and I doubt that in a hour I can have it installed and some code written that uses it (my acid test). My problems with AxKit run along the same lines.

I'm not really sure what the solution is. Is it just me? :)

p.s. I want to make it clear that I'm not knocking anybody's work. People who release code to the masses do great work as far as I'm concerned. I just wanted to give a user's view.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • The problem most people have with OpenInteract (I can't speak for AxKit) is that they have a specific problem in mind, and that problem might not best be solved with this tool. OI is a fairly heavyweight (for Perl) application server. It has authentication, security, object persistence and a number of other things all bundled up in a relatively coherent manner. This doesn't make it any more or less valid that a more lightweight solution, just different.

    I guess my point is: if you have a complex problem to solve, then you need to invest some time into investigating the solutions. The more complex the problem, the more time. TT focuses on a small piece of this and does a great job at it. But that also makes it easier to get started, particularly when the templating paradigm is already ingrained in all Perl programmers' brains, since they themselves have almost certainly written their own templating system at some point :-)

    That said, I am acutely aware how powerful the 'get it up and running quickly' effect is. The installation for OI is a bit hairy (for now), but that's all behind the scenes. Up front I think it's actually pretty clean for all the work that it does. I am not the average case, but I can get an install -- from creating a database to installing the software, creating a site and getting it started -- up and running in 10 minutes. That's pretty good.

    But you might be happy with some other frameworks that don't attempt to integrate quite so much. OpenFrame is one, Mason is another -- particularly since it's got a new book out soon! For the object persistence stuff, there's always a summary and comparison page []. I don't know if anything similar exists for application frameworks...