Re: Perl Elitist Code vs Functional Code

[xyzzy]

Most of our esteemed Monastery Elite are taking the expected position that this so-called "Elitist" code, with it's mandatory OO design and dependence on modules to perform even simple tasks is better because it makes your code "clearer" and "easier to maintain".

The more attuned monks are adding that, while a 10-minute hack will always be better than an hour-long struggle when solving a single, specific problem, most of these small hacks will eventually grow into full-fledged packages and distributions, even if they were originally never designed to do more than that one small function.

I am curious as to the turning point at which one should abandon the hack in favor of a package. For example, to tie in the reference to the Unix shell vs. Perl post, I have a collection of tiny hardware monitoring shell scripts that run every second and output to the notification area of my window manager. Right now there are three "module" scripts, one "daemon" that is required by a "module", and one that runs each "module" and compiles/formats the output onto a single line. Most are 3-5 lines long, one is about 15 or so because it has to do a switch on the different battery states. I wrote the first version of these over a year ago when I first started using dwm, and recently rewrote them for my new netbook almost from scratch and with considerable improvements as I have learned more about bash scripting. Over the last year, I have thought many times, "Hmm... If I combine everything into a super-duper Perl script I can put everything into separate packages and use better logic and tie in CPAN modules and event handling and all sorts of other fun stuff. But-- if I try to make the move from thinking about to writing it, I end up worrying too much about scary OO concepts and being unsure about how to actually prototype everything I want to add without limiting my options. Also I'm a little worried about a tradeoff in resource use, although that shouldn't really be that much of a concern. I kinda lost my train of thought, but I guess the point is, even when you have an idea to expand a quick and simple hack, and when know exactly what kind of features you could get out of it, the sheer complexity of converting everything into OO is too much to overcome the inertia of having a perfectly working thing right now. Unless, of course, you're an OOP elitist who spends the first 30 minutes of every script writing 50 lines of package infrastructure. (Sadly?) I am not experienced enough to do this comfortably.

There is another important aspect to best practices--formatting and naming conventions, comments/documentation, stylistic things--and these I tend to disregard with such inconsistency that it's downright dangerous for anyone to look at my code if they are (not?) on mind-altering drugs. I never remember what I chose to name some random variable, I constantly mix awkwardly short control structures with my clear, fully-typed-out ones because I feel that it would save time and space on the screen, I don't think I have a single file longer than 50 lines that uses the same indentation or delimiter placement scheme throughout the whole file, and I usually only bother to comment when I know from the start I'm not going to finish something right away, or if I've already spent 20 minutes starting at something and don't want to figure it out a third time. This is probably much much worse than not using modules and such, and the Elitists will argue that writing code this way is not even "functional". I say it's functional if it works, and if I wrote it and it worked, then it's functional enough, until I have to go back and fuck with it some more. But I think the root of the problem is that Perl is positioned as this practical language with its quick-and-dirty one-liners and such, which makes it very attractive when you want to sit down and pump out a feature for something in 10 minutes. But then at the same time, it goes "No no no no, this is BAD PRACTICE, you really should treat it like one of those other languages, where everything should be verbose for the sake of clarity." And yeah, I suppose the latter is what all programming should be, regardless of language, and that's just something any code will have to deal with. Then this is really just a rant about how annoying it is to have to type the same thing all the time, because even if you claim that you don't rewrite your code, you do have to rewrite all those long method names, all those long object references, all that nice white space and other assorted "fluff", etc. Like, I've been working with Catalyst for way too long, and it's such a pain in the ass to constantly have to type out the same one or two-line snippets to handle routine things like reloading model data that was saved to the stash, or setting status/error messages (the "best practice" way is: $c->res->redirect($c->uri_for("/some/url/goes/here",{mid=>$c->set_error_msg('Oh noes, ANOTHER FUCKING ERROR!!!'}));$c->detach(); and that is with minimal whitespace). But it works. And it has big advantages over other "simpler" methods. So I grunt and I deal with it, but it certainly makes me laugh at the notion that Perl is, by its very nature, a terse language.

ok. rant over. OBLIGATORY IMAGE MACRO