Articles / Critique of Where Perl 6 is...

Critique of Where Perl 6 is Heading

The purpose of this essay is to explain why I believe Perl 6, the way it currently seems to progress, is the wrong thing at the wrong time, and why I predict (with all the expected caveats of predicting something) that it won't be successful. I will also suggest a better alternative for the future of Perl which makes more sense at this point.

Overview of the Current Design of Perl 6

The design of Perl 6 is progressively laid out in the Perl 6 Apocalypses which are written by Larry Wall (the original creator and designer of Perl versions 1 through 5), and exemplified in the Exegeses by Damian Conway and others. There's a more progressive design which has been shared among the members of the perl6-language Mailing List, but hasn't been formulated into a specification yet, and/or has not finally been decided upon by Larry.

It is evident from the Apocalypses and Exegeses that Perl 6 will break compatibility with Perl 5 in many ways (usually deliberately). Furthermore, it incorporates a lot of features and paradigms from different languages that are not common in most languages in common use today.

Why Perl 5 is Good

Perl 5 has seen incredible popularity. There are now millions of lines of code written in Perl by thousands of programmers. (Possibly even milliards of lines of code, written by hundreds of thousands of programmers.) The so-called Perl 5 Man Pages are (or at least used to be) intended for experienced Unix system administrators and programmers who are already familiar with either Perl 4 or with the Unix toolset of shells, awk, and sed. The Web Revolution wanted something else. Many programmers who were new to Unix (or even to programming in general) learned Perl because it was the most suitable tool for the job, often using it in situations in which writing a shell script would have been better. Thousands of CGI scripts have already been written in Perl, and new ones are constantly being written. Perl has also seen wide deployment in other areas -- bio-informatics, for example, and programming UIs. MandrakeSoft has written the Mandrake Linux installer in Perl, and also many of the distribution system tools. And Mandrake is a very popular distribution.

CPAN has provided programmers with a great number of modules that can be easily installed and used to solve most tasks much more easily. CPAN's convenience and coverage is the envy of all other languages, and even accounts for some people using Perl despite liking a different language better.

One thing that has to be remembered is that Perl exhibits the Iceberg Effect: for every piece of code that is distributed (either on CPAN or otherwise), there's much more code that is kept in-house or in private. Many CPAN modules have many equivalent ad-hoc routines doing similar things written in Perl that are actively in use in many software shops and were never released to the public, nor are going to be released. (I know I wrote such things when I began programming in Perl)

Perl 5 is a modern, powerful language which can be used to write code that either incorporates many different paradigms or even emulates many other languages. As Larry Wall once noted: "You can write Perl programs that resemble sed, or awk, or C, or Lisp, or Python." (Or BASIC/Visual Basic for Applications, Pascal, a great deal of Haskell code, PHP, etc.) Most people can write a lot of Perl 5 code and won't encounter a place where they think that it is inadequate. Thus, Perl 5 is good enough not only for today, but also for the future ahead. ANSI C is a much more limited language than Perl 5, and still, many people are actively using it and writing new code in it. They also often like doing so. If ANSI C is good enough, there's no reason to assume Perl 5 isn't.

Why Perl 6 is Bad?

No one Understands Perl 6

Having read this title, you are probably thinking to yourself: "So you don't understand Perl 6. What makes you think everyone else doesn't? How do you justify this inductive thinking?" Let me tell you a little story:

One day, I met with a good friend of mine (whom I highly appreciate both as a person and as a software engineer), and I asked him if he reads the Apocalypses. He said he does, but that he doesn't understand them. This eventually made me realize that I also read them, and also did not understand many things. And neither he nor I are particularly stupid people. And here's an interesting quote from the famous Weblog "Joel on Software": "Whenever somebody gives you a spec for some new technology, if you can't understand the spec, don't worry too much. Nobody else is going to understand it, either, and it's probably not going to be important." (Read more at the link).

Granted, my editor told me that the Apocalypses are sort of Larry Wall's braindumps, notes on design notes using a lot of jargon from the Perl mailing lists and summarizing a lot of discussion that took place there in one condensed article. However, they do indicate that a lot of new things will be added that most people are not familiar with and will need a lot of time to understand because they haven't encountered them before.

It even takes Damian Conway, Allison Randal, et al. a lot of time to prepare the Exegesis after the latest Apocalypse is published. Perhaps a different, more accessible format of the Apocalypses is needed. Perhaps, eventually, such accessible documentation will be made available, teaching people new to Perl 6 or even Perl in general how to learn Perl 6. (I do hope it will fare better than the original Perl 5 man pages, which were a positively awful resource for beginning Perl programmers.)

I'm pretty sure my friend and I are not dumb people. I know people who will have even more difficulty, and they're not dumb either. Who is going to take all of these people by the hand and teach them Perl 6?

Perl 6 is not Backwards-Compatible with Perl 5

You probably think: "Ha! Backwards-Compatibility is the curse of software design. Let's break it now so we'll get something manageable." That's very nice, but backwards-compatibility is also something you need to make sure people can have some amount of confidence in writing code that makes use of the language or API. Breaking it on purpose, without a good enough reason, is bound to cause resentment among the users, who may opt to convert to something that is known to be more backwards-compatible or stay with the old version.

Perl 6 breaks a lot of compatibility on purpose. In fact, most of the Perl 5 code out there won't compile with it (unless Perl 6 will run in some backwards-compatibility mode.) Naturally and hopefully, this Perl 5 code can be re-used from within Perl 6. That's better than nothing.

As an example of breaking things on purpose, here's some Perl 5 code I wrote:

for my $t (0 .. 6)
  {
  if (abs($new[$t]-$new[$t+1]) > 3)
  {
  $is_ok = 0;
  last;
  }
  }
  if ($is_ok)
  {
  push @moves, [$i,$j];
  }

And here's the equivalent Perl 6 code:

my $is_ok = 1;
  for 0..6 -> $t {
  if abs(@new[$t] - @new[$t+1]) > 3 {
  $is_ok = 0;
  last;
  }
  }
  if $is_ok {
  push @moves: [$i, $j];
  }

Recognizable, but completely different! Furthermore, the dereferencing and method invocation in Perl 6 changes from "->" to "." (just because that's the way it's done in languages such as Java and Python), so the good old string concatenation operator is now "_".

So imagine you have a large body of Perl 5 code which you need to extend with more code. Are you going to write the new code in Perl 6? Well, if you want other Perl 5 programmers (of which there are now several hundreds of thousands) to be able to understand it without getting on their nerves, forcing them to learn a new language, forcing them to understand Perl 6, etc., then Perl 5 is the only option. I predict that most software shops are going to stay a clear mile away from Perl 6, and mandate all of their programmers to use Perl 5 exclusively.

Writing new code in Perl 6 while having to maintain old code in Perl 5 is going to be confusing, and will require the developers working for your project to know both and to actively use both. Most Unix shops just settle on either Perl, Python, or a similar Agile language, and may even have strict style and use guidelines on how to write the code in these languages. They're not going to like having a dual Perl 6/Perl 5 codebase.

While software enthusiasts, who like to write code for fun, may learn Perl 6 because many of them like to learn new languages, they will probably be told to use Perl 5 (or Python, or PHP) at their workplace. Perl (1 to 4) grew as a language to get some Unix jobs done better. Perl 5 was intended as a revamp to eliminate many of the Perl 4 shortcomings, and even to direct Perl for writing large applications. Both of these goals were achieved, but what should still be remembered is that most people use Perl for in-house use, and this is what "pays the Perl developers' rent", so to speak.

Perl 6 may be a good language to design 10 or 20 years from now, but it's certainly not one for this moment. Perl 5 is a good language today already, and if we want people to adopt a new dialect of Perl, we need to start from it, not from a completely new page.

Perl 6 is too Complex

Before we go on, I ask you to make sure you've read what Joel Spolsky has to say about the growing complexity of programming. Yes, programming is becoming more complex, and IT workers find themselves having to (at least temporarily) specialize in a certain field or limited set of fields. However, it is still important that the framework designers try to reduce unnecessary complexity.

A good example are the Unix mail servers. Sendmail used to be the most popular solution, but its configuration is incredibly complex (which is just one of its many shortcomings). As a result, a new crop of mail servers came about: qmail, Postfix, and others. These all sported an easier configuration that even mere mortals could do.

Another good example are languages like Java or PHP. These are highly successful languages, in part because the rules, grammar, and syntax of them were kept as simple as possible. While their standard libraries are very comprehensive and complex, the language as a language is very simple. (I don't suggest that Perl 5 follow this lead -- a complicated core language is one of the things that makes it sexy -- I'm just noting this fact).

The Perl 5 core language is already very complex. Part of this complexity is justified, and the rest is a result of either legacy features or things that some programmers like to use. Nevertheless, Perl 6 will be much more complex than that, too complex for the present level of Perl programmers.

When Perl 5 was created, people expected its programmers to be experienced Unix sysadmins or programmers, probably with some working knowledge of Perl 4 (the Perl 5 man pages originally reflected this). The WWW boom wanted something else, and a great many Web programmers learned it because that's what their job required, sometimes even using it for writing "shell" scripts because Perl was all they knew at the time. Further developments, like the growing popularity of Linux and the bio-informatics boom, have made Perl even more popular. Some people even learn Perl as their first real programming language.

So, Perl 6 will be too complex for them. Much too complex. If I and my friend (who now eats hardcore scientific documents for lunch, and got a reputation for himself as the local Linux kernel guru) could not understand the Perl 6 Apocalypses, I expect much less of the many everyday Perl workers, who are just using Perl to get their jobs done and could not care less about all the extraneous Perl 6 features.

A lot of what Perl 6 integrates will probably turn out to be linguistic fads that no one will want to use. Integrating everything at this point is not going to be beneficial, especially for a language like Perl 5 that aims to be a no-nonsense language for everyday use.

Analogy with the Perl 4 to Perl 5 Conversion

A question that needs to be asked is whether this is analogous to the Perl 4 to Perl 5 conversion that took place circa 1993 and also broke a lot of compatibility, and required people to adapt or even rewrite a lot of their code. There is a place for comparison, but nevertheless, the situation today is very different. Perl 4 was heavily lacking in many respects and justified a good redesign that would make it more up-to-par with the powerful languages of then and now like Common LISP, Smalltalk, C++, and Python.

Perl 5, on the other hand, can serve us well in the foreseeable future. Another thing to note is that Perl 4 was a niche language that was used by various Unix workers to write support scripts and the occasional large-scale application, but not much else. Perl 5, on the other hand, is much more commonly used. There are many more Perl 5 programmers, much more Perl 5 code out there, and much more collective knowledge and love of Perl 5. Also, the Perl "market" of programmers that can learn it is much more saturated today than it was when Perl 4 started.

The Language Formerly Known as Perl 5

Here's a better idea: Let's continue to develop Perl 5 (either using the Perl 5 backend, PONIE, or something else), making incremental improvements, and so make sure it keeps with the pace of technology. Sometimes, compatibility can be broken, or features removed, but not in one big swoop, and always informing people about it first.

We need a new name, because Perl 6 bounds us with its upper digit, leading us to eventually have Perl 5.666. I'll use the name Fifer here, simply because it is an awful name that I don't intend to use. (I'll let the Perl community pick a better name from the list of new names, one of which I'm going to advocate). Fifer would be the language formerly known as Perl 5. It would belong to the Perl Family of Languages, which includes such languages as Perl 4, Perl 5, Perl 6, Ruby, and even PHP.

10 years from now, Fifer will probably be more similar to what Perl 6 is today. However, at that point, there would be plenty of Rindolf code that is perfectly working and modern, as people will have plenty of time to gradually adapt their code.

In a way, I think this is what will happen regardless of whether people read this article or not, but I like to make this prediction clear because I think a programmer eventually needs to make such predictions if he wants to make sure his work lasts for a long time. I see Perl 6 as a dead end, and so don't intend to try to understand it further, and don't intend to learn how to program in it, unless I actually have to maintain some Perl 6 code. (which I don't expect to happen). And I suggest you do the same.

The standing issues in Perl 5 (some of the major ones will be covered shortly) can be resolved without a complete redesign of the language. While a backend change may be in order (like switching to PONIE instead of perl5), or at least a heavy revamp of the original perl5 one, overhauling the language is not needed. The time calls for a gradual evolution instead of a complete revolution.

Standing Problems in Perl 5 and their Solutions

Perl 5 is a good language, all in all. Nevertheless, it has some standing problems which should be resolved. Perl 6 is the wrong way to resolve them. Here is the list of the most major ones as I see them, with suggestions on how to resolve them. Other people may have different views.

Lack of Good Accessible Reference Documentation

The Perl 5 Man Pages are the official reference documentation for Perl 5. Nevertheless, they:

  1. Are quite disorganized. Many things are documented in very obscure places.
  2. Rely on a lot of knowledge of other technologies (many of them pretty obscure or largely superseded by Perl 5 now).
  3. Give many examples that give a common use, instead of trying to illustrate the point. Usually, they cannot be fluently read.
  4. Are generally very hard for a person without a good background in what they talk about to understand.

The Camel Book is much better in this regard, but it is not freely redistributable or modifiable, and not even available online except as part of the pay-per-month Safari, or in various illegitimate online copies. It is, thus, also inadequate.

A good core reference documentation needs to be written, especially taking into account the fact that the ones for Python or PHP are excellent. The easiest way for the community to resolve this is that the authors of the Camel Book make its text available online, preferably with its POD sources. This will not hurt the book sales much, as many people buy it to read before going to bed, or to give as a present to their co-workers, or to keep at their workplace for everyone to enjoy.

If this is not going to be done, then either the Perl 5 Core Documentation will need to be heavily revamped, or an entirely new documentation ought to be written. This will mean much more work on the part of the contributors volunteering to do it, but it is quite necessary.

Perl 6 would be a non-solution to this problem because it gives an entirely new language for which new core documentation has to be written.

(Note that I'm not referring to Perl 5 tutorials, which help a beginner get started. There are quite a lot available, and some of them are reportedly good enough.)

A More Unified Object System

The Perl 5 Object-Oriented Programming system is quite powerful, and adequate for most needs. Nevertheless, to extend it whenever possible, developers wrote a great deal of userland Perl modules on CPAN. However, it is not perfectly clear whether it is possible to make active use of several of these modules or all of them in one applications.

A good idea may be to create a new OOP system which features everything these modules have to offer. This may be possible to do in userland, while requiring people to choose between this or the original Perl 5 way of doing things. It can actually model the Perl 6 OOP framework, without requiring people to adopt Perl 6 entirely. Or it can be something completely new that attempts to be more Perl 5-ish.

Regardless, it can be done in Perl 5.

Better Garbage Collection

The current perl5 garbage collection, which doesn't work well if there are circular references, is incredibly limiting in the choice of the application design. We need a better one. I believe Parrot and PONIE will give it to us for free, but I may be wrong. In any case, perl5 can probably be tweaked to adopt such a system.

Multi-Threading

The current iThreads threading model is very resource intensive, and goes against most of the multi-threading tradition used before Perl 5 adopted it. We need a better threading model in which each thread simply shares the same memory space and variables as the other threads. This is similar to what happens with POSIX Threads on Unix, Win32 Threads on Windows, and the threading model of Java or Python. It also was the old Perl 5.005 threading model.

It is possible that the perl5 backend cannot support this very well. If Parrot (or an entirely different backend) does, then a change of backend may be in order.

Other Issues

I have outlined some of the things I found pressing in Perl 5 in the Rindolf Spec (version 0.3.5). Since then, I neglected working on the specification (much less started working on a suitable implementation), partly because I concluded that Perl 5 was already good enough for me. Nevertheless, the specification may be studied to search for nice additions to the language, all of them possible without breaking compatibility.

Other people may have other things that bother them. I am happy to be informed of any things that they feel are missing.

Conclusion

Perl 6 will probably not be widely adopted. The future of Perl lies within Perl 5 and Fifer, i.e., the language powered by perl5, PONIE, or perhaps a different backend. Any time invested in working on Perl 6 or learning about it can probably give you new insights about programming, but don't expect your efforts to have any day-to-day useful value.

People want a language that gets the job done, is fun to program in, and which they love. Different people have different ideas of what this language is, and they also use different languages for different tasks. To quote my good friend (a different one), "How can you make a programming language that is good for every purpose, if you can't even make such a screwdriver?"

Perl 6 is the wrong thing at the wrong time. Perl 5 is already good enough and will be so for the foreseeable future. We can evolve Perl 5 and gradually make it even better and more suitable for our needs, as we see these needs coming. There is no reason to break every last bit of compatibility, create an incredibly complex language which even experts find difficult to understand, and integrate every last feature from every other language in existence today, just because it is conjectured that some people may find it useful.

A gradual evolution of Perl 5 would be a better idea. Fifer will be a language of the present, instead of a very crude prediction of what new languages will look like 10 or 20 years from now. In twenty years, Fifer will probably be more similar to Perl 6. However, it will still be very different, as things in the software world don't always develop the way people expect them to. And it will also be able to run most of the Perl 5/Fifer code that has already been written (and possibly adapted to the new changes).

Let's continue to work on Perl 5 and just make it an even better language (and technology and culture) than it already is. What is for certain is that Perl 6 isn't better.

RSS Recent comments

16 Oct 2004 01:59 verbat

My feeling
Is that you don't understand perl6.

You really can't see why having named arguments is better than using @_ ?

You don't see MMD as useful so you don't want it. You don't want a seriuos OOP framework cause you don't have a clue on how to use it. perl6 regexen are something new (not harder then perl5's but new) so you'd prefer the others.

But imo this is just an example of blub paradox, is like writing "I mean, perl5 does not really need closures let's all use perl4"

16 Oct 2004 02:03 glane

second system syndrome
Although it's called perl6, to an outsider who occasonally reads the reports on Perl.Com, the perl developers seem to be suffering from "second system syndrome". That occurs when a successful project moves on to develop a major new release where they can "fix" all the mistakes of the previous project and expand into new areas.

It's often an expensive mistake.

16 Oct 2004 03:37 zentara

You didn't give enough emphasis on Parrot.
It's hard to "teach old dogs new tricks". I'm one of them. I've learned Perl5, and dread the coming change over. But I can see the benefit of switching to the Parrot Virtual Machine at www.parrotcode.org. The Parrot virtual machine, is sort of a virtual assembler which is cross platform. This will allow the programmer to think in new , cleaner ways about pushing data around with a processor. It is the future.

Perl6 will have a backwards compatibility mode for Perl5, and there will be nothing keeping you from using Perl5 for the rest of your life. Perl5 and Perl6 can be run on the same machine together. Perl5 will be around and will be continually developed for years. So don't worry about being forced into using it.

Perl6 ( and Parrot) will make it possible to write code which mixes languages in the same script, like Perl with some Python thrown in, or Python with some Perl thrown in.

Finally, there is nothing stopping you from making a separate branch of Perl6, and if people see it's benefit.....you may become the next Larry Wall.

16 Oct 2004 04:44 Avatar shlomif

Re: My feeling

> Is that you don't understand perl6.

You are right - I don't understand a great deal of the Perl 6 apocalypses and Exegesisa. And I'm not ashamed to admit it, because I know most other people don't.

> You really can't see why having named

> arguments is better than using @_ ?

Not really, no. What's wrong with:

my ($self, $name, $family_name, $street) = @_;

Besides, if we want to add these things, I don't think we should start with a clean page, but rather add them to Perl 5 incrementally while maintaining backward compatibility.

> You don't see MMD as useful so you don't

> want it.

What's MMD?

> You don't want a seriuos OOP

> framework cause you don't have a clue on

> how to use it.

Actually, I specifically said a better OOP framework is in order, just that it does not justify an entirely new language with . for dereferencing and _ for concatenation.

> perl6 regexen are

> something new (not harder then perl5's

> but new) so you'd prefer the others.

>

They're new and they are incompatbile. That's the problem.

> But imo this is just an example of blub

> paradox, is like writing "I mean,

> perl5 does not really need closures

> let's all use perl4"

Perl 4 was problematic from several reasons. Perl 5 is much better. However, nothing justifies Perl 6 right now, because Perl 5 is good enough.

There isn't a need to revolve Perl at the moment. You can add all these things to Perl 5 without revolving it.

16 Oct 2004 05:46 pwigren

It doesn't matter!
Most of the things you are complaining about doesn't matter because of Parrot. Parrot will let you use Perl5-modules in Perl6, Perl6-modules in Perl5, and even modules from Ruby, Python, PHP or any other language supported by Parrot in Perl5/6 and vice versa.

I think this is wonderful! You can go straight to the IMHO most beautiful language Ruby instead of Perl 6, and still use your old Perl-code with no need to rewrite.

16 Oct 2004 06:05 michal_321

Re: My feeling
%

> You are right - I don't understand a

> great deal of the Perl 6 apocalypses and

> Exegesisa. And I'm not ashamed to admit

> it, because I know most other people

> don't.

It's just Larry. That's the way he presents things. I personally think that he's got a really good grip on it.

I'd recommend reading Apos with Exegesisa companion.

> Not really, no. What's wrong with:

>

> my ($self, $name, $family_name, $street)

> = @_;

An easy one. To quote Larry:

Perl 5's subroutines have a number of issues that need to be dealt with. First of all, they're just awfully slow, for various reasons:

Construction of the @_ array

Needless prepping of potential lvalues

General model that forces lots of run-time processing

Difficulty of optimization

Storage of unneeded context

Lack of tail recursion optimization

Named params that aren't really

Object model that forces double dispatch in some cases

Quite apart from performance, however, there are a number of problems with usability:

Not easy to detect type errors at compile time

Not possible to specify the signatures of certain built-in functions

Not possible to define control structures as subroutines

Not possible to type-check any variadic args other than as a list

Not possible to have a variadic list providing scalar context to its elements

Not possible to have lazy parameters

Not possible to define immediate subroutines (macros)

Not possible to define subroutines with special syntax

Not enough contextual information available at run time.

Not enough contextual information available at compile time.

> Besides, if we want to add these things,

> I don't think we should start with a

> clean page, but rather add them to Perl

> 5 incrementally while maintaining

> backward compatibility.

Perl6 is a new language. Andf there will a backward compatibility mode.

> What's MMD?

Multi method dispatch.

See some (c2.com/cgi/wiki?MultiM...

> Actually, I specifically said a better

> OOP framework is in order, just that it

> does not justify an entirely new

> language with . for dereferencing and _

> for concatenation.

OK. But that's "syntactic sugar", that's what it is ;-)

> Perl 4 was problematic from several

> reasons. Perl 5 is much better. However,

> nothing justifies Perl 6 right now,

> because Perl 5 is good enough.

Mostly. But starts to be obsolete rig th now.

> There isn't a need to revolve Perl at

> the moment. You can add all these things

> to Perl 5 without revolving it.

No. Perl5 won't match capabilities of python and/or java in near future.

16 Oct 2004 06:14 cbraga

I've never seen such a stupid and short-sighted article before in my life
Cleary the author is a troll who never wrote a computer program certain that he wouldn't need "all this programming crap" for his "real job". That is, assuming he got a degree in something remotely technical, which I very much doubt. Go back to tech support buddy.

16 Oct 2004 08:51 acli

Re: My feeling

> % There isn't a need to revolve Perl at

> % the moment. You can add all these

> things

> % to Perl 5 without revolving it.

>

>

> No. Perl5 won't match capabilities of

> python and/or java in near future.

>

Now this is a mysterious statement. In what way is Java more capable than Perl5?

16 Oct 2004 09:10 alienscience

Perl 6 is needed
I've been programming perl for the last 8 years (maybe longer, I can't remember) and while I am very happy with the language I'm seeing it being displaced by Java in a very big way and perl is now becoming a niche language for sysadmins. I'm my opinion this is a shame because perl 5 is a very powerful language that allows a careful programmer to come up with very solid, maintable solutions.

However, perl 5 has issues (for some people) and perl 5 lacks some really cool features. I have played with ocaml and lisp and have been won over by the usefulness of language features that I didn't understand at first. Other perl programmers are raving on about ruby and like the consistancy of that.

Perl 5 is going leave the mainstream -- I am certain of this. Perl 5 + extras does not stand a chance. I would like to see perl 6 take its place as it is something that is developed by the community, moves language design forward and answers some of the criticisms of perl 5. Combined with the ecosystem that is parrot and the ability to share modules between languages, I am hopeful that this will actually happen or that a better language will evolve. My biggest worry isn't that perl 6 will be too radical, its that perl 6 will be too late.

16 Oct 2004 14:45 motivator

Re: My feeling

>

> Perl 4 was problematic from several

> reasons. Perl 5 is much better. However,

> nothing justifies Perl 6 right now,

> because Perl 5 is good enough.

>

i think you're ignoring the major point already made in one of the responses. you can use perl5 and perl6 on the same machine until the end of time, if you like, so what's the problem with creating perl6. just because you think perl5 is "good enough" doesn't mean perl6 isn't worth creating.

16 Oct 2004 14:48 mmlenz

perl 6.. day late.. dollar short
I wish perl was still a viable programming language. I've been doing nothing but perl programming (web application development) for the last 8yrs. I'm ready to say good bye. Maybe I'll come back once perl 6 is stable and attempts to offer stuff on the same playing level as Java.

I really think (as sad as I am to say that) that perl has seen its end in enterprise web application development. I think it comes down to perl's lack dependable frameworks. The ones that are out there, I don't even really consider all that professional. Mason, not a framework, you have to do 90% of the work yourself. Maypole, where is the documentation and have you looked at the templates? Dear lord. Another thing is finding people to hire to do the work. Its taken progressively longer everytime we've had to hire a new programmer. No one programs in it anymore.

I am lazy, i hate learning new programming languages. Java is bloated and slow and we're going to have to completely rework our architecture to support java. What other choice do we have? Right now it looks as though we'll probably move to Struts.

16 Oct 2004 14:49 CropCircleSystems

Re: I've never seen such a stupid and short-sighted article before in my life
i second that. i couldnt have put it better myself. this guy
obviously is an amateur perl tinkerer at best. while i agree
that perl5 is an awesome, powerful language with a billion
and one uses and years and years and years of life left in it,
but to ignore its shortcomings is plain ignorant. this guy may
hack USING perl, but he obviously has never hacked ON perl
(by which i mean modifying/extending perl itself), which i
cant say i have either, but then again you dont hear me
whining about things i dont understand, and claiming i know
how perl should evolve better than larry does. and while i
dont hack on perl itself, i have used perl enough to have
experienced and understand the shortcomings for which
people believe it should be overhauled rather than
augmented, and why it is loosing ground to some of
today's modern languages. perl6 will be sweet. i am keeping
an eye on it and will thoroughly study its once it solidifies
more/is released. and i will gladly spend company money to
have my programmers learning it on the clock. (i find that a
good programmer should always spend half or more of his
time learning, and enforce that with my team. otherwise
they get rusty, and/or only try and capitalize on what they
already know or get closed minded about what they dont
understand. <clears throat loudly while glaring at author of
said article>)

16 Oct 2004 15:02 CropCircleSystems

Re: My feeling

> Not really, no. What's wrong with:

>

> my ($self, $name, $family_name, $street)

> = @_;

well for one, you are copying variables when all you want to

do is label your parameters.

> Perl 4 was problematic from several

> reasons. Perl 5 is much better. However,

> nothing justifies Perl 6 right now,

> because Perl 5 is good enough.

"good enough"??? yeah. thats the attitude that promotes

greatness and makes things happen in the world. go back to

being a small cog of the machine to which you are a slave.

but seriously though, i agree with you that changing . to _

and -> to . was pointless, and i agree with you that it may

deserve a whole new name rather than saying its the 6th

major version of perl, as it is an entirely new language.

however, i believe the implications of the naming have

already been considered more than i am considering them,

and i really dont care what you call it. a rose by any other

name...

16 Oct 2004 17:35 Schwern

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.

learn.perl.org/library...

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.

search.cpan.org/search...

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.

* Rindolf

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.

16 Oct 2004 20:59 PubliusOvidius

This is wrong in so many ways.

I don't want to sound too harsh, but this criticism is misguided. OK, so he and a friend have problems understanding the Apocalypses. So do I. So do a lot of people. However, when I read Exegeses, all of a sudden, things make sense. The only reason I don't feel comfortable with Perl 6 is that I am not (yet) regularly programming in it. When people start to use it regularly, they'll appreciate its power. It solves many of the problems that are hampering Perl 5's growth.

He also points out that it's not backwards compatible with Perl 5. Ignoring the Ponie project for a moment, I have to ask "so what?" I can't put a Ferrari's motor in a Ford Pinto. That doesn't mean that there's something fundamentally wrong with Ferraris. If all you need is a Pinto, fine. Drive the Pinto. If you need a Ferrari, a Pinto won't cut it. I work on large scale systems that frequently butt up against the limitations of Perl. A Ferrari would be very handy.

If Ponie pans out, Shlomi Fish is dead wrong about backwards compatibility. If Ponie doesn't pan out, we can think "Perl 6 is to Perl 5 what C# is to Java." (Only more so and without the proprietary platform issues.)

And let's take a look at the comparison code snippet he produced (minus the curious formatting):

# Perl 5

my $is_ok = 1;

for my $t (0 .. 6) {

    if (abs($new[$t]-$new[$t+1]) > 3) {

        $is_ok = 0;

        last;

    }

}

if ($is_ok) {

    push @moves, [$i,$j];

}

# Perl 6

my $is_ok = 1;

for 0..6 -> $t {

    if abs(@new[$t] - @new[$t+1]) > 3 {

        $is_ok = 0;

        last;

    }

}

if $is_ok {

    push @moves: [$i, $j];

}

He states the the Perl 6 is "recognizable, but completely different!" I'm curious to know how he defines "completely different." The sigils are now part of the variable name, clearing up one of the greatest sources of confusion for new Perl programmers. The for 1 .. 6 -> looks different but it's hardly obfuscated. Ooh, and look! Fewer parentheses are needed.

He also complains about arrows being eliminated in favor of the dot operator. I don't understand his complaint here. It's such a common operator that Huffman encoding suggests that it should be shorter and, conveniently, there's already an operator that's practically an industry standard. How handy. Personally, I always thought the arrow operator was for C programmers who were used to dereferencing structs. The encapsulation violation this implies is a Bad Thing.

Frankly, I am solidly in the "we need a new Perl" camp. Of course, many argue that Perl 6 is too complex. However, when you look at the big picture of Perl 5 you could make the same argument ... until you realize that everyday coding tends to use an easy-to-learn subset of Perl. That's what we're going to see in Perl 6. The easy things will be easy and the hard things will be possible. Now that's not so strange, is it?

And looking at his follow-up comments, I noticed this interesting snippet:

> Not really, no. What's wrong with:

> my ($self, $name, $family_name, $street) = @_;

Followed by the question "What's MMD?"

MMD is multi-method dispatch. One of the serious limitations of Perl is its poor argument handling. By allowing multiple methods with the same name to take different arguments, you can automatically dispatch to the correct method and let the language take care of it, rather than force the programmer to write a bunch of bug-prone code to handle the dispatching. Frankly, I'm tired of fixing an entire class of bugs that languages such as Java or SmallTalk simply don't have. For someone who is writing a language critique to fail to appreciate such a fundamental feature speaks volumes about the quality of such critique.

Cheers,

Ovid

(And my apologies if my formatting is messed up. I've never posted here before.)

16 Oct 2004 23:38 aufflick

Here's a good refinement of Perl 5 OO syntax
And it's implemented for Perl 5 IN Perl 5:

reformed-perl

16 Oct 2004 23:42 imipak

Mixed feelings
Although this starts off sounding like a criticism of
Perl 6, please read a little further before deciding.


Given that I've never minced words when people
have made drastic API changes to other languages, I
don't feel I can exactly endorse the same thing in
Perl. Often, such changes aren't necessary, their only
function to beautify the language or to conform to
some (often transient) "ideal" in Software
Engineering. You could achieve exactly the same
effect by many other means.


I consider such practices "lazy" for two reasons.
Firstly, redesigning the language is a very small
portion of the work involved. The bulk of the actual
labour has to be put in by application developers,
who then have to divert time and energy from
improving their software to merely making it
consistant with the new environment.


Secondly, and perhaps more importantly, if the
language genuinely has enough structural flaws,
design errors and syntactical weaknesses that a
redesign is actually necessary, it probably indicates
that the foundations aren't holding up. In that case,
you can build what you like on the foundations and
it'll still not stand the test of time. Under such
conditions, it might be better to make use of your
experience but basically start from scratch.


Now we get to the real meat of this post. Although
Perl 6 shows some signs of being reworked (which I
freely admit I'm not crazy about), I'm not seeing any
huge changes. From what I understand, and from
what other posters have said, Perl 5 code will work
with Perl 6. The changes in, say, Java between the
alpha, beta, 1.x and 2.x releases, or between Python
1.x and 2.x were far more drastic and really did
break a lot of code. I'm not seeing that here.


As for the design documents and specifications -
well, nobody is ever going to agree on things like
that. I happen to like Z, but I can guarantee that if I
posted a Z specification to a public forum (unless it
was the Z newsgroup) fewer than 1% of those
reading it would understand it. Z maybe an
international standard, but that doesn't mean
anyone learns it.


Will there be a code fork, caused by Perl 5 vs. Perl
6? It is possible. Some people still write in the K&R
dialect of C, too. In fact, it could be considered a
failure, if code forks didn't happen. Think about it.
The only reason for everybody - every vendor, every
programmer, every reimplementor - switching is if
Perl 5 was inferior in every regard.


If there is a single area in which Perl 5 beats Perl 6,
then those catering to that area are going to stick
with Perl 5. Voila, code fork. But if Perl 6 beats Perl
5 on every imaginable test, under every possible
condition, then Perl 5 went down the wrong path
entirely. Sometimes that happens.


Far more often, programming languages evolve. In
the process of evolving, however, certain
compromises in the design occur. Usually, languages
gain strengths in areas that turn out to be often
used, at the cost of not being quite so good in areas
that aren't as useful. When this happens, there's
usually a fork in either the design or the
implementation, and different interest groups go
their own way.


In some cases, one of the forks survives and the
others die off. Of all the many hundreds of dialects
of BASIC, for example, only Visual Basic is much
used.


In other cases, forks evolve separately and
distinctly, catering to groups with so little overlap
that there is little reason for one fork to be preferred
overall. Again, using the example of BASIC, the
language is a design fork from BCPL and Fortran.
Thirty years of development has resulted in
considerable divergence. Fortran and BASIC quite
happily coexist today, in mainstream use, with little
evidence that either will "replace" the other. Even
BCPL still holds a corner of the language market.


Finally, I'd like to conclude that certain
evolutionary steps can be expected to die out.
OpenMP is no more likely to survive than any other
"parallel C" or "parallel Fortran" has in the past.
Often, such extensions are proprietary, non-portable
or simply unnecessary. If you can get about the
same results without an extension as you can with
the extension, unless there is a considerable benefit
in keeping it, the extension won't survive. The added
resources needed in maintaining the extension and
the code that uses it, not to mention getting
programmers over the learning-curve, are often
significant. If the total benefits are less than the
total costs, nobody is going to bother.


So far, the total benefits of each iteration of Perl
have been worth the costs involved in keeping up.
The only way anyone'll be certain this will be true of
Perl 6 is by seeing what happens. Even if Perl 6
catches on, it might never supplant Perl 5, because
different people will see different costs and different
benefits. As I said before, that could even be seen
as a Good Thing.


Interpreted languages are going through a
reneissance, with languages such as Perl, Tcl/Tk,
Python, Ruby, ML, Scheme and PHP carving quite
substantial markets for themselves. That won't last
forever, but for now, it's more than capable of
handling any changes Larry Wall might make.

17 Oct 2004 01:12 Schwern

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.

17 Oct 2004 07:48 fraktalisman

So should there be two versions of Perl?
I am personally quite happy with Perl 5, using it for web development, and still continually learning to use it and how to use it better.

I don't want to be forced to switch to Perl 6 just because it's new. Until now I didn't take the time to read about its new concepts and possible advantages. Maybe there would be a reason for me to switch to Perl 6.

Comparing the situation with Flash: although the current versions have great advantages, but I often used Flash 4 - for backward compatibility, but also because I'm still used to the program. It seems that it would be nice to be able to stick to Perl 5, and use Perl 6 where necessary.

Now 5 and 6 are not compatible? That would be a pity. There is so many working software written in Perl 5, developed, tested and corrected over the years. There is no need to change that. Keep it running! My conclusion: there needs to be a - quite long - time for transition, where both languages can and should be used. Thus, some kind of continuous development of Perl 5 will be needed even when version 6 is around. Is this any problem? Not necessarily. Webservers can be configured to recognize both version appropriately, I hope. Local computers likewise.

17 Oct 2004 08:11 perlvr

Re: My feeling

Honestly, I think PERL 5 is just fine the way it is. Yes, parrot is sexy, but I groaned when I saw the syntax changes. The old "for notation" has grown on me. And, in math, the "element of" symbol is always on the lhs. The new notation reminds me of my TI calculator which uses "store this into" rather than "store this in."

As far as speed is concerned, that's something that I don't care much about since it's "fast enough."

I recently wrote a custom COFF linker in PERL and it worked just great and more than fast enough.

My favorite function is pack and unpack and along with PERL 5 I'm quite happy.

If people want to use a different syntax, I have no problem with having them place "use perl6;" at the top of their PERL code. Otherwise, the PERL6 compiler, IMO, should be backwards compatible with PERL5 from the viewpoint of the user.

I like PERL because it's quick and I can rapidly prototype. If PERL6 adds baggage, then we'd want something like this: "use nobaggage;"

I program in C++ a lot and have just as many run time problems as PERL.

C++ programmers think they can save themselves with auto pointers, and the such, but at the end of the day, that sort of thing only leaves me with a headache and yelling at the people who use expections as a way to avoid real error checking.

%

> An easy one. To quote Larry:

>

> Perl 5's subroutines have a number of

> issues that need to be dealt with. First

> of all, they're just awfully slow, for

> various reasons:

>

> Construction of the @_ array

> Needless prepping of potential lvalues

> General model that forces lots of

> run-time processing

> Difficulty of optimization

> Storage of unneeded context

> Lack of tail recursion optimization

> Named params that aren't really

> Object model that forces double dispatch

> in some cases

>

> Quite apart from performance, however,

> there are a number of problems with

> usability:

>

> Not easy to detect type errors at

> compile time

> Not possible to specify the signatures

> of certain built-in functions

> Not possible to define control

> structures as subroutines

> Not possible to type-check any variadic

> args other than as a list

> Not possible to have a variadic list

> providing scalar context to its

> elements

> Not possible to have lazy parameters

> Not possible to define immediate

> subroutines (macros)

> Not possible to define subroutines with

> special syntax

> Not enough contextual information

> available at run time.

> Not enough contextual information

> available at compile time.

>

17 Oct 2004 16:06 gt3

Re: You've read the fantasy. Here's the reality.
Most people don't live in reality in general, why expect their opinions about programming to be based in reality

17 Oct 2004 20:12 mdnava

Re: Perl should be kept simpler
I think the article has some good points I Agree on like Perl 5 is complex enough to be making it worse, the sendmail analogy is perfect example of a software being replace by simpler apps, there should be a rule most programmers should remember: Keep it simple

In fact, I remember I stared at Perl for the need of CGI for the web but now I rather use an embedded language like PHP or ASP.Net for this job cause Perl is way too complex for some tasks (obviously more powerful, but in many cases unneeded).

In other hands, who cares if I don't understand at first Perl 6 (which in fact doesn't look this way), in most cases I didn't understand languages like C++ or Java when I first was them, but the best part was getting to know them and making my own libraries.

Backwards-Compatibility is maybe a "curse of software design" but not only programming languages have to be written from scratch, also in many cases the applications made with them too. I think there is something really wrong about the way we are getting programming languages if every time a major one comes up, is not compatible at 100% with the previous one. Maybe is something we should live with but it sure bites me.

I think also, that if Perl 5 can live on the same machine with Perl 6, we can have a powerful environment with more tools.

18 Oct 2004 02:04 imbaczek

If it's good enough...
...just use it. Nobody will force you to use Perl 6 and nobody expects you to use it.

Perl 5 will be here forever, and it's very likely that you'll be able to mix Perl 5 and Perl 6 together. Check out Parrot.

18 Oct 2004 06:24 egarland

Re: You've read the fantasy. Here's the reality.
Thank you for writing that, it saved me a lot of time.

I've done some XS work in Perl 5 and I have to say the parent post is absolutely correct, Perl 5 is straining against a horribly messy underbelly and the only reasonable way around it is to start over the way they are doing.

Proper threading is impossible to do gracefully with the current Perl 5 underbelly. Perl 5's threading is a mess. It's not safe to use in mod_perl. It's horribly memory intensive. It's cumbersome to use. Optimizing it makes you do really ugly things. Objects can't be shared (the data can but the blessing doesn't get copied into new threads.) The only method of fixing the memory problems that seems remotely possible is a copy-on-write scheme which, to me, doesn't fix much. A rewrite of Perl (the platform) is desperately needed.

I'll repeat what the parent said for good measure: Perl 6 will run Perl 5 code. Perl 6 (the platform) will be a good place to run Perl 5 (the language) code. Also, Perl 6 (the language) will be worth learning.

Changing -> to . is important. Most people who get to code in one language exclusively, don't get to code in Perl. Currently you have to retrain yourself to interperate ->'s as .'s or vice versa when switching to/from any other language. Switching that will help people who know other languages use perl and people who know perl use other languages. Perl has always tried to do that.

Being able to name and store regex's is important. All too often non-perl coders see a regex and run away from perl screaming. If we can name the regex with something describing what it does, it becomes much easier to read.

There are lots of other really cool things I see in Perl 6 (the language) that I really like. At first I didn't like the idea and I was angry they were changing it in incompatible ways. Now I'm happy they broke compatibility. The things that aren't compatible, needed to be changed.

I've been programming in Perl for over 10 years (started in 4 and moved to 5) and it's been my primary language the whole time. I've loved Perl 5 but I can't wait for Perl 6.

Bring on the changes. It's about time!

18 Oct 2004 08:06 ides

False
Just wanted to agree with most of all of the comments here. This article was not very well researched and leads people to believe the wrong things.

I confess to only skimming the Perl 6 works by Larry and Damian, but even with just a skimming I know most of this article is false and in some cases FUD.

I hope this author's lack of research and understanding do not end up hurting Perl as much as these types of things can.

Please everyone, do yourselves a favor and disregard this article.

18 Oct 2004 10:07 rwinston

This article is crap
Jesus. It's been a while since i have read such an unimaginitive diatribe from somebody who is patently dull and lazy.

Big yawns all round.

18 Oct 2004 10:10 tzz

Re: My feeling

> Now this is a mysterious statement. In

> what way is Java more capable than

> Perl5?

%

Introspection.

18 Oct 2004 13:59 drewman

Re: You've read the fantasy. Here's the reality.

> Changing -> to . is important. Most

> people who get to code in one language

> exclusively, don't get to code in Perl.

> Currently you have to retrain yourself

> to interperate ->'s as .'s or vice versa

> when switching to/from any other

> language. Switching that will help

> people who know other languages use perl

> and people who know perl use other

> languages. Perl has always tried to do

> that.

while i agree with you and the parent on every other point, this one seems ridiculous. I have developed intensively in c, c++, javascript, perl, and php and never had any problems switching from . to -> and vice versa. every language has features that distinguish it from every other language, and anyone who regularly switches between languages learns to adapt. if they are concerned about making things easier for programmers from other languages, why _? no other language (that i know) uses _ for concatentation. ||, +, and . are all used for concatenation by other langagues, why not use one of those? And if perl has "always" tried to help users of other languages, why is there still no switch statement? (actually, i suspect the parent's post already answered that for me. sorry. just one of my perl peeves.)

that said, i am really loking forward to perl 6; the perl langugage is long overdue for an overhaul.

18 Oct 2004 14:12 Avatar guidod

no excuses
As the discussion went, I think that betting on a parrot or some kind of multi-language approach is a false excuse. As already said, in a multi-developer environment there will be a standardization on source style even going beyond basic syntax elements. Anyway, there is a saying that for some new technology to find a breakthrough it needs to have *two* additional useful features over existing ones. And sure it does not make it easier to add some pain to the mix like some syntax that looks familiar but which means a different thing now. So there is still the argument why to do such a thing when one can have just as well a feature upgrade on the good ol' stuff.

18 Oct 2004 17:45 tangent

Re: perl 6.. day late.. dollar short

> I think it comes down to perl's lack
> dependable frameworks.

Apache::ASP (apache-asp.org/).

> Another
> thing is finding people to hire to do
> the work. Its taken progressively
> longer everytime we've had to hire a new
> programmer. No one programs in it
> anymore.

Translation: we're unwilling to train people.

Though I must say, if you use Apache::ASP, retraining a VB ASP user shouldn't be a major deal.

19 Oct 2004 08:43 kreiger

Re: My feeling
The language is "Perl" or "perl", not "PERL". It is not an acronym.

22 Oct 2004 00:46 mwal

Perl is dying, reinventing it is the only solution
There are lot of people out there that like me used Perl 5-10 years ago, but stopped using it due to is write-once-read-zero times approach.

Understanding old Perl programs has always been awful.

If you look at usage statistics, Perl is today is way behind modern languages like Java, C#, VB.NET, PHP. It has been marginalized.

So inventing a new simpler Perl is the only solution, otherwise Perl will be totally dead in a few years.

22 Oct 2004 08:37 hummassa

Re: My feeling

> The language is "Perl" or "perl", not

> "PERL". It is not an acronym.

>

You mean it's not Practical Extraction and Reporting Language?

24 Oct 2004 01:02 sholden

Re: My feeling
No it's not as a cursary look at the perlfaq documentation would tell you.

24 Oct 2004 01:07 sholden

Re: Perl is dying, reinventing it is the only solution
Care to site your mysterious usage statistics Or do you just make it up as you go?

The freshmeat browse by language appears to show a different universe of software to the one you live in.

30 Oct 2004 12:33 Juerd

Re: My feeling

> but seriously though, i agree with you

> that changing . to _

> and -> to . was pointless

The string glue is now called ~, not _.

-> to . makes sense in many ways. Dot is easier to type (it's only a third of the key presses), and is nicer when used without a LHS. Besides that, -> is now a neat new operator that you will learn to appreciate. It creates a closure with named parameters, and is not just syntactic sugar for loops.

The underscore is a great tool for telling apart people who read some early documents and couldn't get over the initial shock and people who are really interested in the new language.

04 Nov 2004 04:15 moea

Re: perl 6.. day late.. dollar short

> Java is bloated

> and slow and we're going to have to

> completely rework our architecture to

> support java. What other choice do we

> have?

Python?

Bloated? Nope

Slow? Nope

as powerful as java and perl without the performance issues, and the ridiculous syntax, respectively

05 Nov 2004 10:38 mathieur

Re: False

> Just wanted to agree with most of all of

> the comments here. This article was not

> very well researched and leads people to

> believe the wrong things.

>

> I confess to only skimming the Perl 6

> works by Larry and Damian, but even with

> just a skimming I know most of this

> article is false and in some cases FUD.

>

> I hope this author's lack of research

> and understanding do not end up hurting

> Perl as much as these types of things

> can.

>

> Please everyone, do yourselves a favor

> and disregard this article.

I would be happy to follow your recommendations.

But why one should believe you more than the

author of the article? At least, he brought

arguments. You did not.

05 Nov 2004 10:46 mathieur

Re: Perl is dying, reinventing it is the only solution
Sam already pointed out the strange usage you do
of statistics.

But I'd like to point out that
write-once-read-zero approach is more a matter of
developer than language. The fact is that perl
allows developers to do write-only programs. But
are developers forced to do that with perl? How
so?

06 Nov 2004 11:59 hebble

Re: You've read the fantasy. Here's the reality.
MUMPS uses underscore for concatenation. Which, IMHO, is a good enough reason to be skeptical. :)

08 Nov 2004 07:25 ides

Re: False

> I would be happy to follow your

> recommendations.

> But why one should believe you more than

> the

> author of the article? At least, he

> brought

> arguments. You did not.

I didn't feel the need to argue against mostly incorrect facts. His arguments are ok, it's just that all of them were refuted below, and aren't even issues in Perl 6. Everything he stated is already being taken care of.

His article is like arguing about the proper way to get Bush elected, a week after the race is over and having Bush win. My point in commenting was I wanted everyone to know that the "issues" he brought up are not in fact "issues".

19 Nov 2004 07:04 apag

Here's a tip on writing better Perl5:

  MOVE_CHECK: {

      for my $t ( 0 .. 6 ) {

          last MOVE_CHECK

              if abs( $new[ $t ] - $new[ $t + 1 ] ) > 3;

      }

      push @moves, [ $i, $j ];

  }

Cheers.

19 Nov 2004 07:57 apag

Re: perl 6.. day late.. dollar short

> Another thing is finding people to hire to do
> the work. Its taken progressively
> longer everytime we've had to hire a new
> programmer. No one programs in it
> anymore.

Start hiring people, not technologies.

> I am lazy, i hate learning new programming languages.

Maybe you should. Good programmers learn a new language every year or so and write a piece of non-trivial code in it, just to keep sharp. If you don't know at least a half-dozen very dissimilar languages (no, Java, C, C++ and Pascal do not qualify as different, they're all ALGOL descendents) then your programming horizon is pretty narrow. You should at least know declarative and functional programming besides imperative. (OOP is a style on top of the programming paradigma, not a paradigma of its own.)

19 Nov 2004 09:18 apag

Re: Perl is dying, reinventing it is the only solution

Just to reinforce what has been said, I've never had any trouble re-reading my old Perl code, except when I mucked with overly complex data structures I didn't document. The code itself has always been a downright pleasure to read. I can't say that about Java. But then, I spend a lot of time actually using the linguistic freedom Perl grants me, trying to express things in such a way as is closest to how I think about the problem I'm solving. I don't just throw down the first construct that comes to mind. I also spend a lot of time arranging and rearranging code to properly divide it into self-sufficient functions and modules that do everything they should, but not more.

I see a lot of code in all kinds of languages that is horribly written, because the authors seem to simply have taken the first thing that came to mind which they thought would work and then ran with it. Too little abstraction, too much abstraction, bizarre distribution of responsibilities — most code is a mess. Questioning your first approach before you start and then questioning your chosen approach as you go about, breaking the problem down properly, possibly over and over again as you learn more about it, is vital. Refactor mercilessly or choke on your own spout.

Now Perl does not protect you from yourself as other languages try to. As a result, people hurt themselves. It's a poor craftsman who blames his tools, though. Most other languages “protect” you from expressing yourself too well, also. As someone who is extraordinarily particular about concise and coherent expression, I deeply resent that. And even so they still can't prevent +42 pretzel logic of extreme perplexity, as anyone who has seen large VBA macros can testify.

19 Nov 2004 09:23 apag

Re: So should there be two versions of Perl?
But there's noone forcing you to use throw Perl 5 off your system to install Perl 6. The two can happily coexist, much like you work with Flash 4 at the same time as with newer versions.

23 Nov 2004 22:47 HectorLuis

A few comments
a) No one Understands Perl 6.

Who you mean by `No one'?. If no one understand

perl 6, no one will ever program in perl 6. I see some

ppl programming with perl 6. So the sentence: No one

Understands Perl 6 is false.

b) Perl 6 is not Backwards-Compatible with Perl 5.

Why it has to be Backward-Compatible?.

If you think perl 6 as a new programming language,

then, tommorrow you will pretend that C would be

compatible with intercal.

If you think perl 6 as a new version of perl, then you

have to analize one thing (maybe more):

1) You will have to rewrite all your piece of software,

because of Perl 6?.

c) Perl 6 is too Complex.

Maybe .But even Lisp is complex. And there's a lot of

people programming in Lisp.

You have to define the word Complex. And then ask

yourself: This complexity is always bad, or have some

good stuff?.

d)Perl 6 is the wrong thing at the wrong time. Perl 5 is

already good enough and will be so for the

foreseeable future.

Well. There's something interesting about that.

If Perl 5 is good enough, then you can keep

programming in perl 5. If you want to continue

developing perl 5 you can do, too.

The other thing... Perl 6 is the wrong thing .... time.

Are you sure?. Why do you said that?

Follow me:

If all people program in C. C is good enough. Then

why to develop another Programming Language?.

If we decided to develop another Programming

Language, then we have to have a good motivation,

or reason. So, Perl 6 is only a new syntax, and a lot of

crap, or maybe is doing things that improves and

makes perl a better language?.

If Perl 6 is completely study, no one programs (really)

in Perl 6.. so larry would stop developing Perl 6, no

one will ever program in Perl 6, and everyone will start

programming (or continue) in perl 5.

But, if Perl 6 is better than perl 5 in some aspects, and

one or two brains understand it, and exploit it, then

Perl 6 would be the better solution to one problem.

As a final conclusion, you don't have to think about a

programming language, as a solution for every

problem. You have to think about it, as another way to

do things.

I'm sure that Perl 6, even if few ppl understand it,

would be the solution for a lot of problems.

09 Jul 2006 12:54 Jedai666

Re: So should there be two versions of Perl?

Even better, the interpreter for perl6 will silently run Perl5 scripts (the perl6 mode require a "v6;" at the beginning of the script) and you'll be able to use Perl5 modules in your Perl6 scripts.

Contrary to the objections of the author of this article, Perl 6 won't really break compatibility, it will just offer a much better and much clearer (function signature... if anyone here thinks the Perl5 model is correct I would like to know his arguments ?!) way to write your Perl script (yes, the Perl 6 scripts give a very perlish feeling, just check Pugs for examples).

--

Jedaï

06 Jan 2007 22:27 perlysoames

Re: My feeling

Well, we're in 2007 now. Perl6 still isn't finished and if you take a look at the discussions it pretty obvious that it has a loooong way to go. The people working on it (at least some of them) are pretty smart -- that they can't make progress is an indication that the language is too complicated and early decisions were ill-informed.

No one wanted parrot, we wanted simple, well-understood, mainstream language features like functions with named parameter lists.

Against my better judgment, on the advice of a true believer I've been waiting five years for Perl 6. No more. Larry Wall promised us something by Christmas but all we've had is silence.

It's time to throw in the towel guys. Cut your losses, add a few badly needed features to Perl 5, call it Perl 6, and be done with it. I wish I could make this come across better; the Perl 6 people are a bright bunch trying to do a great thing, but it just isn't happening and there comes a point when a change in course is necessary.

23 Mar 2007 22:00 FernandoGonzalez

Re: My feeling
Yes, it does have a long way to go but consider where it's heading. Some of the things that will be incorporated into the language are still being researched and developed. Make no mistake, when it's done it'll be the most advanced language ever seen.

"Will it be complex?"

Sure, some things will be different. But as many of you have pointed out, writing some real apps with a language straightens out all the kinks in your brain, or at least, goes a long way.

Take Haskell, a very powerful language with which the Pugs perl6 interpreter is being built. Oooh, monads, type classes ... Believe me, that stuff is scary at first, especially with all the people going around whining, "What are monads? What's category theory? Do I need to study math to code?". Just write some code. No math required.
Monads: no big deal. The let you keep track of what's going on and when. Type classes: you'll love these, they're a nice generics mechanism. Believe me, you'll get it and you'll love it.

The clarity and coherency of Haskell's design will shine through after an indeterminate number of lines of code.
I suspect the same will happen to those choosing to move to perl6. Reading a spec 20 times won't make you grok any language. It's mileage on the keyboard that really counts.

"So, uh, will it be complex?"

No.

The whole point of the new language is to take what was perl5 and make it cleaner, more powerful and beautiful.

"Should I wait for perl6?"

What the Hell? What kind of self-respecting hacker waits for anything?

You've got perl5, right? If you like it, use it. If you think it should be better, contribute.

As for perl6: If it's taking too long for you, go to the pugs website and lend a hand.

Simple. If you don't contribute, don't complain. Perl can be what you want it to be.

Fernando

03 Apr 2007 10:44 niravdani

OK, now talking about some real numbers
Shlomi Fish, I don't use Perl but you have pressed very sensitive nerve of many Perl advocates.

Anyhow, here are some real-time statistics from a premium job board.

Java : 1 - 30 of 16216 jobs

C# : 1 - 30 of 6625 jobs

.NET : 1 - 30 of9080 jobs

Perl : 1 - 30 of 5368 jobs

Python : 1 - 30 of 1022 jobs

Ruby: 1 - 30 of 439 jobs

Ruby on Rails : 1 - 30 of 223 jobs

TCL: 1 - 30 of 407 jobs

Well, Perl is still holding up good but who knows for how long.

17 Apr 2009 23:59 sehe

Erm... subjective update: 2009 now, in my humble experience there is still not much of a Perl6 that I call tangible. I'm inclined to start saying... vaporware. (Debian doesn't know anything about pugs, rakudo or other scary vegetables. Only parrot has certainly gained some audience!)

9 years in the making... i'm still happily (ab)using perl5 when the need arises (seldom).

14 Jan 2010 19:49 pcg1

it's definitely vaporware.

hwoever, perl5 has gained momentum and has a unified event library (AnyEvent) async I/O (IO::AIO) and stable threading (Coro).

in the meantime, perl6/parrot have basically dropped all of their original goals. new goals: get the mark&sweep stop-the-world garbage collector working. make perl6 rpograms not crash after 100 lines. announce win when perl6 reaches the just-100-times-slower-than-perl5 mark and so on.

basically, it was all hot air.

30 Jul 2010 15:02 Avatar dskoll

I think Shlomi Fish was on the mark. Perl 6 is shaping up to be a Chandleresque disaster and a poster-child for Second System Syndrome.

Screenshot

Project Spotlight

naken_asm

A microcontroller assembler.

Screenshot

Project Spotlight

Mutt Folder List

A mutt patch that adds a sidebar showing all mail folders.