a module may load another module that may load another module that may do something that clashes with a global the main code is using; those issues are not fun to debug

Those issues are especially hard to debug because modules are not supposed to do that: each module should be in its own package (or be closely coordinated with any other components that share a package) and each package has its own "global" namespace, including bareword file handles. (But I have already said indirectly that modules should be using lexical file handles, except, for example, a logging module that opens the log file as a global handle in its package.)

"you don't need strict as long as you don't make typos"

Strictly, (pardon the pun) that is correct, but Murphy's Law says that the typo you do make will drive you crazy when it happens if you rely on that. :-)

you seem to be placing a lot of expectations on people to write correct code, when simply using lexical filehandles easily provides protection from the issues

As a polyglot programmer that often works in other languages that simply do not have those protective features (there is no "use strict" in Awk or Bourne-family shells, for two examples) I have come to see those expectations as routine because in languages that do not require variable declarations, they are.

I suspect that there is some limit of human attentiveness, such that a small set of "watch these carefully" is workable, but as that set expands, the risk of typos increases. In Awk or shell, this can effectively be an upper limit on the size of a program.

what do you mean with an "environment parameter"? And I very strongly disagree with "only option"

An implicit parameter passed via a variable with dynamic extent, such as a variable declared special in Common Lisp or a global variable in Perl. Such usage is rarely a good idea (at least in Perl), but can sometimes be necessary to work around badly-designed API limitations and pass needed information to a callback procedure, although a combination of closures and function currying might work in most cases, at the expense of being even harder to debug.

In reply to Re^6: Summing numbers in a file by jcb
in thread Summing numbers in a file by pvfki

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.