Allison Randal is speaking about how Perl 6 is being shaped. I expect
this to be a good talk, though I regret missing about four others going on
right now, too: “Subversion, WebDAV, and Apache HTTP Server 2.0” (Ozette
will tell me about it); “DIY-IT: How Open Source is Turning IT Into a
Do-It-Yourself Marketplace” (Ricardo said he’d be there); “Ruby for Perl
Programmers” (Craig is attending); and “Automated Testing of Large Projects
with Perl” (Usha’s got it covered). This is probably the richest 45 minutes
of the whole conference; couldn’t they have spread these particular talks out more?
Every language is unique, and this talk will help understand not only
Perl 6, but the how all languages are shaped by their design philosophies.
Simplicity. Simple is better, easier (to teach, to learn, to remember,
to use, to read, to parse). Not all problems are simple, though (the
simplest language would be the empty set, but that doesn’t do much for you).
Choose your complexity. You’ll have to address some complexity, so decide
where and how to do (e.g., make the surface simple, supported by a very
complex processor hidden from the user). Nice example with operators. You
could have a lot of operators (like APL) that could make the language look
like random line noise, or almost no operators (add(4, multiply(3,7))).
Find a middle ground.
Reuse. Repeat structures for consistency. For example, don’t use
curly braces to delimit a loop block, but “then…end” to delimit an if
statement.
Distinction. We don’t see small differences. Suppose “cats” were
named “togs”, not distinct enough from “dogs”.
Freedom. Programmer freedom: programmers should be able to choose
how they want to express their code. So Perl has customs and conventions,
rather than enforcing just one way to do it. “Perl isn’t a training bike.”
Adaptability. Change is natural as we adjust to needs and try to
stay relevant. “Dead languages don’t change.” But that doesn’t necessarily
mean that a language that doesn’t change is dead (it might just be perfect).
So plan for change. This leads to modifiable parsing, and removing the
barriers between core and user-defined functionality.
Prominence. “All syntax is not created equal.” Use things that
stick out to your advantage. Look at
if ($blue) {print "True Blue.";}
versus
print "True Blue." if $blue;
They do the same thing, but the first emphasizes that the condition is what’s important, the second
emphasizes the action. Which is right depends on circumstances.
End Weight. Put the long bits at the end to be easier to read.
DWIM. “Do what I mean.” This has always been important in Perl.
But DWIM isn’t always DWYM (do what you mean). Ada and C programmers expect
different things. So Perl 6 targets Perl programmers, and tries to do what
they mean. It also generally targets English speakers (but not
necessarily natives; ordinal modifiers don’t have to be just 1st, 2nd, 3rd,
but also 1th, 2th, 3th).
Borrowing. For example, the word “camouflage” was borrowed from
French by English. We changed the spelling and the pronunciation, but it’s
still basically the same word. “There’s no shame in adopting features from
other languages.” Borrowing expresses respect for the other language, and
Perl acknowledges when it does this. However, features must adapt to be
successfully adopted.
Perl Should Stay Perl. But what makes it Perl? Not the syntax;
that’s going to change. Not the exact features. But it will stay true to
the designer’s purpose. “Make easy things easy, and hard things possible.”
“Get your job done without getting in your way.” Perl 6 will be familiar to
Perl programmers. And Perl 5 will be mechanically translatable from Perl 5,
which will be important in the short term.
Long-Term Usability. We want Perl 6 to be useful for at least the
next 20 years. That means don’t worry about fads or cute tricks. Perl 6
won’t be perfect, just another step in that direction.
Summary. A recap of what we’ve heard, plus that Perl 6 has to be
“more Perl” than even Perl 5 is.
Charles Engelke's Blog 