I try to follow the writer's rule: "write for your expected audience"; and you seem to have a more sophisticated expected audience than I do. In my case, most of the programmers in my workplace who will be asked to maintain my code just aren't very experienced with perl. If they can't understand it, they'll just come back and ask me; I'll end up maintaining it myself. By using simpler constructs, I improve the odds that someone besides me will be able to maintain the code.

Letting aside that closures are not necessarily coderefs (who told you that?) and that a coderef needs not necessarily be stored in a variable,

Argh... but in some sense, you're making my point for me. How on earth can I try to teach people who barely speak English how closures work if a native speaker with a university education (me) who reads the man pages constantly can't understand all the nuances? It's not like the man page was very clear on the topic, either. Better not to use something than to abuse it, in my opinion.

if so, then -especially if variables are given sensible names, which is what one should do in any case- it shouldn't be more difficult to find the actual code than with a "regular" sub. How would it be less difficult? There's a deeper burder of proof involved for each call. If I see "foo()", I know that the function foo is called. If I see &$coderef, and I believe $coderef contains a reference to the function foo, I still to find out for sure if that's true; it's one more step for me to investigate. Additionally, since Perl lets me change the definition of foo() at runtime, I have to verify that that hasn't happened. If perl didn't allow me the "freedom" to redefine the codebase at runtime, I wouldn't have to check for someone doing that. The more loose ends rattling around, the greater the odds one will go flying and hit someone. :-)

More features means more degrees of freedom, and thus an enlarged phase space. This also means that there are corners of it that yield more obfuscation and there are corners of it yielding more clarity. It's up to the programmer to decide where to place his code...

But because of the way language elements interact, for every choice that leads to enhanced clarity, you've got many, many other choices that lead to obfuscation. The odds favour code becoming incomprehensible unless the programmer is very careful. You seem to assume all programmers are experts, and follow your notion of good programming practice; this is most decidedly not the case. Most programmers are bad; some are medicore; a few are good. Why not optimize for the common case?

PS: since you "sign" your posts anyway, you're a named anonymonk, thus somewhat a fake one: why don't you register instead? I did, a long time ago -- my registered handle is "Ytrew". But I don't have my password at work, and besides, if I gain 5 more XP, my title will change: and I like being called a "monk". :-)

--
Ytrew

I try to follow the writer's rule: "write for your expected audience"; and you seem to have a more sophisticated expected audience than I do. In my case, most of the programmers in my workplace who will be asked to maintain my code just aren't very experienced with perl. If they can't understand it, they'll just come back and ask me; I'll end up maintaining it myself. By using simpler constructs, I improve the odds that someone besides me will be able to maintain the code.

Maybe spend some of your time bringing your co-workers up to speed? I usually find teaching stuff a more effective use of my time than coding to the lowest common denominator or turning myself into a bottleneck.

Maybe spend some of your time bringing your co-workers up to speed? I usually find teaching stuff a more effective use of my time than coding to the lowest common denominator or turning myself into a bottleneck.

Your point is a good one; and if I were in charge of the department, that's what I'd do. On the other hand, I'm not.

1) I'm not a manager; I don't get to decide how to spend my time. Projects get given to me and I do the best I can with them. Training is not really part of my job description; so I'd have to do training for free after hours. I don't mind teaching, but doing it for free after a long day's work, knowing it will benefit my employer more than it will me, doesn't seem all that fair to me.

2) Many of my co-workers don't speak English as a first language; discussing technical concepts is more difficult because of a language barrier. Essentially, at times I end up teaching two languages at once (English+Perl); so progress is frustratingly slow, and, like I said, it's not something I'm supposed to spend much time on.

3) I just don't find it that hard to write simpler code; part of what I was railing at was an ex-coworker using an incredibly obfuscated micro-language solution (with ties, coderefs, objects, evals -- the whole kitchen sink) where a simple SQL query would have sufficed. I find that if I write in a simple, consistant style, I don't have to worry about the alternative ways of "phrasing" something; there's the simple, straightforward encoding, and then there's "something else". If I have to think about something else, odds are I need to think about how to encapsulate the problem better. Nothing I work with is very hard.

Perhaps if I were an engineer working with differential equations, or a statistician analysing stock market trends, or an AI researcher, I'd need some of those exotic features in Perl. But I just don't need that much complexity to automate FTP downloads, or convert file formats, or do simple financial calculations, or to implement other simple business logic. I get no benefit from @INC codrefs, or other wacky perl features. I just have to make sure they're not being used against me. :-(

-
Ytrew