Transcription of Larry's talk

[I have to wake up in about 4 hours, so this is all you get, the
first 1h26m of the talk, loosely transcribed and not proofread]

As I look around here, I see a lot of yougn faces.  Almost too young.
I like you.  I always planned to stay young all my life.  I've always
been blessed with a face that's younger than my age, so I've tried to
always adopt a young attitude to go with my face.

You can fool some of the people all of the time, but you can't fool
Mom.  I think she knows that I'm just a late bloomer. (speaking of
procrastination)  I'm late for a lot of things, not just blooming.

For instance, I only started writing this talk yesterday.  Another one
of these Just In Time talks.  I'll probably finish it sometime
tomorrow.  Lateness is one of my specialties.  Someday I'll be dead,
and when you refer to me as "the Late Larry Wall", people will think
you were joking.

Speaking of my long-lost youth, I remember sometime way back during
the Kennedy administraion, my gradeschool teacher asked us all to
calculate how old we'd be in the year 2000.  I got the unfathomable
answer of 46.  I could imagine being 10, maybe. But 46 is a lot closer
towards infinity!

Anyway, I couldn't imagine being 46.  Now I can.  Aas of last month,
I'm in my late 40s.  Whoopee!  Does this mean I can schedule my
mid-life crisis soon?

Besides my birthday, I recently noticed several things that tell me
I'm not so young any more.  The first thing I noticed is that I took
my first child, Heidi, off to college.  Believe me,even if you don't
notice your kids while you still have them, you'll definitely notice
them when they go away.

The second thing I noticed is ... I forget life.

The third thing I noticed is that I want to start reminiscing about my
youth.  Old people really only have three things to say: how good it
was back then, how bad it is now, and (if you're lucky) how much worse
it will be in the future.

So, I'd like to talk about how good it was back then, how bad it is
now, and how much worse it will be in the future.

Actually, I just said that to be funny.  I really do think things are
getting better, and the getting betterness is what I would like to
talk about.

The name of this talk (for the moment, I might change it) is: Camelot
#6, The Once and Future Perl.

I going to do a little bit like Ken did last night, and take you
through how bad it used to be and how good it's getting, and on to the
future.  A chronological outline is a great way to go.  Some of you
may recognise some of these slides.  In fact, these are probably about
10 years old, some of them.  I put them in more for historical value.
If you look closely, you can see gritchineses--that's an overhead
transparency that I scanned.  So this is the real original.

Way back in the dawn of time, this is what Unix looked like.  Either you
programmed in C, or you programmed in shell.  Of course, those were
two different realms, and it was sort of one or the other.  We had
this dichotomy of our thinking, that you had to do one or the other.

How it really was back then, one day it opened up to me, these were
not opposites but think of an oyster shell opening up here.  Instead
of opposites, they were two different dimensions in space that you
could graph things like this.  You could consider sed and awk to be
sort of warts on the shell.

For those of you at the back who can't read this, the left hand axis
(what C is good at) is called "manipulexity" and the horizontal
attitude is called "whipuptitude".  

With that realization I realized that there was a big gray area out
there.  In biological terms, that's an ecological niche.  So I decided
to fill it.

Perl got hatched, and that's kinda why it's egg-shaped there.  From
the beginning it was designed to grow into that space.  Perl was
always designed to be an evolving language.

The reason I'm telling you some of this stuff is that, as some of you
know, we've announced Perl 6, and I'm going to be talking about that
later.  And one of the very very high level goals of perl6 is to keep
Perl capable of evolving, and Perl 5 was running into some limits and
we're going to figure out how to get around those limits.

So it appears that there are these two axes of C and Perl.  And there
could be other dimensions: the Python dimension, the Java dimenson.
But you don't want to think of either/or.  It's really easy for people
to get (especially computer scientists) to get locked into this
either-or thing.  Either I use the GPL or I don't.  Well, why not use
the GPL *and* some other license?  Is that right, Ken?  It wasn't long
after that that I invented dual licensing, and I think that actually
works pretty well.

So there are lots of ways in which we try to avoid falling into the
either-or trap.  Perl got its philosophical inputs from four different
areas, not just from computer science (obviously).  From this diagram,
you can see that computer scientists tend to not like things to be
art.  They prefer things to be scientific.  So computer science is
sort of the opposite of art, maybe, but I don't know that linguistics
isn't the opposite of common sense.  Maybe it is--I've been trying to
learn Japanese lately ....  People say that Perl is hard to learn.
Nu-uh!  *Japanese* is hard to learn!

More specifically, here are some points that Perl took from those four
languages I listed earlier.  The bold things are things that I
borrowed, and the non-bold things are things that I specifically left
behind.  People often think that Perl is hodge-podge, everything
including the kitchen sink, but I actually left out a few of the
kitchen sinks along the way.  Still, a few have snuck in and that's
what I'll talk about later.

The question is, when you combine things like this, is it good or is
it bad?  Well, that's a personal judgement.   I have my opinion on
it.  I have a lot of opinions, actually, and some of them you'll
notice in the design of Perl.  I don't like dangling syntax, and I
think that ordinary people like me hate abstractions.  Hmm, that sorta
assumes that I'm ordinary.  I do think of myself as ordinary.
Ordinary-weird, but ordinary.

And I believe contradictory things.  I believe that C is wonderful and
I believe C is awful.  And that AWK is neither.

I think that language is an amoral medium, by which I mean that
language itself is like an artistic medium, like paint.  You don't
have pretty paints and ugly paints, it's after you arrange them on a
canvas that they get pretty or ugly.  Similarly, language is something
you can use.  You can write beautiful poems, or ugly flames.  Or
beautiful flames.

I think ugly can be beautiful, and that beautiful can get ugly real
quick.  I think in particular of LISP, which is the most beautiful
language in the world, and every program in lisp is real ugly.

I think visual metaphor is more than just poetry, so I think things
that are different oughta look different.

This applies to language designers: you have to simultaneously not
care what other people think, and care what other people think.

And I think that God has free will, which is why he designed us to be
creative.  Which is why programmers prefer to have more than one way to
do it--they have choices, and that's what makes programming fun.

Now lots of people design computer languages, and fall into all sorts
of traps:

"Now, we have to start over from scratch".  That's almost any academic
language, which throws out all the existing art and says "we're going
to make people think entirely different from how they did before".

"If we put in English phrases, that makes it readable".  That's
COBOL.  

"Simple languages produce simple solutions".  There are lots of simple
languages, but simple languages produce complicated solutions because
you have to be verbose.

"If I wanted it fast, I'd write it in C".  That was the original
reasoning behind making AWK run so slow.

"I thought of a way to do it so it must be right".  That's a very
common trap: people just implement the first thing they think of.

"This is a very high level language--who cares about bits?"  Again,
like AWK.

"You can do anything you want with AND gates".  That's Turing
machines, I guess, or something like that.

"Users care about elegance."  No, they care about getting their job
done.  For some reason lots of languages that come out of Europe have
this thing about elegance that I don't quite get.  Obviously.

"The specification is good enough".  That's ADA.

"Abstraction = usability".  That's Lisp or Scheme, or maybe UML.

"The core should be as small as possible."  That's FORTH.

"Let's make this easy for the computer."  That's assembly language.

"Most programs are designed top down."  That's Pascal.

"Text processing doesn't matter."  Fortran.

"People should never have been given free will."  Lots of languages.

I think that what actually makes a language useful is not the theory
involved in it.  Theory is good, but if you drive a particular theory
into the ground, that just drives people away.

So a language's practicality is inversely proportional to the number
of theoretical axes the language has to grind.  I don't mind theory, I
just don't like theoretical axes.

Now there's an interesting chart that I go back to look at again and
again, to remind me that programming is not a sequential activity.
We already saw the fallacy of either/or thinking.  Another fallacy we
often fall into is sequential thinking.

Some of you may have heard of the waterfall chart, which talks about
doing specification, then you go to the design, then coding, then
testing.  But really it's more of a chaotic strange attractor, where
all of these things are going on simultaneously.  You know,
"readyfireaim" is how we program.  There are some methodologies that
advocate testing before doing coding and then doing the design, and I
think that's one of the eXtreme Programming tenets.

Right now as I'm giving this talk, Camelot #6, it's about perl 6, I
think that perls 1 through 5 were prototypes for Perl 6.  And you plan
to throw away the prototypes ...

Now Unix has an interesting history (audience laughter).  I think this
down here is the little dance being done by BSD and Linux.

The C family tree kinda looks like this (more laughter).  We had K&R
C to begin with, then we had gazillion different types of C, then we
had ANSI C, and then ... something happened.  And then something else
happened.  (more laughter)  And then something else happened, and this
is the Microsoft view of reality (yet more laughter).

Here's the Perl family tree.  Actually, this is slightly disingenuous,
because there was a little branch off to the side when Activestate
first ported Perl to the Windows platform, but we made a big effort
and pulled it back together.  So the line got a little wider there and
got narrower again.  The nice thing about open source is that you can
pull things back together again if you really need to.

The slide has said "under construction" down there from the beginning,
and it still says that.

Here's the other way of looking at the Perl family tree.  Needless to
say this is notional.

Now Perl's design, from the beginning, since my background is both in
linguistics and computer science, has a lot of linguistics
notions.  Not on the level of COBOL, where it just looks like English,
but on a deeper level.

A natural language you learn it once, and you use it many times.  So
you should optimize for expressiveness, not for learnability.  I think
somebody had told that to the Japanese before they designed their
language, and I wish their language was a little easier to learn.

Another thing about language is that you learn as you go, and many
acceptable levels of competence are ... acceptable.  That means we
don't expect a 5 year old to speak with the same level of competence
as a 50 year old, or a 46-year old.  And it's perfeclty okay for a kid
to use kid-talk and a baby to use baby-talk.  Contrast that with your
typical C++ shop where if you don't know the whole language and
program in a subset of C++, you get left out of the office.

To me it should be acceptable to program in Perl subsets.  If you want
to program in the subset that looks like awk, sed, or C, that's fine.
Or the subset that looks like Python ... (slow laughter)  Some of you
are awake.

There are more points here that I'm not going to go through.  The
slides are on my website if you're interested.  There are many more
things that are based on how we use natural language, and I don't want
to lose that as we go forward and evolve Perl.

So for more recent history, meaning 5 years ago plus or minus, when
Perl 5 first came out this was what we announced as the goals of Perl
5.  Perl 5 did improve in all of these areas.  When I look back at it
now, in all of these areas it can continue to improve.  So most of the
rest of this talk is going to be about that.

Now Perl 5 had some constraints on its design.  First of all was the
need for backward compatibility.  We have deprecated a few things along
the way, but most of them were what I call 'eternally deprecated':
"don't do that, but it still works".  So most of your Perl 1 scripts
(I'm sure you've all written Perl 1 scripts right?  Some of you
weren't born then!) still work in Perl 5 for the most part.  You might
get some warnings, but we had to keep the backward compatibility at
that point.

Of course another constraint on the design of perl5 was my own
idiocy.  That was the last time I designed the language by myself, so
I was limited by my own imagination.  And the cultural model of Perl 5
worked for Perl 5, but it had bottle necks in it, in terms of how we
developed it.  Having one person in charge of all the integration
tends to be a bottleneck.  Yes, you know that.

Of course, there was ignorance of the future.  And there were some
places where I was ignorant of the present and the past, but we'll let
that go.  And a lack of round tuits.

And another way in which Perl 5 was constrained was that in dealing
with all the other things there, the core was quite complex.  You like
it when Perl rips through a file really quickly, doing pattern
matching or whatever it's doing, but a lot of that is because of the
internals doing optimizations and the like.  So it's a little hard to
get in there and actually change it, particularly if you're starting
out.  There aren't that many people that can do it, and that limits
how much Perl 5 can evolve.

And then of course there's the issue of complacency.  You can easily
sit there and say "well, it's good enough".  That was sort of starting
to happen.  Between version 5.005 and 5.6, it took about two years.
There were many reasons for that, some of them I mentioned on the last
slide.  A personal reason is that I was busy writing the new Camel
book, Camel 3 as we call it.  I was busy with the Perl Whirl cruise
(you know, there's a Linux Lunacy cruise coming up.  I highly
recommend it.  It's cheaper than you think, because the cruise lines
are overbuilt so they're trying to get people to go on all these
cruises.  I was expecting the Perl cruise to be all these old fogeys
pretendign to be Perl programmers, but it was really much of the same
demographics as you.  But I spent a good part of it proofing the Camel
book in my cabin.  You look up every five minutes and "there's a
beautiful view, oh nice", then go back to proofing).

After that I was busy getting ready for Yet Another Perl Conference
19100 (that's what they called it), and after that getting ready for
the Perl Conference 4.0.

As much as a year before the Perl conference, we'd said to ourselves
"you know, we should have ourselves a constitutional convention and
figure out how to reorganize the community to be more effective".  And
yeah, that's a great idea, but finally this last summer Chip
Salzenberg said "let's have one of those meetings".

We started having one, and an interesting thing happened.  We spent
the first hour gabbing about all sorts of political and organizational
issues of a fairly boring and mundane nature.  Partway through, Jon
Orwant comes in, and stands there for a few minutes listening, and
then he very calmly walks over to the coffee service table in the
corner, and there were about 20 of us in the room, and he picks up a
coffee mug and throws it against the other wall and he keeps throwing
coffee mugs against the other wall, and he says "we are fucked unless
we can come up with something that will excite the community, because
everyone's getting bored and going off and doing other things".

And he was right.  His motivation was, perhaps, to make bigger Perl
conferences, or he likes Perl doing well, or something like that.  But
in actual fact he was right, so that sort of galvanized the meeting.
He said "I don't care what you do, but you gotta do something big."
And then he went away.

Don't misunderstand me.  This was the most perfectly planned tantrum
you have ever seen.  If any of you know Jon, he likes control.  This
was a perfectly controlled tantrum.  It was amazing to see.  I was
thinking, "should I get up and throw mugs too?"

Anyway, so we started talking after that and the idea popped up that
maybe we oughta rewrite Perl.  The idea that occurred to me then was
that we had some new technology: Perl has a decompiler now.  You can
take a Perl 5 script and compile it down to the bytecode, and take
that and compile it back to Perl 5 code.  And if you can do that, why
not compile it back to Perl 6 code?

So with that realization, we are now free to actually do a major
redesign.  What can we do that we would have done differently if we
had known better, 14 years ago?

So later that day we also had an open meeting of the perl porters,
with about 50 people there, and we started handing out tasks about how
we would do the redesign.  And the next day in my keynote I announced
that we were rewriting Perl.  I only got about three hours of sleep that
night because I was rewriting my speech.  That would have been okay
except that I'd only had three hours the night before.  So if you
listen to that audio on the net, you'll hear that I sound very spaced
out.  More than usual.

So anyway, Perl 6.  As I was flying here on Delta Airlines, the
monitor was showing all sorts of happy sayings.

"If you can dream it, you can do it"--Walt Disney.  Now this is
actually false (massive laughter).  I think Walt was confused between
necessary and sufficient conditions.  If you don't dream it, you can't
do it, that is certainly accurate.

So we've been dreaming.  Everything's fair game. We've been thinking
how to reinvent the lexer, the parser, the interpreter, the code
generators, the internal APIs, the external APIs, the language itself,
and the culture surrounding it.  And interestingly, the first thing we
started reinventing was the culture.

Here are some mailing lists that have spring up since August 1, and a
rough idea of the number of messages that have been posted to each of
those.  These correspond to various working groups.  We have a working
group model where there's an official person in charge of each working
group, and there's a charter, and there's a sunset law where at a
certain date we will shut ourselves down unless we can justify
continuing our existence.  So we're doing something very different
from the perl5-porters mailing list that has gone on forever, and
isn't much about porting any more.

So there's much more sense of responsibility, and people are holding
themselves accountable.  And the amount of raw flamage has been less
than in the old days.  So so far so good on the culture, and we'll
continue evolving the culture.

As you can see, some of these working groups look very general.
perl6-language obviously has a lot of activity and will probably go
on for a long time.  Some of these were working groups set up to
discuss one little issue, one RFC, and sometimes the timing was a
little off.  If you look at the perl6-language-unlink one, they
created the mailing list just as the discussion was dying, so it never
got anything on it.  But this tells you of some of the ways we're
breaking down the culture here.

In particular, there's an official way of announcing RFCs.  We're
splitting the language issues from the internals issues.  Build issues
are being covered.  QA.  Notice that that's perl-qa -- we're hoping
that we can back-apply some of the QA things we develop in perl6 back
to perl5.

Now one thing I want to make clear about these perl6 activity is that
we're not abandoning perl5 any time soon.  We don't know how long this
perl6 will take.  There are still some people using perl4 out there.

Now perl6 has a different set of constraints.  Hoepfully these are
more liberal constraints than perl5 had.  It's still the case that
Larry needs to understand perl6.  For some strange reason, even though
they split off into all these working groups, and they have a language
working group, they appointed me Chief Language Designer.  So I said
"okay".

So I need to make sure that I grok everything that's out there.  That
doesn't mean that I had to come up with it in the first place.  That
doesn't mean that I have to understand how to do it, only how it's
going to interact with other things.

Other constraints that we were putting on the design: you can propose
a new feature, but if it's not something that people really need,
we're not going to put it in.  The underlying philosophy of Perl is
to serve, and if it doesn't serve our needs then what good is it?

Can we implement it efficiently and robustly?

And a biggie here--does it preclude translation from perl5?  We need
to be able to have a migration path from perl5 to perl6, so if you
distort the semantics too violently then it becomes too difficult to
translate.  So perl6 will bear a close resemblance in some ways to
perl5.

Does the utility of the change grow faster than the complexity?  And
does the size of the executable grow slower than Moore's law?  These
things always grow over time, but is the computer getting faster
faster?

And we have to take the time to maintain perl5, and we also have to
make sure that we take the time to design it right.  There's never
time to do it right, but there's always time to do it over, but we
want to do it over first.  Or something like that.

The RFC process.  We call them RFCs, and they really are Requests For
Comments, they're not standards!  There are over 360 standards,
they're written in Plain Old Document format, and they must be
well-formed to be acceptable to be announced and posted on
dev.perl.org.  They're subject to revision, retraction, rethink.

The first one came out right after the perl conference, and we had it
open for brainstorm essentially until the end of last month.  And
that's when I got a snapshot of it.  The theory was that I would read
all these RFCs in two weeks and come up with a language design.
Riiiight.  I've read the abstracts of all of them but the last 50.  If
I run out of things to say here, I'll read the last 50 and take a
master class approach here.


These are things that will be in Perl 6, for some definition or other,
but they are somewhat nebulous.  Perl needs to support higher level
programming, and I'll go into some of these as we go along, and it
must support lower level programming.  It'd be nice if it supported
more paradigms, yes the p-word.  And we really want to avoid the
equivalent of DLL hell.  It's getting harder and harder with all these
modules out on CPAN, with different versions of them, to keep them all
straight.  There are ways of handling these sorts of things.

"Perl must support absolute flexibility".  There's actually an RFC
that says "Perl 6 will be the last version of Perl".  By which they
mean, "we'll do it good enough that there'll be no need for a Perl 7."
In fact, they say that the version number will asymptotically approach
pi*2.  That's what the RFC says, I haven't said whether it's right or
not.

It needs to have a mean and lean core, and we'll talk about that.
Perl must not surprise people unnecessarily, and there are still ways
in which Perl surprises people and we can reduce some of that.  It
needs to be as simple as possible, but no simpler.  It needs to map
well onto your problem.  The better your solution space maps onto your
problem space, the more compact your solution will be.  And Perl must
remain Perl.  There's an RFC that says that too.

There's a lot of things we can simplify, going from perl5 into perl6.
If the core is going to be lean and mean, that implies that a lot of
stuff are going to move out of the core.  Non-critical builtins,
sockets, operating system stuff, and so on, will be moved out to
modules.  Now they might be autoloaded, so they look like they're in
the core, but there's no reason they have to be there to begin with.
So we can discount those in the internals design, provided of course
that calling out to those modules is efficient.  So that's another
goal.

All variables will be usable as objects.  There are ways in which you
would like to be able to treat arrays and hashes and scalars as
objects, so for instance (and this comes back to the category of not
surprising people) people expect length() to work on arrays.  That's
because they're thinking of the array as an object, not as a list in
scalar context.  So probably length() is goign to become a method on
the array object.  So the translator for perl5 will actually have to
translate the mistake of saying length(@array)!

In any event, all the variables are actually objects internally.  And
rather than having this funny conditional code like perl5 does,
everything will be run off vtables as C++ does.  That does not
necessarily imply thtat we are writing it in C++, probably not, but
that's all implementation.  That will be very efficient and it will
allow alternate implemenations to be swapped in and out very quickly,
loaded as modules.

Now many of the strange global variables that you know and love dearly
will be lexically scoped.  That will simplify things like
multithreading.  Filehandles become objects using object-oriented
notation, meaning we've decided that they'll be regular scalar
variables instead of bare filehandles as they are now.  This
simplifies a whole bunch of things, one of those things is the parsing
rules for indirect objects.  We can probably simplify the parsing
rules in other places as well, disambiguation rules, and might even go
pretty wild there in terms of how you specify a slice--it might be
entirely different.  As long as we can translate it!

We plan to unconfuse homonyms, like the different types of do() and the
different types of eval().  For example eval BLOCK will probably
become try BLOCK as that's how other languages are going these days,
and that's what eval BLOCK means.  So we may disambiguate that way.

Typeglobs we would very much like to go away.  XS we would dearly
*love* to go away.  And I think we can do that, if we can Perl a
low-enough level language to have you specify the interfaces.

I had this realization a few years ago when I wrote this thing called
JPL, Java-Perl Lingo.  You link Java and Perl and pass execution back
and forward between them.  I realize dthat Java had sufficient
information to write all the glue to call back and forth between Java
and Perl, and there was no need to have a glue language.  I thought
"that's cool, I wish Perl could do that".

So part of the design of Perl will be that you can specify enough type
information in your function and method signatures to be able to do
that.  To be able to produce that glue automatically.

We're going to be standardizing the way that objects are set up.  Not
that we're going to be undoing all the flexibility that you have right
now, but you'll have some standard ways that will be easier and more
efficient.

Perl 5 by design made it easy to use objects, but not easy to use
object classes.  We'd like to make it easy to write object classes.

It's becoming obvious that we need a real garbage collector, either
one of our own or we need to be able to relate to one that is
supplied.  For example if we compile Perl down to the C# virtual 
machine, it provides its own garbage collector.

Exception handlign becomes completely object-oriented.   You can still
pretend like it's string-oriented.  If you die with a string, you can
still treat it like an object.  This gives you many benefits.

You'll have easier ways to interpolate expressions in strings.  We
might even think, and I've thought about this a lot as you can tell by
all the questions on the end, about simplifying the precedence
levels.  And the translator can handle that, if it knows about the
precedence levels in the different languages.  So we might be able
to do that.

So the question is, with all this simplification going on, how much
can we get back out?  Well, I don't know.  We can handle a certain
amount of complexity so long as we can hide it from people.  As long
as you're not exposed to the part of the complexity that you're not
interested in at the moment, that's a virtue.  It goes back to
programming in a subset of Perl: the standard Perl has ta certain
level of complexity, and if you put a declaration at the top then you
get the full level of complexity, but you don't *have* to worry about
it.  So there are things you can do with the complexity.

So now let's look at the RFCs.  As I said, there are lots of them.  As
I said, I've sorted out about the first 20 of these, and I've read all
but about the last 50 of them.  There are some very interesting things
here, and I'm sad I don't have time to read them all to you.

To let you know the way I'm going through these is.  Well, let me just
show you one as a for instance here.  Here's one that probably won't
be done.  Let's talk about my classification scheme.  There are the
first 361, except for the first 20 which have already disappeared into
subdirectories.

Now you can't read it, but that one says "GOOD", that one says "BAD",
and that one says "UGLY".  So I really am sorting them into the good,
the bad, and the ugly.  There's also a culture, and other things I
don't want to deal with: culture, internals, retracted, metasyntax.

If you look down into the GOOD directory here, I'm not just
classifying them into GOOD, but I'm also giving them grades.  Not
because I want to flunk them, but because I want to sort them in
order.  The two grades I'm giving them, the first one is "is this a
real problem that we need to deal with", adn the second grade is "how
well is the solution specified".  And a lot of these are "I don't know
how to solve this".  This shouldn't be taken to mean I'm castigating
them for brainstorming, but it means I can see them in order.

Yes, it would be great to have higher-resolution time values.  I think
they should be floating point.  Some of these I've gone through and
put notes up to myself: should we modify open() to support objects and
extensibility?  Yes.  I think that open() should return a filehandle
object rather than take a filehandle as a first argument.

Rename the local operator?  Yeah, I think we ought to do that.  It
confuses people when we call it local().  The problem is, of course,
that this is not a perfect solution--they haven't come up with the
right name here: savetmp, tmpsvae, scratchpad, etc.  The consideration
for me is how it's used grammatically.  It'll often be used with an
our() declaration.  It depends on whether it should come before or
after the our() keyword.  If it came after, you'd say "our temporary
$foo", but if it came before, you'd say "temporarily our $foo".

Yes, we'll reorganize all these funny variables.  Rather than put them
into other globals, we'll make it object-oriented as far as possible.

Here's one that is rathed "BF": pretty good problem, rather lousy
solution.  There should be a way to tailor error messages to different
languages.  We'll have to do that for localization anyway, so fine.

Here are some from the BAD directory.  (reads from one) ... and they
want us to solve the halting problem.  No.

Highlander variable types.  This is an interesting one.  The idea is
that an array is really just a funny name for a reference in the
corresopnding scalar.  It makes for some interesting ramifications,
but I think that it would probably be more confusing in the long run.

Multiline comments in Perl.  I'm sorry, I was brainwashed by the Ada
rationale.  Ada has comments to the end of the line and I think that
if your editor can't put a row of sharps down the left, then you need
a better editor.

And so on.

Ugly things are ones that sort-of are good ideas but maybe we need to
think about them.  Yeah, we need to talk a lot about threads.  Immediate
subroutines, yes.  We need ways of having subroutines that are
evaluated at compiletime, but this mechanism probably isn't it.  Lexical
variables made default.  Uh, no.

Keep default Perl free of constraints such as warnings and strict.
Yeah, I can argue this one both ways too.  Overloadable logic
operators.  This has ramifications on a semantic level because at
least currently the Perl internals don't distinguish between these
funny C-like && and || and the higher precedence if(), unless() and so
on.  These compile down to the same thing, and it would be strange to
make some of them behave one way and others the other.  We might allow
it if you declare that you want it this way.

Anyway, that's kinda how I've been going through it.  They're great
fun, you should read through them if you want to be enteratined.
They're all over the map.  Some of them contradict others.  There's no
way we're going to implement them all, because they are
self-contradictory.

In fact, some people have written their own contradictory RFCs.
"We'll do it this way!"   "No, we'll do it this way!"  Yes, I was
going to point out Brad here.  Let's see: "Artistic License must be
changed" fair enough.  "Perl6 License must be a bugfix of Perl5's
License".  "Perl6's Artistic License should be GPL 2.0", which is a
complete change from the old Artistic License.  I haven't actually
given this one too much thought yet, so I can't tell you whether I
approve or not.

A big category in my mind is "things I don't want to think about yet"
and I'm deferring this one.  In fact, licensing is probably something
we can defer for a while, at least until we start publishing alphas.

Perl as a low-level language.  Polymorphism is your enemy if your'e
trying to do low-level programming.  If you want to get early
compile-time binding as soon as possible, you want the copiler to spit
out very efficient code, so you write your loop to declare i as an
int, then by golly you want your compiler to spit out very efficient C
code.  "num" is a number, "str" is a string.  For some reason they're
all coming out to three letters.  You'll be able to get nice
declarations like this:

  my num $pi :const = 3;

And similarly if you have homogenous arrays or hashes, you'd like to
be able to declare the type of all the elements and have compact
storage.  And this will be hugely more efficient than the way arrrays
and hashes are currently stored.  Furthermore you specify not only
what the types are and how they're stored, but give hints to the
compiler like "I'm only going to use these four bits so if you want to
pack them in tight, go ahead".

If you want to have mathematically compact arrays, multidimensional,
then we'll have some way of declaring those.  There's a whole series
of RFCs of what the mathematicians want out of Perl, if we make them
declare at the top "use MathematicallyFunnyArrays" or something like
that.

Non-homogenous arrays are going to be done primarily through the
obuject interface.  I'd like to borrow the idea of unsafe code from
C#, where you can go in and do things with low-level pointers, so long
as you're careful.

By way of contrast, if Perl's going to become more a high-level
language then polymorphism is your friend.  You want to delay your
binding as long as possible as to what implements what.  Perl has
always been in the business of allowing, but not requiring,
abstraction.  We'd like to put in more support for functional
programming, for logic programming, and for what are called little
languages.

The folks at Bell Labs invented this notion, soon after they invented
YACC.  "Cool, YACC lets you make a grammar for your own language".  So
all these itty bitty languages sprang up that were for their own
purpose.  So each time you wrote a new program, you wrote your own
language for your program.  This was cool except that you had to learn
the new language each time, and it was always different.  We'd like to
explore the notion of using a big language as a little language.

If it's okay to program in a Perl subset, and you define a subset that
looks like a little language, then how do you get around paying the
price of the generality of the big language?  We have ways of thinking
about that.

(stopped at 1:26)

• Transcription of Larry's talk by Nathan Torkington
• RE: Transcription of Larry's talk by David Grove
• Re: Transcription of Larry's talk by John Porter
• Re: Transcription of Larry's talk by J. David Blackstone
• Re: Transcription of Larry's talk by John Porter
• Re: Transcription of Larry's talk by Philip Newton
• Re: Transcription of Larry's talk by Dan Sugalski
• Re: Transcription of Larry's talk by Philip Newton
• Re: Transcription of Larry's talk by Larry Wall
• Re: Transcription of Larry's talk by Nathan Torkington
• Re: Transcription of Larry's talk by Larry Wall
• Re: Transcription of Larry's talk by Steve Fink
• compile-time taint checking and the halting problem by David L. Nicol
• Re: compile-time taint checking and the halting problem by Larry Wall
• Re: compile-time taint checking and the halting problem by Steve Fink
• Re: compile-time taint checking and the halting problem by Dan Sugalski
• Re: Transcription of Larry's talk by Simon Cozens
• Re: Transcription of Larry's talk by Larry Wall
• Re: Transcription of Larry's talk by Philip Newton
• Re: Transcription of Larry's talk by Dan Sugalski
• Re: Transcription of Larry's talk by Adam Turoff
• Re: Transcription of Larry's talk by Philip Newton
• Re: Transcription of Larry's talk by Bart Lateur
• Re: Transcription of Larry's talk by Simon Cozens
• Re: Transcription of Larry's talk by John Porter
• Re: Transcription of Larry's talk by Simon Cozens
• Re: Transcription of Larry's talk by Dan Sugalski
• Re: Transcription of Larry's talk by Nicholas Clark
• Re: Transcription of Larry's talk by Philip Newton
• Re: Transcription of Larry's talk by Nathan Torkington
• Re: Transcription of Larry's talk by Jarkko Hietaniemi
• Re: Transcription of Larry's talk by Larry Wall
• Re: Transcription of Larry's talk by Bart Lateur
• Re: Transcription of Larry's talk by Peter Scott
• Re: Transcription of Larry's talk by merlyn
• Re: Transcription of Larry's talk by John Porter
• Re: Transcription of Larry's talk by Piers Cawley