There's an old, old story about a guy in Britain who stood up in front of
a crowd--kinda like this one--and told everyone that he could make a pun
on any subject.  There was silence for half a moment, and then someone
piped up from the back and said: "Make a pun on the Queen."  Without
missing a beat, the guy said, "The Queen--is not a subject."

Now, I'm not going to tell you that I can make a pun on any subject.
I can, but I'm not going to tell you that.  In these State of the Onion
talks I always try to avoid talking about subjects.  That's because
Perl is object-oriented.  You're objecting.  That's your subjective
opinion...

So anyway, I won't make a pun on any subject today.  Any more
subjects, I mean.  But I would like to do something kinda like that.
In years past, I've explained a bit about how Perl works like a
natural language.  Now if Perl really is like a natural language,
then it has a very wide problem domain, and you should be about to
relate Perl to almost anything.  Or at least, I should be able to.

So what I've decided to do this year is take a set of six random
topics and talk about Perl with respect to each of them.  Or more
likely, with disrespect to each of them.

For my six random topics, I picked up a copy of the latest Scientific
American, dated August of 2002.  It turns out that there are six feature
articles in this issue, on completely random topics.  You don't believe
me?  I'll prove they're random in just a moment.

If you happen to have brought your Scientific American with you for a
little light reading during the boring parts of the quiz show tonight, then
you're in luck.  You can just follow along the table of contents.
If not, you can visit www.sciam.com via your wireless connection.
I should warn you, however, that they put the table of contents in a
different order on the webpage.  And why did they do that?

Obviously, they put them in random order because they really are
random topics.  Q.E.D.  Hey, logic has to be good for something...

Anyway, on to our first topic, which is, I kid you not, "The Serious
Search for an Anti-Aging Pill".

Actually, I'd take them more seriously if they didn't put the word
"Serious" in the title.  I mean, come on.  Would you have taken it
any more seriously if they'd named that Star Trek movie, "The Serious
Search for Spock"?

I mentioned this to my son Aron, and he conjectured that no discipline
that has the word Science in its title is really a true science.
You only put Science in the name if you want to trick people into
thinking of it as a science.  For example:

    Social Science
    Political Science
    Earth Science
    Christian Science
    Creation Science

Dare I mention Scientology?

Oh, and let's not forget our favorite, Computer Science.

I suppose by that argument, anyone who reads Scientific American is
not really a scientist.  I'd better be careful, or I'll start to feel
downright un-American as well.

It's sort of un-American to get old, and that's what this article is
about.  It's been proven that if you starve rats, they live longer.
As long as you don't overdo it.  Or would that be underdo it?

It's also been proven that if you feed a rat 50 pounds of food every day,
it loses its appetite.

Anyway, it's thought that if you eat 30% less, you'll live longer, and
not just because you're healthier.  It really does appear to slow the
aging process.  But these guys are lazy.  What these guys would like
to do is to find a pill that mimics some of the effects of starvation,
in the hopes that we can get the good effects of starvation without
the bad effects.

More precisely, if we can find a pill that makes our bodies 30% less
efficient at processing glucose, we can keep stuffing ourselves and
not age as fast.

Now, the article doesn't point this out, but there's a problem with
this approach.  I don't know about your brain, but my brain uses lots
of glucose.  I can barely keep my brain supplied with enough of it.
That, and caffeine.  I don't want to think 30% slower.  You don't
want the Apocalypses to come out 30% slower.

Actually, on that subject, let me just say that I think it's a feature
that the Apocalypses have been coming out as slowly as they have.  When
we announced the Perl 6 effort two years ago, there was a great deal of
concern that Perl 6 development might kill off Perl 5 before its time.
Obviously, that hasn't happened, and we're all delighted to see a
healthy 5.8.0 out the door, all honor to Jarkko and the p5p crew.
Plan A is still in effect, and working well.

But there's also a Plan B, wherein I dare to put Perl on a 30%
dietary restriction and see if it will live longer.  Plan B is
not yet in effect, but we must prepare for the future of the clan.
Necessity exists.  How many of you have read the Liad books?
I'm sorry, I just finished reading one, and the idioms seem to
be leaking into my speech.

Obviously, Perl 5 has been aging, but there is no reason to bury
it just yet.  And we haven't.  But Perl 5 will eventually succumb
to the bitrot that overtakes all large projects, and we have to be
ready for the transition to Perl 6 when it is time.

But for now, both Plan A and Plan B are important, and the people
working on both are important.  They are equals--even if you think some
are more equal than others.  No one should disparage the members of the
other group.  In Liaden terms, we bow the bow between equals, with a
subtle hand flourish indicating that you're allowed to think otherwise.

In the long run, the only way to preserve culture is to pass it on to the
next generation.  But that's the long run, and you can only pass culture
along if the old generation lives long enough to do it.  So balance is
necessary--up to the point where it becomes impossible.  As they say
around here, Life's a Beach, and then you Dry.

Well, that's it for topic 1.  Let's see, what's our next topic?

Does Dark Matter Really Exist?

This article is by one of those so-called "mavericks" of science, named
Mordehai Milgrom.  Every science needs a few mavericks.  Even computer
science.  Know any mavericks?

Some mavericks turn out to be wrong, and we call them crackpots.
Some turn out to be right, and we call them visionaries.  Some
mavericks go marching right up the middle, and we don't yet know if
they'll turn out to have been right or wrong.  Often they turn out
to be wildly right about some things, and wildly wrong about others.

If they're lucky, people consider their foibles to be less important
than their contributions.  We don't much mind that Einstein was wrong
about quantum mechanics.  He turned out to be right about the fact that
Newton was wrong about physics.

Anyway, this Milgrom fellow is proposing that Newton is even wronger
than Einstein thought.  He's telling a bunch of cosmologists that
when they look for the dark matter that holds galaxies together,
they're seeing something that isn't there.  Or more precisely, they're
XXX
*not* seeing something that isn't there.  He proposes that the
data that most people take to be indicative of the presence of
dark matter may be more simply explained by tweaking Newton's laws
of gravitational acceleration.  In fact, he's been proposing this
for about 20 years, which is more than long enough to earn a star
in the crackpot sidewalk of fame.

But oddly enough, Milgrom has the respect of the scientific community,
even when they don't agree with him.  I highly recommend Milgrom's
approach to anyone who would want to introduce a revolutionary open
source product.  His approach is simply to be humble, and to not
overstate his arguments.  He says, "This might be an alternative
explanation of the facts."  He says, "I could be wrong."  By not
claiming more than he does, he separates his ego out from the idea.

And the other scientists respond positively to this--or at least, not
negatively.  You really ought to read what the dark matter scientists
say in rebuttal.  Their sidebar is entitled, "Not a Bad Idea".

Just because they don't think it's a bad idea doesn't mean they think
it's a good idea, or even a complete idea.  But Milgrom doesn't give
them a handle by which to reject it completely.  Sometimes the dogs
aren't barking simply because there aren't any other dogs to bark at.

So, just as with dark matter itself, it's what you don't see that
is often the most important.  People sometimes think that Perl is
cluttered, and in a few ways it is.  We're working on that for Perl 6.
But it's still largely true that much more has been left out of Perl
than has been put in.  What passes for simplification in other languages
is often oversimplification in my estimation.

But let me say that I could be wrong.  Occam's Razor was never
very sharp.  We claim that science is about knowledge, but that's
an inadequate view.  It's as much about ignorance as it is about
knowledge.  It's only when we admit our ignorance that we learn
anything new.

I think the biggest compliment I've gotten so far about Perl 6 was
from someone on Slashdot who said, "I'm surprised that Larry
has been able to escape his preconceptions as well as he has."

But you should know that I've always valued seeing straight above
almost anything else.  As a hobbit once said, "I saw what I saw, and
I saw what I didn't."  Seeing what's not there is one of the most
important skills for a language designer.

Well, enough that dark matter.  But continuing on in the vein of
important things you can't see, our next article is entitled,

The Ocean's Invisible Forest

It's said you sometimes can't see the forest for the trees, but in
this case, you can't see the forest for the water.  Human beings
are provincial at the best of times, so we naturally like mammals
better than reptiles, and reptiles better than bugs, and bugs better
than slugs.  But at least we see all of those regularly because we
live on dry land.  Or wet land, in the case of slugs.

But you don't see much phytoplankton unless you live on the oceans, or
go out on one of Neal Bauman's Geek Cruises.  Which I heartily recommend,
by the way.  Or you can just do like I did yesterday and look out your
window at the water in the marina, which has a nice green bloom in it.

Turns out that, although phytoplankton are only about 1% of the
world's photosynthetic biomass, they accomplish far more than their
fair share of photosynthesis.  In fact, they slurp up just about as
much CO2 out of the atmosphere as all the other plants combined.
And the odd thing is that their photosynthetic production is not
constrained by the availability of either carbon dioxide or sunlight.
Or water, obviously.  What constrains their growth is the trace amount
of iron that blows into the water as dust, because the phytoplankton
incorporate iron into an important catalyst.

Now the really interesting thing from an ecological point of view is
that we now potentially have a way to suck down large amounts of CO2
into the deep oceans by just distributing trace amounts of iron into
the oceans.  This is not only doable, it's done-able.  I mean, it's
already been done.

Whether we *ought* to do this is another question, but that's more
a question of ecological policy, not of ecological science.  Er,
I mean, ecology.

But what's this got to do with Perl, you ask?

Well, those of you who have read or heard my earlier state of the
onions--or is it states of the onion, will remember that I like
to use biological metaphors to describe the evolution of Perl.
In particular, ecology is a part of biology, and it's the aspect
that is most often neglected in the design of open source software.
There are zillions of open source projects that start off with great
excitement but soon falter for lack of a viable ecological niche.

But I've said all that before.  What I'd like to say new this time
is that sometimes ecology is a matter of policy rather than science.
And this scares me.  We often talk about open source being a kind
of grass roots phenomenon, but if you ignore the roots, it's a lot
like phytoplankton too.  In particular, it would be very easy for
governmental policymakers in various countries to squeeze out the
ecological niche for open source software, simply by denying us some
of the necessary trace elements that we need for our freedom.  You can
view the land plants as being in competition with the phytoplankton,
since the more successful the land plants are, the less dust gets
into the oceans.  I don't know whether Microsoft has ever been
compared to a land plant before.  Hmm.  I suppose people living near
Redmond would tend to think of Microsoft as a magnificent douglas fir.
Maybe they're right.  Of course, the rest of the country is thinking
more along the lines of kudzu...

Meanwhile Johnny Appleseed is going around planting apples everywhere.
I've been having a lot of fun in the last couple weeks with this new
iBook here.

While policymakers can make our lives miserable, it'd also be possible
for policymakers to fertilize the open source movement, and if they do,
they'll find that we outproduce the land plants handily.  This scares
some of the land plants, of course, but it need not.

In actual ecological fact, the land plants and the sea plants cooperate
to bring down CO2 levels, and are not much in competition with each
other.  Apple understands that, and this iBook is the proof.

I have a vision for the world in which policymakers understand it too.
But that's seeing something that isn't there yet.  There's always
a lot of dark matter in Washington, D.C.  I hope we can get where
we're going through common sense, and not just through fighting.
There are long-term consequences to the health of the world economy,
and too much of our current economic policy is tilted in favor of
large corporations who can afford to buy patents on spec.  I can't
afford to buy patents.  I can't even afford to buy politicians.

Now, there's a particular reason that small organisms can do certain
things more efficiently than large ones, and that's hinted at in our
next article, which is called:

Computers Without Clocks

This article is written by two employees of Sun Microsystems.  You may
have heard of that company.  The article is about designing computer
chips with asynchronous elements.  Up till now, most computer chips
have been totally synchronous.  They work like an assembly line in
car plant, where if everything doesn't happen right when it's supposed to,
the cars come out with parts missing.

How many of you have read A Wrinkle in Time, by Madeleine L'Engle?
One of the most memorable scenes from that book is when we see
a bunch of children all coming out of their houses simultaneously
and playing identically to each other, to the point of bouncing their
balls in unison.  One little boy can't quite manage to keep up, and
gets in trouble for it.  I always found that scene profoundly disturbing
on several levels.

But it turns out that computers find this disturbing too, because
it's hard to get computers to follow a schedule.  It's even hard to
*publish* the schedule on a computer chip, because you have to run
big clock traces all over the chip, and worry about propagation delays
and such.

This whole problem arises because we confuse two concepts.  We often
say that a things should happen right when it's supposed to happen,
by which we usually mean that the thing should happen when the schedule
says it's supposed to happen.  But schedules are artificial.  Really,
a thing should happen as soon as its inputs are ready, and not before.
Events should be driven by other real events, not by fake events like
clock signals.

And this is why large organisms are more efficient at large jobs, and
small organisms are more efficient at small jobs.  We spend a lot of
our energy coordinating large groups of muscle cells using our nerve cells.
Our individual muscle cells do not take much initiative on their own.
And our nerve cells suck up lots of glucose producing those timing signals.

As open source authors, we need to think more like ants than
like elephants.  We must see even our big projects as a bunch of
cooperating little projects.  We need to get over our tendency to
put software development on a modern 20th century assembly line,
and instead put it into a postmodern 21st century network, where
just-in-time manufacturing is the ideal, and products are shipped
as soon as they're ready to be shipped.  And not before.

Admittedly, open source manufacturing often falls short of that ideal.
The scratch-your-own-itch approach tends to produce results not just-in-time,
but more like not-quite-too-late, and sometimes a little later
than that.  But the results are worth the wait.

Let me put this bluntly.  If we'd done Perl 6 on a schedule, you'd
have it by now.  And it would be crap.  Perl 6 will be ready when
all the inputs are there, and all the event-driven decision circuits
have had a chance to make their decisions.  We're not the least bit
afraid to slip our schedule, because we don't have a schedule.  We
just have a plan.

Speaking of being afraid, that brings us to our next article,

Combating the Terror of Terrorism

In geek terms, this article is about taking the F out of FUD.
There's nothing really wrong with "UD".  Dealing with uncertainty and
doubt is why we were given brains in the first place.  But as Frank
Herbert points out in Dune, "Fear is the mind killer."  When you're
afraid, you're basically insane.  The terrorists know this.  And so
do the marketroids who work for certain large corporations.  So do
their lobbyists.  Now when the lobbyists can instill fear into the
politicians, *that's* something to be afraid of.  I'm afraid of that.

Yeah, "the only thing we have to fear is fear itself."  But don't
forget that a politician said that.

It's true that some corporations are needlessly fearful of open source,
but I think that, as open source advocates, we also give in to fear
far too often.  Fear turns potential friends into actual enemies.
We're all much too quick on the trigger when someone accidentally
pushes our hot buttons.  Some of us even get to like having our hot
buttons pushed so that we have an excuse to lash out, with predictable
results in forums like Slashdot.  This too is a form of insanity.

But accidental hot buttons aside, people who purposefully trade in fear
are the real terrorists, regardless of the scale of their terrorism.
To intentionally destroy the rationality of another human being
is despicable.

Now let me say something very complimentary about Perl Culture.
Two years ago, we were afraid, and therefore insane, because we felt
as though the endless bickering on perl5-porters was going to destroy
our culture.  Fortunately, we managed to get that straightened out,
though in a roundabout way.  It happened like this.  For the Perl 6
effort, we made new mailing lists, with leaders who were authorized
to enforce civility.  That had the expected result of keeping things
civil in the initial brainstorming for Perl 6.  But it also had the
unexpected result that the perl5-porters mailing list also calmed down.
Suddenly people weren't afraid to confront the terroristic tendencies
that we all harbor to some extent or other.  And it resulted in a
new level of mental health for the community as a whole.

I take this as a lesson that open source leaders have a special
responsibility to deal with the fears of their community.  Yesterday
there was an Ask Slashdot in which someone wanted to know how to keep
control of an open-source project that they were thinking about doing.
It struck me as an unnecessarily fearful question in the first place,
but my advice would be, if you want to keep control of an open source
project, you must first of all manage your own fears. Then and only
then will you be in a position to help everyone else manage their
fears.  Only in the absence of such fear can the uncertainty and
doubt be dealt with rationally.  Much though I'd like to at times,
I'm not allowed to prescribe Valium for the Perl community.

I keep coming back to the "community thing" in these talks, but
that's because it's so important.  In the long run, the community's
attitudes will make or break the community itself.  This article
could almost be speaking about the Perl community two years ago:

    Marcelle Layton, a leader in bioterrorism preparedness with the New
    York City Department of Health, notes that social cohesion can be
    promoted by educating the community about potential threats and by
    informing the public as to the nature of the official response.
    Inspiring the populace can also be a great positive influence.
    Political leaders can play a significant role in caring for the
    public's mental health, because a sense of community and social
    cohesion fortifies people against terror's fundamental goal of
    inflicting psychological trauma.  (In fact, a growing body of
    epidemiological literature suggests that social cohesion, or
    "social capital", confers *overall* protection against morbidity
    and mortality.)

    A primary component of social cohesion and morale, probably deeply
    based in evolutionary psychology, is the leadership of a single,
    trusted authority figure.  One of history's foremost examples of the
    power of such social bonding dates to the 1940 Battle of Britain in
    World War II.  Nazi bombings were designed to kill some but
    demoralize all.  While concurrently attempting to fortify a weak air
    defense, Prime Minister Winston Churchill set himself the task of
    strengthening the resolve of his people to endure the psychological
    fallout of the air raids. His inspiring radio addresses, which
    promoted a sense of common purpose, in effect were public mental
    health interventions.

There are other examples, such as Rudi Giuliani.  It's a role that
I've found myself getting into upon occasion.  I really do tend to
think of my talks as "public mental health interventions".

And this relates to our next topic.  You might wonder how I decided
to talk from the table of contents of Scientific American.  I knew
I'd be doing that the moment I saw the final article in the list.
It is entitled:

Saving Dying Languages

No, I don't think Perl is a dying language.  And Parrot isn't
dead yet either.

There is, in fact, a Python script that claims the parrot is dead.
A Monty Python script, that is.  But that's a parrot of a different
color.  In fact, a good case could be made that it's Monty Python
that's dead.  It could even be argued that Monty Python will never
get any better.  How could it get any better, when it started out
perfect?  Any resemblance to languages of the same name are entirely
coincidental.  Really!  Guido's Python is still quite lively.  I'm not
going to say anything bad about Python.  This year.

Anyway, Dan's Parrot is alive and healthy, last I heard.  There's even
a rudimentary Perl 6 parser for it now.  Dan will be talking about
Parrot for most of Friday.

But anyway, back to the article.  The world actually does have a
problem with languages going extinct.  Of the 6-7000 languages in the
world, we could easily lose hundreds of them within a generation,
and half of them in a century.  We're talking real languages here,
not computer languages.  We're essentially talking about the death
of a culture.  It's worse than the library of Alexandria burning down,
because at least we had backup copies of some of those documents.
These languages have no written records, and when they're gone,
there will be no way to reconstruct them.

Interestingly, the article only hints it, but it's an embarrassing
fact to secular linguists that almost all of the language preservation
work up till now has been done by missionaries.  My own interest in
linguistics was sparked for similar reasons by a college friend named
Gary Simons.  Gary went on to work with a group of missionary linguists
called SIL International, and lately he's been working on unifying the
many different databases of linguistic information, much as Lincoln
Stein unified the human genome project.  As it happens, I was also a
member of SIL for a time--that's where I got my training in tagmemics.
I'd tell you what tagmemics is right now, but I don't have time,
and I don't want to spoil Allison Randal's talk.  Allison is yet
another SIL graduate (we are everywhere), and she will be giving a
talk on tagmemics on Thursday.  So this article is closely tied to
the origins of Perl in the first place.

But the article goes on to make some interesting points about how
languages die, and I think I'd like to talk about the dynamics
of that.

A human language dies in several steps.  First, the people speaking
the language come in contact with a larger group of people speaking a
different language, typically a national language.  Second, existing
speakers of the language decide that their language is somehow inferior
to the other language, and become embarrassed by it.  At that point
the other language becomes the "dominant" language.  Third, the
young people pick up on that attitude and learn to speak the dominant
language by preference, neglecting to learn the original language.

The fourth step, of course, is that all the older speakers die off.

You'll note that COBOL has begun to reach stage four.  But the dying
started much earlier than that.

I said that Perl is not a dying language.  But two years ago Perl 5 had
already started dying, because people were starting to see it as a dead-end
language.  It seemed odd at the time, but when we announced Perl 6,
Perl 5 suddenly took on a new life.  We shouldn't have been surprised.
When people have a vision for the future of a language, the current
language doesn't seem inferior any more.  Any language can feel dominant
in the right circumstances.

And now something really amazing is happening.  Instead of Perl dying,
Parrot is becoming a kind a refuge for other endangered languages,
such as BASIC, Forth, and so on.  Because of Perl's TMTOWTDI attitude,
we're not afraid for other languages to succeed along with Perl.
Not even Python, or Ruby, or Scheme.

And that is exactly what this article says we should do.  I can't
think of any better way to end this talk than to read you the last
two paragraphs of the article.

    "Ultimately, the answer to the problem of language extinction
    is multilingualism," Matisoff argues, and many linguists agree.
    "Even uneducated people can learn several languages, as long as
    they start as children," he says.  Indeed, most people in the
    world speak more than one tongue, and in places such as Cameroon
    (279 languages), Papua New Guinea (823) and India (387) it is
    common to speak three or four distinct languages and a dialect
    or two as well.

    "Most Americans and Canadians, to the west of Quebec, have a gut
    reaction that anyone speaking another language in front of them
    is committing an immoral act," Grimes observes.  "You get the same
    reaction in Australia and Russia.  It is no coincidence that these
    are the areas where languages are disappearing the fastest."
    The first step to saving dying languages is to persuade the
    world's majorities to allow the minorities among them to speak
    with their own voices.

I think that the highest goal of the Perl community should be to allow
every programmer to speak with his or her own voice.  There's more than
one way to do it.  You wanna help me save the world?  Let's give every
language an anti-aging pill.  Let's be honest with who we are, and
who we aren't.  Let's be sensitive to ecological issues.  Let's give
the small guy a time and a place to be efficient.  And by all means,
let's discourage the terrorists by taking the F out of FUD.

Thanks for listening, and have a great conference.