Re: "static" declaration

[Michael Vanier <address@hidden>]

> From: kragen@pobox.com (Kragen Sitaker)
> Date: Sat, 10 Aug 2002 23:18:42 -0400 (EDT)
> 
> > 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.

A new paradigm for programming -- "programming by intimidation" ;-)

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

What I think would be really cool is if languages gave programmers the
power to define their own conventions that could then be enforced by the
compiler.  Sort of like a user-programmable "use strict" pragma where the
definition of "strict" could be up to the programmer (or, more
realistically, the programming team).  This would cause this particular
debate to evaporate.

Mike