Re: Mixed feelings
> From what I understand, and from
> what other posters have said, Perl 5
> code will work with Perl 6.
Not quite. Perl 6 will not be compatible with Perl 5 in that Perl 6 is not just additional features on top of Perl 5. They are different languages. You will not be able to cut & paste Perl 5 code into a Perl 6 program and expect it to work.
What is meant by Perl 5 code working with Perl 6 is that Perl 5 (via PONIE [Perl On New Internal Engine]) and Perl 6 will both run on the Parrot virtual machine and compile down to Parrot bytecode. It is a goal of the Parrot project that languages running on Parrot will be able to interoperate. In this way you will be able to have a Perl 6 program calling functions from a Perl 5 module and vice-versa.
In this way you should be able to mix Perl 5 and Perl 6 code. This will allow you to use existing modules and libraries and slowly transition your code one piece at a time from Perl 5 to Perl 6. Or if you find there's things Perl 5 continues to do better than 6 you can keep writing those portions in Perl 5 much like how you can write parts of a Perl 5 program in C.
You've read the fantasy. Here's the reality.
This article is written from a point of near ignorance of what is really going on inside Perl 5. Except the author has had this pointed out to him time and time again so he can't really hide behind simple ignorance. He makes statements about ideas he considers "simple" without any idea of the extreme complixity in implementing any of them in the reality of Perl 5. He has demonstrated a marked lack of understanding of the guts of Perl 5 or the design of Perl 6.
So I would like to simply say: please ignore this article. The article is not a troll, because I know Shlomi is sincere, but it is very wrongheaded. Its sorry that Freshmeat allows such things to be published, I wish they would do some basic editorial checks before publishing. For those that know of me hopefully that's enough explaination. For the rest, read on.
I write this not as a rebutal to the article but to prevent its spurious assumptions and erroneous conclusions to spread.
I'm going to only briefly talk about the documentation issue and get it out of the way because its such an old and tired argument. Documentation is hard. Documentation is always in need of improvement. Everybody knows this.
In fact, we know it so well that we've been writing lots of new introductory Perl man pags. perlintro, perlretut, perlreftut, perlrequick, perlboot, perlbot, perldebtut, perlopentut, perlpacktut, perlthrtut, perluniintro are all fairly new tutorial man pages.
And look, there's learn.perl.org. A whole site devoted to learning Perl. And several beginner's mailing lists. And an entire book generously made freely available online by Simon Cozens, one of the better Perl developers out there.
Shlomi has waved around two magic fixes to the Perl documentation problem for a long time. Make "Programming Perl" free or rewrite everything. Its questionable if the Camel would solve all our documentation problems since its derived from the man pages, but it doesn't matter. The authors and they have said no. Their decision should be respected, everyone's allowed to make money off their own work if they like.
So what about rewriting everything? I personally believe in incremental fixes but sure, go for it. Why not? Maybe something better will come of it. But I'll tell you what won't work: Writing articles about how other people should rewrite the documentation or give away their work. Shlomi's been doing this for years and frankly its gotten tiresome. Direct all that energy at more documentation patches please.
Perl 6 actually is a solution to the documentation problem. Emotional attachment to the existing doc layout doesn't exist so we can fix long standing problems. More importantly, Perl 6 is being completely documented as its being designed. Therefore the documentation will not grow piecemeal as the Perl 5 docs did but we can lay it all out sensibly up front. Finally, we've come along way in knowledge and culture about documentation in the last 10 years.
And besides, wasn't he just proposing rewriting the docs anyway?
That's all I have to say about the docs.
Now for Perl 6. Rather than take the article point by point let's just lay out some simple realities. The article is sorely lacking in knowledge about what is really involved in developing Perl.
We'll start with some simple truths. The sky is not falling.
* Perl 5 is not going away.
Perl 5 is still actively maintained and shows no signs of slowing down. In fact, new stable releases are coming out faster and more regularly than ever. Parrot and Perl 6 have not resulted in a brain drain from Perl 5. Instead the community expanded to fill the new needs.
* Perl 5 is NOT GOING AWAY!
The PONIE project is an attempt to incrementally replace the guts of Perl 5 with pieces of Parrot. This will result in a better bug-for-bug compatibility with Perl 5 than a complete rewrite. Eventually PONIE will become Perl 5. So far it works, you can download an alpha from CPAN right now.
* Perl 5 will work with Perl 6.
If all goes as planned with PONIE and Parrot, Perl 5 code will be able to interoperate with Perl 6 code by virtue of their both compiling down into Parrot bytecode. This means the huge bulk of existing modules out there (such as CPAN) will still work with Perl 6 to ease the shock of the intial transition.
Nobody's forcing anybody to learn Perl 6. In fact, we're bending over backwards so they won't have to.
* Parts of Perl 6 are being backported into Perl 5.
There is a whole host of Perl 6 features that have been implemented in Perl 5. Here's some of them.
Some are just proofs of concept. Some, like the grammar parser, are intended for eventual production use. Some, like the defined-or operator, will appear in the Perl 5 core. Perl 5 will continue to absorb whatever it can from Perl 6 without breaking backwards compatibility.
Let's talk about the current state of Perl 5.
* Perl is old.
Perl 5 will be 10 years old tommorrow (11 if you count from the first alpha). Perl itself is pushing 17. A lot has changed in 17 years. A lot has changed in 10 years. A lot has changed even in just 5 years. And I'm not just talking about technology I'm talking about the Perl community. Its grown from a bunch of sysadmins avoiding shell scripting to a bunch of half-educated .com CGI programmers and is now a community of seasoned veterans using Perl for large applications.
Perl 5 is having trouble keeping up. Here's why.
* The internals of Perl 5 are a disaster.
Layers upon layers of C macros and ifdefs. Code dating directly back to Perl 1. Hacks made to support TWO threading models. Hacks made to support every OS under the sun. Hacks made to support buggy libraries. Buggy compilers.
As a consequence some very powerful techniques are avoided because they are slow. Tying is slow. Overloading is slow. Threads are slow and fraught with bugs. Hell, function calls are slow which is disasterous to modern programming.
And its becoming increasingly difficult to change or optimize anything without breaking something.
This alone is reason enough to rewrite the code. But what about the language?
* Nobody knows how its supposed to work.
There is no specification for Perl 5. Features are "discovered" all the time. XS is largely undocumented. There are tons of "accidental" features that people rely upon all the time. The renewed interest in regression testing has helped but any rewrite is going to get subtle things wrong.
This means when you try to add in a new feature, or fix an old one, much more often than not the patch will be shot down for esoteric reasons of backwards compatibility. This means improving the Perl 5 language becomes very, very difficult.
* The grammar is undefinable.
Not only is there no grammar definition for Perl 5, parsing Perl 5 code without running it has been proven to be impossible. Many modules can alter the way the code behaves. From the somewhat extreme filtering modules like Lingua::Romana::Perligata to the simple and commonly used strict.pm.
This means no automated programming tools for Perl 5. This means no refactoring browsers. This means one of the most powerful programming tools of this decade will remain unavailable to Perl programmers.
Now, lets consider some things about the Perl 6 design.
* It has to live a long time.
As mentioned, Perl itself is pushing 17. Perl 5 is 10. If you're the sort of person that has to play with the Perl 5 internals or write advanced CPAN modules you know its already showing its age.
Perl 6 has a planned lifetime in decades. The point was made that "Perl 6 may be a good language to [sic] design 10 or 20 years from now". This is true. The hope is to make the design flexible enough to be competative in 10, 20, even 30 years. The only language which has remained respectable that long is C and arguablely not because its a good language but because its the fastest thing out there.
It was also said that Perl 6 is "certainly not [a good language] for this moment." That is also true. However, it is not a language for this moment. There's another year or two before an alpha is released and I'd be surprised if a truly stable release came out before 2008. When you look at what Perl programmers were doing in 2000 (sysadmining, basic web stuff) vs what they're doing now (pretty much everything) you can see why the Perl 6 design is sticking to the bleeding edge.
I've been a Perl programmer for nearly eight years now. I'd like to be a Perl programmer for another 10 or 20 years at least. I'd rather some short-term pain now in transitioning to Perl 6 than long-term chronic pain with a limping Perl 5.
* Perl 6 is not changing as much as it seems.
People who read the Perl 6 materials are often overwhelmed by all the change and new features. What's often forgotten is how much is not being changed. Or how many of the changes are superficial. It is better to read Damian's Synopsis and Exegisis than Larry's Apocalypses to get an idea of what using Perl 6 will really be like. Larry is writing a language spec. Damian is writing user documentation. Consider them like "Learning Perl" vs "Programming Perl".
* Perl 6 is actually simpler than Perl 5.
Perl 6 is trying to remove as much of the unnecessary complexity and exceptions from Perl as possible. The grammar is simpler and easier to parse. There's less exceptions. Operator precedence is simpler. Scoping is simpler. Writing OO code is more explicit and regular. Rules (ie. new the regexes) are simpler and its easier to write and modify complex expressions.
And the same will be true of Perl 5 as Perl 6: You don't have to learn the entire language to get things done. Personally in eight years of programming Perl I've never learned how to use formats, pack or XS in Perl 5. Much of the really interesting/complex stuff will be hidden inside modules. Modules written by the top 1% of Perl programmers but used by everybody else. Modules allow you to hide complexity but still take advantage of it.
* Perl 6 will retain the Perl 5 class system in addition to its new one.
"This [a new OOP system] may be possible to do in userland, while requiring people to choose between this or the original Perl 5 way of doing things."
Yes, Perl 6 is doing exactly that. We're making the Perl 5 regex engine available, too. Please do more research next time.
With all the backround information in place, let's look at some of the propositions and why they won't work.
* Just bolt the new features onto Perl 5!
I've already shown why the existing Perl 5 code is becoming impossible to work with. I've already shown why the language is too brittle to accept new changes. If we're going to hang onto backwards compatibility there's little in the way of large changes that can be made.
As an example, to get a firm idea of the order of magnitude of work involved in something like fixing the garbage collection and threading systems take a look at the effort being made in the PONIE project. Taking advantage of Parrot's GC and threading is one of the major reasons for PONIE. This is not something you just wave your hands at.
iThreads, as another example, took years to even bring into the usable state they are now. And this is over the ashes of the first attempt at threading (the 5.005 threads). The fact that the article blithely states that we should now go back to 5.005-style which was tried and failed tells me he has absolutely no idea what's involved.
* Just do it all as modules.
The article offhandedly states that "a good idea may be to create a new OOP system which features everything [advanced CPAN OOP modules] have to offer" and lets us know that "it can be done in Perl 5". As an author of several of the sorts of modules he's talking about I can say this is fantasy. In order to get advanced OOP stuff done in Perl 5 you often have to do very perverse and mutually incompatible things. Syntax filters. Symbol table hacking. Global autoloaders. Just getting the magic working is hard enough without worrying about other people's magic.
I'm not saying its impossible, I'm just saying its really, really, really, really hard.
* Fifer: Add incompatibilities a few at a time.
This is the worst of all possible worlds. Could you imagine what would happen if every release deliberately broke compatibility? For every new release of Perl you'd have to check over all your existing code to see if anything broke. Anyone wanting to ship Perl code would have to ship different source for each version of Perl. CPAN would become useless. No one would ever want to upgrade, and we have enough trouble getting people to go from 5.6 to 5.8 as it is, and we're anal about backwards compatibility. Perl would become balkanized and useless.
Shlomi has been pushing Rindolf for years. It puts forth some shallow improvements to Perl 5 and doesn't really address any of the real problems. Its priorities are somewhat bizzare and detached from reality. It doesn't even bring Perl 5 up to the level of other existing languages.
Rindolf is vaporware. There has never been any code for it and having seen how the author works over the years I doubt there ever will be. He seems to be expecting someone else to pick up his ball and run with it. Something I tell people time and time again about free software is this: if you want something done do it yourself!
So that's that and I wasted too much time writing all this.