The purpose of this page is to help respond to FUD about Perl 6:

Guidelines for Responding to FUD

When responding to FUD, keep these things in mind:


Development Issues

Perl 6 will never be released!

While a release date is purposefully not given, there is no reason to assume that it will never be released. Building a language that supports all the ways of programming currently known to man (as well as some entirely new ones) is challenging and takes a lot of time. Perl 5 has been around for over 15 years, and Perl 6 will also be built to last at least 20.

Note, by the way, that it took all this time since 1987 to get Perl 5 where it is now. Doing that all over again (the right way, this time) isn't something we can do in a few dozen months.

A language or VM this powerful can never be fast!

That has been said about almost every new language. The truth is that it all boils down to machine code eventually, and that this is fast, regardless of where this came from. The number of layers in between is somewhat important, but there's no universal rule than something that is powerful has to be slow. We're not about to invent the rule, either.

Perl 6 is still a compiled language, like Perl 5 was. The VM that executes it is separated from the rest, but separation doesn't make slow. In fact, it allows for new optimization techniques that can apply to all the languages supported by the Parrot VM.

The development process will implode into a giant ball of ego and misery!

Ancient FUD. Hasn't happened.

The Perl 6 process is driving away too many good developers!

Perl 6 is unnecessary and is hurting Perl 5 development!

Perl 6 will not be as portable as Perl 5!

Perl 6 will not be able to fix the line noise stigma!

It takes too long to port all CPAN modules!

Implementing unnecessary features will delay development!

All the Perl documentation will never be rewritten to match Perl 6!

Of course not. There are plenty of old IBM BASIC manuals around, and I'm quite sure that those have never been rewritten to match current BASIC dialects. Some books and manuals will be rewritten to match Perl 6, some new ones will be written from scratch and some will never see a Perl 6 version. As long as all target audiences get Perl 6 documentation suited to them, this does not have to be a problem.

The Perl 6 reference documentation (available as Perl6::Doc on CPAN) will probably be rewritten from scratch, in a more structured and beginner friendly way, but with all the important warnings and side information you have learned to love from Perl 5.

Language Usage Issues

My Perl knowledge will be useless!

Programming isn't a skill of knowing syntax and a bunch of functions. It is a way of structured thinking. The philosophies behind different languages may differ, but the way you programmed in Perl 5 is still possible in Perl 6. Just the spelling changed a little.

Besides that, your Perl 5 knowledge will come in handy the many times that you encounter legacy Perl 5 code. When Perl 5 was released, there was still Perl 4 code in production, even though very few people had experience with it.

All my existing code will have to be rewritten!

Perl 5 will be around for as long as you need it. It is free software, not a subscription. There is no way it can be taken from you. In fact, most new Perl 6 applications will probably begin with

use perl5:DBI;

and make use of CPAN libraries. Pugs can compile Perl 6 programs into Perl 5 source code, so you can freely experiment with Perl 6 on top of your existing Perl 5 codebase.

If you do not want to have to keep Perl 5 around, the Ponie project aims to port Perl 5 on Parrot, the new virtual machine designed for Perl 6. Once Ponie is ready, you can use Perl 5 code in a Perl 6 application, if you want.

If you want it to be real Perl 6 code, you can use an automatic conversion program that takes your Perl 5 program and turns it into Perl 6. It may require some manual adjustments afterwards, but most will work automatically. This is assuming you didn't obfuscate or golf :) And of course, that your code does not depend on bugs in Perl 5.

To get idiomatic Perl 6, yes, you will need to rewrite the code by hand. Whether this is worth the effort is up to you to decide. Rest assured that Perl 5 will not suddenly disappear.

Perl 6 is hard to learn!

Perl has always had easy onramps, even though learning all of Perl has always been challenging. In Perl 6, you still only need to know a small subset of Perl to be productive. Perl 6 can do more than Perl 5, and of course it will take longer to learn all of it. But for a fair comparison, you have to compare the feature subset of Perl 6 that was already available in Perl 5. And then you will see that learning the language will in fact be much easier, because unexpected side effects and changing symbols have been taken care of.

Many things that required manual fiddling are now automatic. Especially in object oriented programming, the differences are huge. Perl 5 supported OOP, but didn't do much to help you write in it. Perl 6 has a very complete object model. Perl 5 was not well suited for teaching OO to beginners, because of its explicit complexity when dealing with objects.

Perl 6 aims to be much more usable in academic programming, and for first time programmers.

A good editor will provide you a way to display the glyphs in other ways, and you can always choose to convert the source code to ASCII.

Language Design Issues

Perl 6 has too many operators!

Compared to Perl 5, Perl 6 has a few more operators -- and slightly fewer precedence levels. This doesn't automatically make the language harder to learn. Many operators are there to make your life much easier. Many tedious and error prone loops are no longer needed, and there are operators that are very easy to learn that let you avoid constructs that are hard to learn.

The number of operators has increased mostly because of some much needed separation. The single bitwise-OR operator | is now three different operators: ~|, +| and ?|, operating on strings, numbers and booleans respectively. That does not mean you have to learn each of them. Their spelling is very consistent and takes very little learning. It will take less time to learn the new operators, than to learn how the old ones behaved in all the different situations.

Perl uses symbols where other languages use words. Either way, to use a feature, you have to first learn how the feature is spelled. In this respect, a function with two arguments is just as hard as a symbol, especially if English is not your native language.

If we say that you can now write $foo == (1|2|3) instead of ($foo == 1 || $foo == 2 || $foo == 3), you have learned a new operator in less than a second, with no effort at all. You can use the new | operator productively, without the need to know that (1|2|3) is actually a single junction value.

Perl 6 is not Perl! Perl 6 does not look like Perl!

Perl 6 is not Perl 5 and hence does not look like Perl 5. But ask yourself what makes Perl be Perl and what makes Perl look like Perl. Sigils, context and expressive power are what make Perl, and each of these were improved.

The new features won't be used by people!

This was said about Perl 5 too, when it got object orientation, references and lexical variables. New features can be very intimidating, but eventually people do discover their use, and that they're not so hard to get used to.

Not everyone will use every feature, but that too is true for every sane programming language in existence. This is okay, because without the new features, Perl 6 is still a great language. If someone uses a loop instead of a nice hyper operator, that is just another way of doing the same thing.

Many new features make programming much easier, even for beginning programmers who may not know the details of the new features. It is probably safe to assume that the majority of new features will be used. If you are really afraid that they won't, do know that you can play a role in their acceptance. Be active in the community, show that you are using the new features in intelligent ways, and others will catch up.

I will never be able to type Unicode operators!

It is not necessary to type any of the unicode symbols. They all have an equivalent that is plain ASCII, typable with one of the most limited keyboards used today: the US QWERTY keyboard. The ASCII variant may be one character more, but in many cases, it will be easier to type and work exactly the same.

Configuring your system so that you can enter the new pretty glyphs may be hard, but it is expected to become much easier in the coming years. Some archaic technology may never be able to let you input these characters, though, and that's okay.

Unicode ops cannot be read by me!

Perl 6 will not be used as much as Perl 5 was!

Junctions will be abused!

Perl 6 will be too much like Haskell!

Perl 6 has too many features just for completeness, rather than utility!

Perl 6 makes golf (and obfuscation) hard and thus ruin culture!

Please take a look at the examples/obfu/, examples/japh/ and examples/golf/ directories in the Pugs repository.

Perl 6 is made for big programs, not for oneliners and short scripts!

Programming Perl will be three volumes!

POD will still not support OO and Grammars!

POD will continue to use visual markup!

Every module requires 42 "use" statements to improve syntax!

Larry's really bad decisions tend to get fixed later in the design process, we hope. If you keep using the same modules over and over, you can make a module that uses all of those modules, and still end up with the things getting exported to the right place. Individual authors, communities, or style guides could have their own sets. Most languages (with the possible exception of $your_language_of_choice) have numerous misdecisions.

In Perl 6, due to the dynamic grammar, you can change them.

use Style::JRandom; use Style::PBP; use Style::GNU;

Perl 6 will split into multiple incompatible dialects!

The internals will be just as inaccessable as Perl 5's!

There is too much misinformation surrounding Perl 6!

General Resources and References