Re^5: defining methods on the fly

[ptum]

I don't think I'm qualified to judge this specific implementation, or to weigh in on a particular 'good programming practice'. I was reacting to what I perceived as your er, kneejerk reaction, in seeming to generally defend 'cool' Perl idiom.

I think you expressed your point of view well, when you indicated that resistance to a particular Perl idiom can be rooted in individual unwillingness to learn more Perl. But I think it is common for Perl developers to indulge their taste for the elegant at the expense of code clarity or maintainability, a natural pitfall of TIMTOWTDI. It may have been unfair for anonymonk to pick on the OP in this particular instance, but I don't think I am alone in wishing that some of the 'cute' idioms could be restrained so that those of us (I admit it freely) who haven't yet learned all of Perl could get on with our work.

I know I'm out of my depth in arguing with you, and I hope I'm not just trying to have the last word, but I feel a little like George Bailey in It's a Wonderful Life, when he says to Mr. Potter, "They may be 'rabble' to you, but this 'rabble' you sneer at does a lot of the living and working and dying in this town. Is it too much to ask that they do that living in two rooms and a bath?" (original quote badly paraphrased).

[chromatic]

I don't think I am alone in wishing that some of the 'cute' idioms could be restrained so that those of us (I admit it freely) who haven't yet learned all of Perl could get on with our work.

In what sense do they prevent you from doing your work?

If you have another developer on your team who persists in using idioms you don't understand, either ask for help learning the idiom and decide if it's worth using, or, as a team, decide not to use that idiom. (If you can't do either, your code maintenance problems have very little to do with technology.)

[ptum]

Hmmm. I think you caught me. What I really want is for you (in the generic sense) to dumb down your code so I can easily understand and adopt it and so that it doesn't take much time for me to use it to do my work. When you don't cooperate with my selfish goal but instead have fun with your own elegant approach, then I get peevish. After all, it isn't all about your ego, it is about my paycheck. :)

Either that, or I just got up too early and am cranky.

Update: Strange as it may seem, I'm not being sarcastic, here. I realized that my frustration was founded in the fact that, as BrowserUK pointed out earlier, I stopped learning Perl when I had enough knowledge to get my immediate work done, and I resent the (sometimes perceived as oh-so-clever elitist) folks who were more thorough in learning the language and can thus fully use its capabilities without having to puzzle over it.

[chromatic]

When you don't cooperate with my selfish goal but instead have fun with your own elegant approach...

Please don't put words in my mouth.

I've used a lot of obscure and esoteric features of Perl. Some were for good reasons and some were for very bad reasons.

I've also spent five years writing tests, writing test modules, giving talks on how to test Perl, and writing books and articles on how to make Perl code more maintainable. It would be nice if people would take that into account before jerking their knees so hard they mistakenly hit enter before thinking about what I said.

The presence of idioms in Perl the language or in code written in Perl is not the problem.

The problem is in people using idioms badly, ineffectively, and antisocially.

Take P5NCI for example. There aren't a lot of people who can look at that code immediately and tell what's going on, or how it works. Yet also look at P5NCI::Declare and tell me that doesn't make a lot of maintenance problems related to XS and language bindings just go away. If the people who just wanted idioms and weird features and stuff they don't understand to go away had their way, I couldn't have written either module.

Remember, there are people on this site who don't understand hashes, let alone map or anonymous functions or closures. I don't expect them to maintain my code, not because I revel in complexity or have some ego complex about being the smartest programmer in the room. (Trust me; I know way too many other programmers to believe that.)

I don't expect them to maintain my code because they don't have any business maintaining my code without more experience and at least some guidance from another experienced programmer.

Now if, some day in the future, I find myself on a programming team where the team's guidelines are to avoid anonymous functions or closures, I won't necessarily like it, but I'll program that way (and I'll probably try to explain how they work to the rest of the team and get them back on the approved list).

I'm not giving up all of the great features of Perl that make me more productive and make my code more powerful, more concise, more expressive, and more maintainable just because someone, somewhere might not understand them. I'll write tests. I'll write documentation. I'll explain it over and over. Yet expecting people not to have to learn anything to maintain code is silly and wrong and a grave technical risk and I'll keep saying it until people listen.

Update: corrected module name