4 ms·

I guess you've never written any bash either, wherein the exact same problem exists except that == and eq are the other way around, for reasons I can't quite re

by mst 12y ago

I guess you've never written any bash either, wherein the exact same problem exists except that == and eq are the other way around, for reasons I can't quite remember. Plus, of course, if you'd enabled perl's warnings system, via 'use warnings;', it would have complained at the use of == on a non-numeric value. If you don't enable the compiler features that catch problems, then, yes, you can run into problems. Welcome to programming. Edited to add: I got downvoted within five minutes. If you disagree that my bash analogy is inaccurate, I'd love to hear why.

scrollaway 12y ago
I did not downvote you, but comparing a language to Bash is certainly in no way flattering, and I would definitely not put it in the "good defense analogy" category.
- mst 12y ago
  Comparing a final conditional in a systems-style script that is then calling another program, shell-style, to bash, which is the most common language where you'd execute a conditional then call another program, seems reasonable. Maybe not flattering, maybe not a good defense, but I think under the circumstances an acceptable comparison.
amenbrother 12y ago
Thanks for the 'use warnings;' suggestion. Keep in mind the subject here is maintainence - where small changes with minimal impact to production is the rule and the work is often done by programmers with incomplete knowledge and no patience for explanations. For maintenance you want KISS, not TMTOWTDI. I'm no big fan of bash but at least bash gets the common case right here without any special settings. For example, if I use -eq instead of == and write #!/bin/bash x=`cat FOO 2>/dev/null` if [ $x -eq 'bar' ]; then echo baz fi as you imply, bash won't be silent. It will say bash-3.2$ ./example.sh ./example.sh: line 3: [: bar: integer expression expected
- mst 12y ago
  Equally, bash requires 'set -x' to not ignore errors. In both cases, the reasoning is significantly to do with backcompat, I believe. So, yeah, things that have been around a long time often require a setting to be safe in cases that we, ten or twenty or whatever years on, consider common. Also: I did keep that in mind. That's why I started off suggesting using warnings, rather than (as I normally do for new code) making them fatal :)
Joeri 12y ago
Sane defaults are a cornerstone of good language and framework design because for better or worse people don't read the manual before they start using something. If a compiler doesn't do the right thing by default (throwing errors on problems a new user is likely to cause), it's a bad compiler.
- BugBrother 12y ago
  What sane defaults are will change over the years. Perl kept amazing backwards compatibility by adding extra statements to modify how it worked. So "use strict;", "use warnings;" and "use <other_newer_perl_features>;". Both new code -- using the best OO system of the scripting languages, extendable syntax, etc, etc -- will run at the same time as most of the old and crufty stuff from before testing took over after the Millennium.
  - SilasX 12y ago
    Lines that can affect the global behavior of the program are a mixed blessing.
    - BugBrother 12y ago
      It would have been bad, if the design had been stupid enough to not make declarations file/package based... :-)

by mst 12y ago

scrollaway 12y ago

I did not downvote you, but comparing a language to Bash is certainly in no way flattering, and I would definitely not put it in the "good defense analogy" category.

mst 12y ago
Comparing a final conditional in a systems-style script that is then calling another program, shell-style, to bash, which is the most common language where you'd execute a conditional then call another program, seems reasonable. Maybe not flattering, maybe not a good defense, but I think under the circumstances an acceptable comparison.

amenbrother 12y ago

Thanks for the 'use warnings;' suggestion. Keep in mind the subject here is maintainence - where small changes with minimal impact to production is the rule and the work is often done by programmers with incomplete knowledge and no patience for explanations. For maintenance you want KISS, not TMTOWTDI. I'm no big fan of bash but at least bash gets the common case right here without any special settings. For example, if I use -eq instead of == and write #!/bin/bash x=`cat FOO 2>/dev/null` if [ $x -eq 'bar' ]; then echo baz fi as you imply, bash won't be silent. It will say bash-3.2$ ./example.sh ./example.sh: line 3: [: bar: integer expression expected

mst 12y ago
Equally, bash requires 'set -x' to not ignore errors. In both cases, the reasoning is significantly to do with backcompat, I believe. So, yeah, things that have been around a long time often require a setting to be safe in cases that we, ten or twenty or whatever years on, consider common. Also: I did keep that in mind. That's why I started off suggesting using warnings, rather than (as I normally do for new code) making them fatal :)

Joeri 12y ago

Sane defaults are a cornerstone of good language and framework design because for better or worse people don't read the manual before they start using something. If a compiler doesn't do the right thing by default (throwing errors on problems a new user is likely to cause), it's a bad compiler.

BugBrother 12y ago
What sane defaults are will change over the years. Perl kept amazing backwards compatibility by adding extra statements to modify how it worked. So "use strict;", "use warnings;" and "use <other_newer_perl_features>;". Both new code -- using the best OO system of the scripting languages, extendable syntax, etc, etc -- will run at the same time as most of the old and crufty stuff from before testing took over after the Millennium.
- SilasX 12y ago
  Lines that can affect the global behavior of the program are a mixed blessing.
  - BugBrother 12y ago
    It would have been bad, if the design had been stupid enough to not make declarations file/package based... :-)