[sf-perl] use {strict,warnings}

[Rich Morin]

DF> What a bummer for Ruby that it doesn't have this basic
DF> kind of protection...over ten years after perl got it. ;)

Fortunately, I can add features to Ruby via metaprogramming
of various sorts, make them dynamically configurable, etc.
And, in Rubinius, I can actually extend the interpreter to
(say) collect more information as the script is being parsed.
Unfortunately, all of this requires Real Work...


DF> Tests, if you'll pardon the Rumsfeld-ism, are for known
DF> unknowns, and they frequently lead to a false sense of
DF> security.  It's the unknown unknowns that come up and
DF> bite you on the butt.

Peculiarly, many in the Ruby camp use a similar argument to
say that built-in tests (as provided by strict and warnings)
are too low-level, so they don't catch semantic and design
errors.  "Just write appropriate tests."

My take is certain types of errors are known to be common,
so why not let the computer check for them?  Of course, the
tests should be optional, customizable, and dynamically
configurable.

FWIW, the Fortress type system has some interesting ideas.
For example, it can keep you from calculating furlongs per
fortnight and saving the result in a variable whose type is
fortnights per furlong.  I don't think I want to be required
to specify things that tightly for much of my work, but when
the code really has to work, this can provide useful checks.


QW> - Wherever possible, make the analysis static.
QW>
QW> - If you can't do perfectly reliable static analysis,
QW>   heuristics are still good.
QW>
QW> - Make some kind of prepackaged test target that runs
QW>   all your tests (or a chosen subset) and either flunks
QW>   your program or gives it a clean bill of health.

+1

-r
-- 
http://www.cfcl.com/rdm            Rich Morin
http://www.cfcl.com/rdm/resume     rdm at cfcl.com
http://www.cfcl.com/rdm/weblog     +1 650-873-7841

Technical editing and writing, programming, and web development