Re: another take on hackers and painters

[Paul Prescod <address@hidden>]

Dan Sugalski wrote:

> ...

> The big reason for this is the origins of perl--it started as a language
> for quick-n-dirty sysadmin and text processing tasks and grew out from
> there. Many of the programs lived only on the command line, and many
> more were thrown together in a dozen or two lines of code. The data they
> dealt with was dirty, but dirty in predictable ways, and perl's defaults
> are shaped to deal with that. When you're throwing together a quick
> program to tally up data from log files, you don't *care* about the
> error conditions--it's bad data, and you want to ignore it. (Which is,
> in this realm, the appropriate action)

I guess there is an unbridgable gap in perceptions there. Although I 
occaionally sysadmin, I bring an engineer's perspective that *I always 
need to be told about bad data*. Maybe in the end I will decide to 
ignore it, but ignore could mean replacing it with 0, or 1, or -1, or 
ignoring all of the other data in that "record" or "line" etc.

On the other hand, Excel will happily sum "1", "abc" and "5" so I guess 
there is a market for that behaviour.

> If you're looking for more caution, that's when you turn it on, by
> enabling warnings, or even more by forcing warnings to errors. That's
> fine, works the way we want it.

That solution may be fine for Perl but it also has serious drawbacks 
(which perhaps are not that large for Perl's problem domains):

First, what if someone else on my team has created a module that all of 
a sudden starts spewing warnings or errors when I turn on the flag? What 
if my "team" is CPAN? Global flags do not interact well with programming 
in the large. Sure, these issues are tractable if we apply peer pressure 
appropriately, but I'd prefer to let the language deal with it than do 
it in email. After all, even memory management can be handled as a 
social rather than software issue...but I'd rather not.

Second, a language with a variety of modes and different behaviours in 
those modes is generally harder to learn (in total) than one without modes.

  Paul Prescod