Re^3: OO in Perl 5: still inadequate

The number of bugs is linear with the amount of code. Powerful constructs that reduce the amount of code you need to write therefore reduce the number of bugs in your code. And shuffle it inside the constructs themselves, which are harder to debug, since they're powerful and complicated. You still don't win; you end up maintaining ugly libraries full of someone else's notion of "cool" or "powerful" constructs, and now the userspace problem has been halfway abstracted into a less-comprehensible language, in a half-tested toolkit.

I've been down that road. I don't like it. It's made me suspicious of the whole "powerful code is good code", because usually someone's idea of "power" really is "ugly, complicated code that tries for too much at once". Sometimes it's not, and those people do good work; but it's the exception, not the rule.

Powerful features can be wrapped in nice generalised packages for everyday use. There’s a difference between being Damian and being a user of Damian’s modules.

Not really -- if you end up having to debug one of Damian's modules to fix some obscure bug in the middle of the night, you still have to know what the hell he did and how he did it. And then you'll probably wish he was less clever and used fewer obscure tricks, so that you could see the bug and FIX it, and go HOME, instead of fretting over how the classes and the closures and self-rewriting language constructs are conflicting in some wierd and unpredicted way.

If you gamble on complex, powerful code you'ld better be sure you get it right the first time, because maintanance sure is a nightmare when the call to do_deep_magic() fails.

And as the guy who has to fix stuff, I get grumbly when it's me that has to fix it. I don't like beautiful and elegant code. Sure, maybe you're a genius with knots, and you can make a sailor jealous with your bowlines. And maybe you think it's a conceptualy elegant and powerful notion to solve the problem of cable management with the cables themselves. But to me, it's still a mistake to make your network cables look like a some elaborate piece of celtic knotwork that's an absolute pain to untangle at 3:00 am when the same job can be accomplished in an inelegant, ugly, but obvious way using cable ties and conduits that can be fixed on a moment's notice late at night.

I've seen so many "code as art" projects that were an abject nightmare to deal with not to scream internally every time someone starts chuffing their chest, and touting words like "elegance", or "powerful constructs", or "higher order" anything.

Maybe I'm just a grump. But I've seen a lot of stuff like that, and I keep having to clean up after young, bright eyed kids who think they know what they're doing, but can't quite nail it -- they bustle in on contract, fire buzzwords around, generate a lot of cute, complicated code, get bored, leave before they can be fired ( or get fired), and leave me to clean up the mess.

That's no fun.

Comment on Re^3: OO in Perl 5: still inadequate

Replies are listed 'Best First'.
Re^4: OO in Perl 5: still inadequate by Aristotle (Chancellor) on Jan 24, 2006 at 12:43 UTC
It’s a question of whether you want to spend 3 days writing something that you could have gotten done in an hour using a Damian module. Sometimes, having magic available makes the difference from “too much effort to implement at all.” And personally, I don’t take the notion of magic lightly. I rarely ever implement the first thing that comes to mind either (in this, I seem to be in a minority). I wouldn’t use Damian magic without a good reason for it. I wouldn’t use Ingy magic at all. I’d never use a source filter in production. And on and on. I know to discipline myself. I resent it deeply when the language assumes I don’t and puts itself over my judgement. Makeshifts last the longest.	[reply]
Re^5: OO in Perl 5: still inadequate by Anonymous Monk on Jan 24, 2006 at 15:55 UTC
I know to discipline myself. I resent it deeply when the language assumes I don’t and puts itself over my judgement. In your case, I believe you. That's not the common case, though. Most people who say they know how to discipline themselves just don't; and then other developers suffer for their failings. Self-discipline is hard. It's like the way 90% of drivers consider themselves "above average" -- they can't all be right, and only a few of them are really as good as they claim. A good programmer can work within a language to get whatever he needs done, one way or another. It's a question of limiting the amount of damage a bad developer can do (deliberately or by accident) that's hard.	[reply]