Why am I writing this Guide?
Because someone has to. :-)
More directly: I am not on the design team, so I don't have any insight or deep understanding of the perl6 development process. I do, however, have just shy of 8 years of Perl5 experience, consisting primarily of consulting, training & tutoring, etc. (See this for the big version.) During that time, one of my primary roles has been training people who start out not knowing the first thing about perl5, and turning them into top-notch Perl5 programmers. So I know how to train people, and I know how to break complex ideas apart into smaller ones, and I know how to write. Not spell, mind you... but write, yes.
Why is Perl my "home language"?
My initial background was in low-level code production. Assembler (various), C, C++. (I have working knowledge of many of the "academic" languages as well.) Until quite recently, I would still have stated that my "home language" was C/C++, though I have been programming most heavily in Perl ever since the Perl4-to-Perl5 switch, and in C/C++ only when I have to.
I moved to Perl because Perl5 has something most other languages don't. Actually, it has two somethings:
- It has a rich enough set of operators and constructs to allow 'basic' recipes to be more simply expressed than in most other languages. There are many things -- mostly dealing with lists, hashes, and complex structures based on them -- that are one-liners in Perl5, but horribly painful in most other mainstream languages.
- It is decidedly laid-back about enforcing particular modalities and methods for solving problems. Many other languages attempt to be very strict in enforcing how "object orientedness" takes place, or how event handling is done, etc. Perl5 is based more on the general philosophy of "make it work, and make it easy for the programmer."
Perl5 is a language, therefore, that is less academic and more goal-oriented. You don't have to tweak your problem to fit the solution the language attempts to enforce upon you. You just extend the language, and away you go. ;-)
However, Perl5 has some basic issues that, several years ago, began to convince me that I would soon have to migrate our own commercial (web-based) applications to other languages, and begin using Perl5 less.
First, because Perl5 has begun to suffer from speed issues. Not horribly, but perceptibly. (And untyped languages simply have speed issues, compared to more strict ones.)
Second, integration with routines written in other, more low-level languages can be quite painful, meaning that those speed drains can be difficult to patch. XS is not something you want to deal with very often.
Third, most applications we construct are too complex not be be OO-based, but Perl5 imposes rather significant speed penalties when using OO techniques. That's a showstopper.
Fourth, the same richness that gives Perl5 its concise syntax and one-line solutions can make it impenetrable to newcomers. I've taught many people, many with no previous programming experience, how to program (well!) in Perl5. I don't think it's a confusing syntax, but my own experience shows, inarguably, that other people often do.
Fifth, because other languages slowly are gaining the capabilities that I relied on Perl for in the first place, making conversion a more reasonable possibility. Regexes, easy list/hash construction, etc. For example, Java, Python, and Ruby all have some good stuff, but Java has the additional advantage of being much more popular than the other two, which, by definition, makes it better for large-scale, multi-company production efforts. (More people know it. More places to learn it. Therefore, less stress for the company managers who have to decide these things.)
So, do those sound familiar? They're the basic concerns behind the Perl6 efforts as a whole.
Perl6
Having said all that, I started out not being terribly active in perl6. When the RFCs came out, I was impressed, but not inspired: while an improvement, let's face it -- the RFCs by themselves are mostly a patchwork on top of Perl5. Good suggestions, but nothing encompassing. While I kept on top of developments, I never really got the feeling that the core issues were going to be solved in any way that would profoundly affect the capabilities of Perl. As the Apocalypes and Exegeses (Exegesii?) came out, however, I began to take more notice... here, quite possibly, was something New.
So in the end, what finally happened -- my conversion in the desert, as it were? Apocalypse 5, to be blunt. No, really. Apocalypse 5 was an eye-opener; it showed that the design team was working from a much deeper level than I had expected, and was willing to tackle some of the fundamental issues with the notion of improving them, not just fixing them. I think everyone owes kudos to Larry on that one. Perl6 isn't just going to be a fixed-up Perl5. It's going to be a new version of the language, refocused towards what has been "learned" in the intervening ten or so years. More things will be easy. Fewer things will be hard. Many things may turn out to be one-liners. And that's why most of us are programmers -- to get things done, and not for the dubious pleasure of the mental gymnastics, trying to explain complex concepts using whatever precious few words our dumb-as-sand computers happen to know.
Are there still problems in Perl6?
Yes, I think so. For starters, Perl6 may be even more impenetrable to newcomers, instead of less. Non-alphanumeric characters will comprise a great deal of Perl6 functionality -- that could mean trouble. And different concepts may be expressed with very similar syntax, causing new programmers to have fits, and causing them to rip my head off during the training process.
But that's solvable, and probably will be. I don't worry about it as much as I did a few months ago. Right now, my goal is therefore pretty simple.
The Objective
I want to document Perl6 from a "normal person" perspective. I'm not on the design team, and so I have no more insight into the internal architecture than most people. Sure, I've looked at the Parrot source, etc., but most people won't. And shouldn't. And can't. Sure, I've used Perl5 since it was first introduced, but most people haven't.
I want to document how Perl6 behaves from the perspective of someone who doesn't know the ins and outs of the internal design, and who hasn't memorized the various new operators, syntax, etc., to such an extent as to make the answers automatic. Does this mean I want this to be a "beginners" guide? No way -- it'll be hard-core, detailed, best practices stuff. But it will be conciously written from the perspective of a non-expert. As much as possible, it won't assume any particular previous language experience.
I do plenty of consulting, and train people how to use Perl, but the people I train generally don't have much Perl experience... they just need to get a job done. Perl is a means to an end for them, not a religion. So, I'm thinking, how would I explain Perl6 to them? Not to a Perl5 expert, but to a typical, corporate programming team that wants to know how and why Perl6 is different from C++, or Java, or C#, or VB, or whatever they've had previous experience with?
Right now, I'm going through the Apocalypses and Exegeses, again, and coming to the realization that Perl6 will need to be taught a bit differently from Perl5 -- more so than I first thought. The Camel book won't necessarily represent the best ordering of concepts, anymore. While the core language looks very much the same, some of the new underlying concepts have implications that will dramatically change what the best way of doing something will be. And so I've started to branch out from the OO questions, outlining other areas that are going to be tricky.
We'll see where that goes, but one thing's for sure -- Perl6 will be better than Perl5. Faster, more concise, more fully featured, more helpful to programmers. It will be a language that can be used, easily, for enterprise-level applications. And it will be.
Oct. 18, 2002
Mike Lazzaro
mlazzaro@cognitivity.com
