Re: "static" declaration

[address@hidden (Kragen Sitaker)]

Dan Weinreb writes:
> What's so reasonable about that?  If you misspell the name of a key,
> fetch the value associated with that key, and print it, Perl doesn't
> give you any hint that something went wrong.  The end user could
> easily walk away from looking at the program output, thinking that
> the computer had computed that assertion X is true, whereas in fact
> the whole thing might be based on a misspelling that was never
> caught.  That seems like a great formula for unreliable code and
> surprising failures in the field.

It's more reasonable than any other possible default, such as "" or 0
or 37 or 'Your mother wears army boots', and yes, it is a great
formula for unreliable code and surprising failures in the field.
That's why I always use -w on my Perl programs and make them run
warning-free, so that Perl *will* give me a hint that something went
wrong in this case, and it's also why the vast majority of recent
items at http://lists.canonical.org/pipermail/kragen-hacks are in
Python, not Perl.

> >Python's philosophy is to refuse to guess in the face of ambiguity;
>
> I would say that continuing to run the program after a hash lookup
> failed (and there wasn't anything anywhere to say that such failure
> was really OK) constitutes guessing in the face of ambiguity!

Yes, that's why Perl continues and Python raises an exception in this
case.

> Gee, I wonder which conventions, exactly, you mean when you say
> "normal Perl conventions".  Certainly the Perl expression above is
> depending very cruciallly on certain conventions.  In my experience,
> even in a fairly disciplined and experienced programming team, you
> can't expect the conventions to always, rigorously be followed.  So
> if I am looking at a Perl caller-callee cross-reference and see that
> there are only two callers of a certain subroutime, and I refactor
> the subroutine based on what I learned from those two callers, I
> might very easily screw it up.  I don't think there are universal
> Perl conventions and I'm skeptical that the "yes, there's no design,
> so there" Perl culture are a good breeding ground for
> well-documented languages suitable for writing enterprise code that
> will live over ten years and have more than 30 people maintaining it
> over time;

I agree with all of the above; I will say, though, that the brutally
abusive environment of comp.lang.perl.misc is relatively effective at
getting people to follow a fairly uniform set of conventions to avoid
problems like you describe.

I would like to point out that the difference between languages in
their dependence for sanity on sane convention is largely in how
widely the conventions are followed; for example, most C++, Smalltalk,
and Lisp dialects, Python, and to some extent, even Eiffel, allow
programmers to willfully violate module boundaries and "peek behind
the curtain" of any abstraction; it's just a matter of how easy it is
and how commonly it is practiced.

-- 
<kragen@pobox.com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
Edsger Wybe Dijkstra died in August of 2002.  This is a terrible loss to the
whole world.  See http://advogato.org/person/raph/diary.html?start=252 and
http://www.kode-fu.com/geek/2002_08_04_archive.shtml