Re: Traffic lights and language design
[again, apologies if this is a duplicate] * 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 certain 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. It seems to impose unneeded burden on the programmer for the most common case. 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. At the time I gasped - how could we ignore consistency?! - but then I realized that though Perl isn't the most consistent language, 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
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
Traffic lights and language design
Excuse me, I'm going to ramble a bit about traffic lights and see if something interesting falls out. I was riding to work today and started thinking about the trouble we were having with string concatination (no, this isn't another concat proposal) and how the basic problem is that we've run out of ASCII characters. I briefly thought about Unicode, but its not nearly well supported. Then I stopped at a traffic light (the police in Belfast get annoyed by bikes blowing through lights, even at 2am on an otherwise road. And the bastards drive unmarked cars). Traffic lights convey their signals through color. I briefly thought it would be neat to convey Perl grammar via color, but that can't be done for similar reasons to Unicode. The interesting thing about traffic lights is the color is just for clarification. The real communication is through position. Stop on top, caution in middle, go at the bottom (some countries do this a bit differently, but that's generally how it goes). This is important because a large section of the population is color blind, but even if you saw a traffic light in black-and-white you could still make out the signals by their position. If you ask anyone on the street what 'stop' and 'go' are on a traffic light, they'll probably say 'red' and 'green' without even thinking. But if you asked them to draw a traffic light they'd be sure to put the red on top and green on bottom. Its very interesting that although we respond strongly to color cues, we subconciously remember the positional cues. Its especially interesting given that we're never actually taught "go is on the bottom". There's a thin analogy to syntax highlighting of code, where the color is just there to highlight and position conveys the actual meaning. This idea of having redundant syntax which exists to merely make something easier to remember is perhaps one we can explore. Now, color and position aren't the only tools a traffic light has. Order is another. Stop, Go, Caution, Stop, Go, Caution... it goes that way. Again, most people know this subconsciously even if they've never been taught it or ever thought about it. Its a pattern that's picked up on and expected. Go follows Stop. Caution precedes Stop. If a light were to suddenly jump from Caution to Go, drivers would be momentarily confused and indecisive, even though they know perfectly well what both signals mean. The lesson there is simple. Be consistent. So while order doesn't convey any extra information, its consistency can be important. I experienced this on coming to Belfast. The lights here go Stop, Caution, Get Ready, Go where "Get Ready" is conveyed by a combination of red and yellow. Very useful (especially if you drive a stick or have toe-clips on your bike) but a bit confusing the first few times. This directly contradicts the above lesson, eshew consistency if its going to add a useful feature. Which brings us to another tool. Combinations. Although rarely done, you can squeeze more meaning out a set of lights by combining them. Just like a 3 bit number. The red/yellow combination is the only one I can think of, and probably rightly so. While there's still three more combinations available, they would rapidly get confusing if used. Perhaps the lesson there is, just because you can wedge meaning in doesn't mean you should. The final method of communication is flashing. Flashing red is like a stop sign. Flashing yellow, proceed with caution. I don't think flashing green is ever used or what it could mean. Most flashing lights are there to draw attention. Emergency vehicles, gaudy advertisments, navigation lights. Flashing signals are deliberately jarring. They're also rarely used in combination with the normal signals. This is very important. The normal confusion associated with a break in the pattern isn't there since the normal pattern is totally absent. The meaning of the flashing signals themselves is very close to their normal solid meaning, which allows most drivers to know what they mean without really thinkng about it. Flashing signals are also rather rare. They're used at times when there's few cars on the road (late at night) or on roads which experience little traffic. The lesson there, if you're going to be inconsistent, make sure you don't do it in a way that will mix with the normal pattern of things. Think about how the inconsistent feature will be used and make sure it will be used in spots that are distanced from normal use. Also, the potential uses of the inconsistent feature should be relatively rare. Although it will vary from light to light, a single light will only use one frequency. They could use more. In fact, an almost infinite amount of information could be conveyed by varyious frequencies of flashing. This technique is in active use today by most Navies of the world as a method of secure, short-range ship-to-ship communication. Powerful lamps with shutters are used to fl
