http://www.perlmonks.org?node_id=864202


in reply to Writing a better Modern::Perl

There is a very delicate balance to be struck here.   On the one hand, we want it to be convenient for us to write accurate, robust software.   On the other hand, we must always be able to look at a piece of software and to ascertain, correctly, what it will do.   Programmers handle this by devising standard practices within each “shop.”   They dub their favorite things, “best practices,” and subsequently stand around the Monastery's electronic water-cooler, bickering in a friendly way about what “best” actually means; what is “better.”

Being good Perl programmers, they practice laziness and hubris.   They automate things.   Then, they insist that everyone else should automate things just the way they did.   But change happens slowly, if at all.

They’re professionals, often with twenty or thirty years in.   Among the very best.   The disagreements, and the insistence, and the resistance, all come from people who know whereof they speak.   Change happens.   Slowly.

I have learned to be reluctant about things that are “too convenient.”   Specifically, about things that place substantial influences over the behavior of a piece of source-code, anywhere outside of that piece of source-code.   In my experience, such things, well-intentioned though they might be, create substantial difficulties.   Call me a Luddite if you want to... ;-)   I can be convinced, but not quickly.

Replies are listed 'Best First'.
Re^2: Writing a better Modern::Perl
by chromatic (Archbishop) on Oct 08, 2010 at 21:33 UTC
    They’re professionals, often with twenty or thirty years in.

    I didn't write Modern::Perl for professionals who know the ins and outs of Perl 5 and who have customized their development environments such that their editors always insert the appropriate preludes for them.

    I wrote it for people who don't yet know enough Perl 5 to understand the half-dozen lines of code that pretty much every new Perl 5 program begun today really ought to have.

      I see that.   And, I did not intend my comment to be in any way critical of, nor disrespectful of, you or your work.

      Indeed, it is highly desirable to have modules that make it easier (and more trouble-free) to “DDRT=Do The Right Thing.”   The natural and understood trade-off is, the need to understand precisely what they are doing ... and the need to improve-upon the “DDRT” module without breaking a mountain of existing code that has been written to use it.   Every ointment has its houseflies...

      The bugaboo is this:   if we have n Perl modules that are all relying upon the behavior of (some hypothetical) DDRT 1.0, those n modules now have a material dependency ... not just to DDRT 1.0, but to one another.   Not only might you find it to be difficult to change or to replace the DDRT module, but also you might find it problematic to “do anything different” in any one of the client modules.   It might be “all, or nothing.”

      If we found it business-necessary to implement “different” behavior in some particular module, we might find that we have no practical choice but to replace the DDRT module calls with “what that module would have done, only slightly different.”   And, when that continues to happen over time, the benefits begin to disappear, or are negated.

      Alternatively, some clever programmer might find a way to “work around” the not-quite-desired behavior or implementation of DDRT through resorting to some kind of “clever trick.”   Something that leverages a side-effect, or an undocumented subroutine, or something even more obscure.   “It works!”   But... how soon will it be forgotten?   And, when we replace DDRT with NAIDDRT (“New And Improved...”), suddenly there are problems.   Maybe the problems spew all over our production-schedule, but maybe ... far worse ... they don’t.   Or, they initially do not appear to.   It is three o’clock in the morning.   Your beeper just went off ...

      Houseflies do not go to sleep at night.

      Again, I do not intend anything negative by these observations.