Larry's approaching perl6 through the Programming Perl book (the Camel).
He's going chapter by chapter through the Camel, writing documents about
the perl6 equivalent concepts. These missives are known as "Apocalypses",
for reasons best known to Larry. :-)
He's churning through the RFCs, looking through them to deeper issues.
He hopes to emit Apocalypses more-or-less weekly, although some chapters
have fewer RFCs and issues than others.
Enjoy!
Nat
-
Apocalypse 1: The Ugly, the Bad, and the Good
by Larry Wall
Apr. 2, 2001
Table of Contents
o RFC 141: This Is The Last Major Revision
o RFC 28: Perl should stay Perl
o RFC 16: Keep default Perl free of constraints such as warnings
and strict
o RFC 73: All Perl core functions should return objects
o RFC 26: Named operators versus functions
People get scared when they hear the word Apocalypse, but here I mean
it in the good sense: a Revealing. An Apocalypse is supposed to reveal
good news to good people. (And if it also happens to reveal bad news
to bad people, so be it. Just don't be bad.)
What I will be revealing in these columns will be the design of Perl
6. Or more accurately, the beginnings of that design, since the design
process will certainly continue after I've had my initial say in the
matter. I'm not omniscient, rumors to the contrary notwithstanding.
This job of playing God is a little too big for me. Nevertheless,
someone has to do it, so I'll try my best to fake it. And I'll expect
all of you to help me out with the process of creating history. We all
have to do our bit with free will.
"If you look at the history of Perl 6 up to this point, you will see
why this column is subtitled The Ugly, the Bad, and the Good. The RFC
process of last year was ugly, in a good sense. It was a brainstorming
process, and that means it was deliberately ugly-not in the sense of
incivility, since the RFC process was in fact surprisingly civil, but
in the sense that there was little coherent design to the suggestions
in the RFCs. Frankly, the RFCs are all over the map, without actually
covering the map. There are contradictory RFCs, and there are missing
RFCs. Many of the RFCs propose real problems but go off at funny
angles in trying to propose solutions. Many of them patch symptoms
without curing the underlying ailments.
I also discovered Larry's First Law of Language Redesign: Everyone
wants the colon.
That was the Ugly part. The Bad part was that I was supposed to take
these RFCs and produce a coherent design in two weeks. I starting out
thinking I could just classify the RFCs into the good, bad, and ugly
categories, but somehow most of them ended up in the ugly category,
because the good ones typically had something wrong with them, and the
even the bad ones typically indicated a problem that could use some
thought, even if the solution was totally bogus.
It is now five months later, and I've been mulling over coherence the
whole time, for some definition of mulling. Many of you know what
happens when the size of your Perl process exceeds the size of your
physical memory-you start thrashing. Well, that's basically what
happened to me. I couldn't get enough of the problem into my head at
once to make good progress, and I'm not actually very good at
subdividing problems. My forte is synthesis, not analysis. It didn't
help that I had a number of distractions in my life, some of them
self-inflicted, and some of them not. I won't go into all that. Save
it for my unauthorized autobiography.
But now we come to the Good part. (I hope.) After thinking lots and
lots about many of the individual RFCs, and not knowing how to start
thinking about them as a whole, it occurred to me (finally!) that the
proper order to think about things was, more or less, the order of the
chapters in the Camel Book. That is, the Camel Book's order is
designed to minimize forward references in the explanation of Perl, so
considering Perl 6 in roughly the same order will tend to reduce the
number of things that I have to decide before I've decided them.
So I've merrily classified all the RFCs by chapter number, and they
look much more manageable now. (I also restructured my email so that I
can look at a slice of all the messages that ever talked about a
particular RFC, regardless of which mailing list the message was on.
That's also a big help.) I intend to produce one Apocalypse for each
Chapter, so Apocalypse 1 corresponds to Chapter 1: An Overview of
Perl. (Of course, in the book, the Overview is more like a small
tutorial, not really a complete
