in reply to Perl Elitist Code vs Functional Code
-
So is the functional coder worse then the elitist?
The answer is 42... problem is you're not asking the right question.
Let's set aside language for a moment. I've been programming in one language or another since 1972. Over that time period I've seen some really nifty code and I've seen butt ugly code. The difference in the two very little to do with the techniques used. I've seen functional coding that was elegant and I've seen OO code that was butt ugly. I've seen elegant OO code and I've seen code that looked like an obfu competition entry. Worst part of that is I've inherited my share of the butt ugly code to maintain.
To me the difference between good code and bad code is readability and maintainability. I should be able to look at a piece of code and understand to some extent what is going on right away. I haven't much hair left and I get upset when I end up pulling more our trying to figure out what a piece of code does.
As to your example of the "Elitist Code" let me say this. If some authoritative body for the environment in question or local culture dictates that your code should only work on 5.12 then I'd be asking the question of why? Usually there's a good reason and on some rare occasions I've been exposed the answer has been "because it's always been that way." If there's go good solid technical reason for the standards than suck it up and work within those parameters. If not then you may have an opportunity to change things for the better if you can keep your temper in check and provide good solid technical and/or business reasons for your proposals. Been there done that and it was a rewarding experience for me to influence change for the better.
I am the right kind of lazy. (At least I'd like to think so) I use a lot of OO programming in both Perl and C++ when I write code. My reasoning has always been that I hate writing the same code over and over again. I'll give a for instance.
I was once presented with a requirement to write some code to glean records from network equipment logs and look for patterns in the entries to detect malicious behavior. There were several flavors of that malicious behavior out there so I broke the job into several modules that made up the work.
- Log reading and parsign
- Pattern detection
- Report Writing
- Report archiving
- Report delivery
use strict; use ABC::NE::Logparser; use ABC::Traffic::Patterns; use ABC::Report; my @recipts=( 'user1@abc.corp','user2@abc.corp','user3@abc.corp'); my $lp = new ABC::NE::Logparser; my $records = $lp->get_all('2011-01-01','2011-01-15'); my $matcher = new ABC::Traffic::Patterns('pattern1'); my $matches = $matcher -> find_candidates($records); my $rpt = new ABC::Report(); $rpt->generate($matches); $rpt->save(); $rpt->send (@recipts);
If I had pursued the functional approach my code wouldn't look that clean for one thing, adding new functionality is a bit tougher (maybe not a lot) and someone who needs to look at my code has less to look at in one chunk than having to look at an entire script with lots of subs.
Summing up my thoughts on this:
- Code standards are a necessary evil for code that more than one person is going to be looking at.
- Code standards
areshould be driven by business need, best practices and technical merit. - Code standards should not be developed in a vaccum
- Write code with the thought in mind that someone else is going to read that code some day.
There's a postscript to this posting: It is timely that the post I'm commenting on showed up on PM. The above mentioned "framework" for a lack of better term was inherited by some folks I've never even met. Since my personal email address was listed in the comments for the modules and scripts that I wrote they sent me an email to tell me that they were still using my code and had added several more types of pattern matching logic to what I had written. That code was written in 2001.
Peter L. Berghold -- Unix Professional
Peter -at- Berghold -dot- Net; AOL IM redcowdawg Yahoo IM: blue_cowdawg
|
---|