Re: another take on hackers and painters

[Dan Sugalski <address@hidden>]

At 8:52 AM -0700 5/24/03, Paul Prescod wrote:
>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.

I don't think the gap is unbridgeable. I think it's more getting 
people to realize that there is a gap, and that behavior that is 
appropriate in one problem domain may not be appropriate in another, 
and that there really are many problem domains.

The latter is, I think, the biggest problem. It's very easy to slide 
from "this is the area that I find interesting" to "this is the only 
area that is interesting" to "this is the only area". Or to go from 
"This is my way" to "this is the only way". Partly this comes from a 
sort of arrogance that programming brings on--we can make these 
machines do whatever we want if we're clever enough, and that does 
induce a bit of ego. It's also partly because computers are used in 
such a vast range of places and ways that it's likely impossible to 
keep them all straight, so we don't realize that there are other 
requirements in other places.

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

Sure. Go sum a column with occassional subheads in it and it's terribly useful.

>>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):

While I know you've already seen the answer to some of these, going 
over them is worth it for everyone else, so...

>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.

Modules aren't developed in isolation--at the very least you need a 
test harness and a wrapping sample program to make sure the darn 
thing works. The default test and wrapping code that the skeleton 
module creator emits turns on warnings and strictures by default, and 
even when those are skipped and people go hand-rolled, they normally 
throw in warnings in their testing code. And since so many people put 
warnings on by default when writing large programs anyway, modules 
they snag from CPAN will get run through the warning gauntlet. CPAN 
modules that aren't warnings-clean don't get used that much. It's 
pretty darwinian.

>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.

Yes, without a doubt. But... so? Simpler languages tend to push off a 
lot of their semantics to their library instead (C's printf, anyone?) 
which just shifts the semantic burden, not lessening it. Shifting 
this burden is only a win if you can ignore the semantics because 
they're in the library, but often you can't. Since the shift seems to 
increase the total semantic burden (I don't know if this is intrinsic 
in the shift, or just that less thought is given to the library code) 
there really isn't any easing of effort. You trade six months of 
language learning for two years of library learning.

Even without that.... so what? The languages people use are complex 
and messy, and programming languages are meant for people. For the 
longest time languages were simple, but this was out of necessity, 
not choice. That doesn't mean they shouldn't be complex, just that 
they couldn't be.

I'm not trying to argue that all the decisions perl has made are 
correct, because for many of the decisions correct is 
domain-specific, and for some of the others the decision that was 
made is in hind-sight demonstrably sub-optimal. That's fine. What I 
*am* trying to argue is that the things perl has chosen to do are 
very valid things to do. The defaults we've chosen (or that have sort 
of fallen out) may not be what someone else would choose, and a 
language with a different feel would have different defaults, but the 
things we've chosen to do are useful things worthy of doing. *That's* 
the important point.
-- 
                                         Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                       teddy bears get drunk