Front page | perl.perl6.meta |
Postings from May 2001
Traffic lights and language design
From: Michael G Schwern
May 4, 2001 15:51
Traffic lights and language design
Message ID: 20010504235102.D4926@blackrider.blackstar.co.uk
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
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
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 flash morse code between
ships. More commonly, FM (Frequency Modulation) radio is essential
just a big flashing traffic light.
Traffic lights chose to use only one frequency. Why? Simplicity.
There is flashing and there is not flashing. That's it. Easy to
remember, but more importantly, easy (and quick) to recognize. Very
important when a car is approaching at 65 MPH.
There comes a point when you're cutting the syntax too fine. When the
distinctions between one meaning and another take too much careful
examination to distinguish. A good example being the string concat
proposals which wanted to use certain whitespace combinations to
distinguish, or special uses of quotes. Perl 6 must be very careful
of this sort of thing as we strive to shove more and more information
into just 95 lights (the set of printable ASCII characters). There's
a reason the Navy employs highly trained men on those Morse lights.
Finally, there's sound. I lived in Pittsburgh for a while near a
school for blind children and a clinic for the blind. The major
intersections for a few blocks around all had the normal walk/don't
walk pedestrian signals, but these are a bit different. Rather than
the usual Walk with the green, Don't Walk with the red, it would be
Don't Walk in all directions. When Walk came on, all lights would go
red and pedestrians could cross in any direction.
This was accompanied by a very distinct, very loud "koo-koo" sound to
let the blind know it was time to cross. Also, there was a speaker at
every corner to give them something to walk towards.
Sound as syntax. It would be interesting to use sound as grammar,
especially since we usually use grammar to represent sound (ie. sheet
music). However, I don't know about you, but I'm not about to start
dragging around a Moog with me to code Perl... though playing chords
to represent code would be very neat. Imagine the twisted noises
coding up a particularly nasty regex might produce.
Rambling along this thread, its been reported that London.pm recently
attempted to encode DeCSS as an interpretive dance. Perhaps DeCSS
will surpass the Tarentella as the "Forbidden Dance".
There are also some attempts at translating Perl code to music. I
think someone hooked Perl code run through the DNA module into
something that generates music from genetic code.
But I digress.
Let's think about what traffic lights are used for. Well, they're
there to control the flow of traffic. Theoretically, you'd want to
use them to maximize use of the available roads and get the most cars
to their destinations as quickly and efficiently as possible. You'd
do things like time the lights down a stretch of road so someone going
the speed limit never hit a red light. You'd want to keep the lights
green as long as possible on the major roads at intersections. You'll
want sensors to detect when no car is waiting for a red so it can keep
the other side green longer. By doing this you'll get everyone
coordinated and moving about quickly.
But then traffic lights can be used for directly contradictory goals.
They can be used to deliberately slow and minimize traffic, say around
a school or in a shopping district with lots of pedestrians. Lights
will be deliberately set to prevent a driver from going continuously
down a road, making them stop often and keeping their awareness up
(but perhaps their frustration as well). All sides of an intersection
can be stopped at once to allow pedestrians to pass safely. Flashing
yellows can be employed to warn of a school zone. Lights can be
placed at dangerous intersections (or ones where children are known to
be about) even though drivers should be able to self-regulate.
So the exact same device and features can be combined and used in
slightly different ways to produce contradictory effects. Perl must
have this nature, as is clearly evident from the wildly differing and
contradictory RFCs presented, often in direct opposition to each
other. We should design Perl features to be like traffic lights. The
same feature used to may different and contradictory effects. This
will ease the pressure to squeeze more and more grammar out of our
limited syntax possibilities.
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).
Yep, my brain is done with this.
Michael G. Schwern <email@example.com> http://www.pobox.com/~schwern/
Perl6 Quality Assurance <firstname.lastname@example.org> Kwalitee Is Job One
Any sufficiently encapsulated hack is no longer a hack.
Traffic lights and language design
by Michael G Schwern