Re: Traffic lights and language design

* Michael G Schwern <[email protected]> [05/04/2001 15:51]:
>
> Oddly enough, varying the number of traffic lights can effect
> efficiency.  By over-regulating you can choke off traffic.  Constant
> fiddling with the setups and timings, trying to control each and every
> intersection to maximize throughput leads to gridlock, zero
> throughput.  The exact opposite of what was intended.
> 
> We are in danger of doing just that.  By wanting to correct,
> streamline and optimize every bump and snag in Perl we may cross some
> imaginary line and have syntactical gridlock where the language design
> descends into a morass of continual minor adjustment.  By backing off
> we can often find a much more sweeping solution than just putting up
> lights on every corner.  A perfect example is Larry's "module"
> solution to the Perl 6 vs Perl 5 interpretation (although it still
> needs a few extra lights here and there to make it really work).

Actually, I can relate to this, this is the same feeling I got when
reading parts of Apoc2. 

First off, I think many of the deeper semantic changes are very much on
the right track. Such as the new context rules, and the way that
variables are treated as references. So in Perl 6:

   @foo = (1, 2, 3);
   print "First one is ", @foo[1], "\n";
   @bar = @foo;         # reference copy, not list flattening

I think this is good. Excellent, actually, there's lots of potential to
improve the way arrays/hashes/lists are handled this way.

However, I think lots of the proposed syntactic changes to Perl are
on the verge of becoming unnecessary. And here I'm NOT talking about
.-deref, since some of Larry's comments have convinced me there's some
additional semantics to gain from this (.foo like $foo). I'm thinking
more along the lines of:

   @list = < foo $bar %baz blurch($x) >;
   @list = qw/ foo $bar %baz blurch($x) /; # same as this

I can't help but thinking "Why?" The whole q-series of quoting ops are
easy to understand and use. Do we really need a "prettier" alternative
to them? The same thing for having to do:

   print <<"EOF";
Hello, $name
EOF

Again, this seems unnecessary. Does it make things more consistent? Yes.
Does it make things easier? No.

Damian Conway said something a while back to me, and I never realized
how important it is to Perl:

  Just remember that consistency is a hobgoblin, and has
  little sway in Perl.

A key tenet is that Perl isn't the most consistent language, but it is
one that has intelligent defaults which suit programmers well. I worry
we're reacting against what other non-Perl-hackers complain about. But
often these are the same things that JAPHs love about the language.

Anyways, this isn't meant to spawn a religious war, but I do agree
changing too much syntax without marked gains is not a good thing. I
think we should only mess with stuff that's really truly broken, not
just that's suboptimally attractive.

-Nate