Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister

Levels of strictness and compatibility

by Anonymous Monk
on Feb 16, 2014 at 23:05 UTC ( #1075110=perlmeditation: print w/replies, xml ) Need Help??

A little while back there was a long discussion on p5p/RT about fatal warnings, a blog posting about fatal warnings by chromatic, and a long discussion about use VERSION; and related issues in here on PerlMonks.

All this got me thinking, and I realized that Perl gives you an incredible amount of control over features, strictures, warnings, best practices, and on and on:

This variety makes it pretty obvious that which of these apply will be different between people and applications. So the next time someone disagrees with a recommended practice or Perl's defaults, it might be helpful to point out the number of choices and level of control they have.

Replies are listed 'Best First'.
Re: Levels of strictness and compatibility
by BrowserUk (Patriarch) on Feb 17, 2014 at 00:21 UTC


    • If you employ none of them:

      It is almost impossible to write a program -- that despite compiling clean -- functions correctly.

    • If you employ all of them;

      It is almost impossible to write a program that actually compiles -- even if it would function perfectly correctly.

    So the challenge as a newbie is what level of prophylactic should you employ?

    And as a reasonably experienced Perler; what level should you employ to ensure that your perfectly functional code cannot be trivial modified in an incorrect way without tripping a warning or error of some kind; without having burdened it with overhead such that it is entirely useless?

    And, IMO, the answer is: you cannot. In the end, one has to assume some more-than-beginner, less-than-expert level of competence from those that will follow you.

    Attempting to pander to the lowest common denominator, is an exercise in futility; and more damaging to the language than obfuscation!

    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
Re: Levels of strictness and compatibility
by sundialsvc4 (Abbot) on Feb 17, 2014 at 20:25 UTC

    Most of the code that I encounter was written by other people, many other people, over a long period of time.   Long enough that both the framework technologies and even [Perl | whatever] itself have evolved.   When you look at a code-base like that, you can watch the influence of various fads and fashions, as they come and go.   There have been just three things that I have most wanted to ask / beg of the coders who are writing “the crappy code of tomorrow” ;-), today:

    (1) Write for the future, and be consistent with the past.   Sometimes it is much better to keep one way of doing something, in a large application, than to introduce another way of doing the same thing that (a) is no better, and (b) burdens other parts of the system ... especially, exception-handling code ... with decision-making therefore complexity that doesn’t bring added value.   For instance, use eval or Try::Tiny, but not both.   Don’t launch on a big project (especially an unauthorized one) to save the application from itself.   Some of the directives in Perl exercise a surprise influence upon how the language itself behaves, and this can be hugely disruptive, especially if their introduction by you into the project is, itself, a surprise.   Yes, we have the use languageversion; pragma, but there needs to be universal consensus before introducing any new code anywhere that would oblige one to use it.   An application consists not only of itself, but the entire and total context which surrounds it.   Undetected instability can come from anywhere.

    (2) Don’t commit an “off-topic” change, or one that is any larger than it truly is required to be.   If, for example, you get annoyed that a piece of code is being Perl::Criticized, and you decide to Perl::Tidy it up to make it “–er,” you have just cut-off that entire piece of code from its history ... affecting every thread of changes in the version-control system that ever passed through that region of code.   (In every version-control system that has ever in the past been used ...)   It can even be very-disruptive for a piece of code to be visually different from the prevailing norm, even if some tool/pundit things that the new appearance is “–er.”   New ideas, which might be fantastic in a brand-new application (and how long has it been since you actually saw one of those ...?) can just be de-stabilizing.   There are no absolutes.   “There’s More Than One Way To Do It™” doesn’t mean that it is a good idea to introduce another way.   (In fact, please don’t.)

    (3) Write for simplicity, and write tests for everything that you write.   Perl is not a strongly-typed language; the mere fact that a piece of source-code compiles does not tell you much of anything at all.   Many coders coming into the labor market today do not seem to be well-versed on this idea.   They are very dependent upon “compile-time” errors and warnings which Perl often simply does not have ... and, they are unaccustomed to seeing some of the very dynamic behaviors that are routinely used when writing (especially, legacy ...) Perl source-code.   If you do not have “test-driven development” in a Perl shop, maintaining stable releases can be very difficult ... especially among the work of the “new hands from foreign lands.”   The only way to know that something works, and that it did not break something else, is to continually prove it.

    “Compatibility,” then, is not entirely a language feature:   it is a process feature.   It is an attribute, not so much of the language (whatever it is), but of the team’s own internal disciplines – and your own.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://1075110]
Approved by Athanasius
Front-paged by Old_Gray_Bear
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (7)
As of 2022-01-18 22:20 GMT
Find Nodes?
    Voting Booth?
    In 2022, my preferred method to securely store passwords is:

    Results (54 votes). Check out past polls.