Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW

Re^2: Writing a better Modern::Perl

by chromatic (Archbishop)
on Oct 08, 2010 at 21:33 UTC ( #864285=note: print w/replies, xml ) Need Help??

in reply to Re: Writing a better Modern::Perl
in thread Writing a better Modern::Perl

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.

Replies are listed 'Best First'.
Re^3: Writing a better Modern::Perl
by sundialsvc4 (Abbot) on Oct 10, 2010 at 15:14 UTC

    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.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://864285]
[hippo]: Which people and how long ago?

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (7)
As of 2018-05-22 10:17 GMT
Find Nodes?
    Voting Booth?