|P is for Practical|
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.
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:
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