Critique of Where Perl 6 is Heading on Freshmeat.net

[cyocum]

Hello and greetings venerable Monks of Perl.

While I was crusing Freshmeat today, I saw an interesting article right at the top. It is entitled Critique of Where Perl 6 is Heading.

The author's main thesis is that Perl 6 is not needed at this time and that Perl 5 can be evolved into Perl 6 rather than having a revolution into Perl 6. I am not quiet sure wether to believe him or not but I thought it might be interesting to open the floor on his article.

[rob_au]

Shlomi Fish, the author of the Freshmeat article, is a long time critic of everything in the world of Perl. Previous topics which garnered discussion and critique from this author include Perl documentation and Perl 5 development efforts, the latter of which was manifest in a discussion of "Rindolf", a proposed language branched from Perl 5 which the article author sought to develop.

My thoughts - Take everything with a large dose of salt.

[shlomif]

Well, I only criticized the Perl documentation as part of my analysis of the usability of the Perl online world to newcomers, which was pertinent at the point. I never criticized the Perl 5 development efforts. Rindolf was meant as an anti-thesis to Perl 6, but I stopped thinking about it after I realized Perl 5 was pretty much OK for me. The article in question is based in part on a the Philosophy section of the Rindolf spec.

Other than that, I like Perl a lot and am highly appreciative of the people who contributed to it so far. I also contributed some of my own things to Perl or otherwise, so I need not be dismissed as a free eater.

Feel free to take what I write with a grain of salt (it's probably a good idea to apply it to everything I read.) But don't dismiss it just because I wrote it.

[hbo]

But don't dismiss it just because I wrote it.

I'm more likely to dismiss it because I lived through the Perl 4 to Perl 5 transition. There were a lot of the same fears expressed then about the continuity of Perl, and the "unnecessary" new features and broken syntax in the new version.

The leap from Perl 4 to Perl 5 was a long one, in time, space and imagination. I was at the LISA conference where Tom and Larry gave a series of talks on the upcoming Perl 5 language. Without having the need to actually write code with the new syntax, I found it difficult to comprehend what the heck they were talking about in those seminars. I came away feeling fairly uneasy about the direction that Perl, one of the primary tools in my sysadmin kit, was taking.

It turns out, in hindsight, that I had little to worry about. Perl 4 didn't vanish when Perl 5 hit the streets. My "pink camel" kept getting more and more frayed, while my "blue camel" stayed fairly pristine. Gradually, I cracked the latter to look up this or that new concept, in my spare time. Finally, I took the plunge on an object oriented module or two. By that time, Perl 5 code was really taking off with CPAN, and I just couldn't ignore the wealth of code in my day-to-day work. So I finished the transition from Perl 4 to Perl 5. I can't say that it was painless, but at least I wasn't forced through it on someone else's schedule. And when I finally made the jump, it was so I could get something in return: use of all that free code.

In your article, you acknowledge the similarity in the two transitions. You attempt to differentiate the two by stating that the redesign of Perl 4 was justified because it ".. would make Perl more up-to-par with the powerful languages of then and now .." This is correct, but you draw the wrong conclusion with respect to Perl today. Computer language theory and practise have come a long way in the 10 or so years since Perl 5 was released. The radical nature of the changes Larry is proposing for Perl 6 reflects this progress. At the time Perl 5 was discussed at LISA, I had no clue what OO programming was for, so I couldn't understand, let alone see the benefit of object oriented extensions to Perl. By the time I took up OO Perl 5, I had learned Java, which gave me more of a clue in that regard. Most of us are in the same boat with respect to the many new features of Perl 6. Though I can't be certain, I suspect I will feel the same way about some of those features, once I've learned them, as I did about Perl 5 objects. The point is, I can't predict which of those unfamiliar features will fit the bill in the future. Neither could I do so with the then unfamilar features of Perl 5.

You also say that ".. the Perl "market" of programmers that can learn it is much more saturated today than it was when Perl 4 started." To the extent that this argument isn't irrelevant, it tends to support the idea that the Perl 5 to Perl 6 transition will be smooth and slow. The more source code written in Perl 5, the longer that language will live on. In other words, relax. Perl 5 isn't going anywhere.

[steves]

I'm curious why you don't seem to see Ponie as that Perl5/Perl6 bridge you seem to allude to. Or is it just that you fear that Perl6 will stop things from progressing down the Perl5 path? I am a 5 year Perl programmer and also have some concerns about total abandonment of Perl5, since we have a significant Perl5 code base. But the reality I see is a bit different (perhaps tainted by similar large rewrite experiences in other software areas). I see Perl6 as having to start anew to offer the big changes seen as necessary by the Perl community. I don't see it being widely used for a while, which would mean that the community would do what we'd expect and provide suitable bridges and migration paths. I also see that the move on all fronts towards VM run-time environments means that as we move towards Perl6, another change is taking place that makes the actual languages you use and mix in a given environment start to become less important. In the end, I'm not sure the migration scenario ends up all that different from what you lay out, except for the fact that it starts with two distinct entities, rather than starting with the idea of building on one. There are previous models for this sort of approach that prove it can work and migration can be less painful than it seems when that first divide is presented.

I'd be interested to hear you elaborate on your thoughts here. At the rate offshoring is going I might be lucky to be programming in any language in 2-3 years. ;-)

[pg]

"Perl documentation"

I almost never read any Perl book, so I have the right to say that, overall Perl documentation is very good, I had no problem to learn the language by reading documentation.

However some of the modules are poorly documented, this includes some of the very popular modules. A typical example is Tk.

[Ovid]

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 acceptance.

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 Ferrari's. 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?

[zentara]

Yeah, I encourage the Perl experts here to get over to freshmeat, and stick up for Perl6, this guy is just spreading FUD.

[pg]

I can see the real possibility that Perl 6 and Perl 5 will co-exist as two different languages for quite a while in the future. Perl 5 has its strong selling point for certain application areas, that is exactly why, as a mainly C and Java prorgammer, for certain things I always choose Perl.

[perlcapt]

Even though I am far from being a computer linguist, I can see the need for Perl 6. If Perl 5 was syntactily as pretty as Python for doing OO programming, I wouldn't be building a event driven application using Python (and having to learn Pythons's very wierd excentricities most of which come from it's lack of value assignment.). I have written tens of thousands of lines of OO-perl5, but am embarassed to pass off maintenance of this code to a non-Perl programmer.

Perl 6 syntax is far more elegant. This is important. It may be fun to write obfusticated code, but applications that require maintenance should be easy to follow. (No, I'm not a COBOL programmer ;-) I mean, easy to follow by another programmer.. who may actually be me looking at my own code two years from now after having done a dozen other projects in between. H___, I have trouble recognizing my own English text as written by me, years later.

Perlhaps, if and when Perl6 is developed and released, it will be called something other than Perl! Stranger things have happened.

[steves]

Interesting tangent about syntactic elegance ... I have not seen enough differences in Perl6 to say it has significant syntactic elegance over Perl5. Can you point out some specific examples?

You mention COBOL which I had the (mis)fortune of getting paid to program in for a short time back when I was a college intern. In addition to liberal GOTO use, the code was peppered with ALTER statements, which is COBOL's way of writing self modifying code. So, far from being elegant to maintain, it was a syntactically pleasing maintenance nightmare I inherited.

After that I worked on some easy to maintain C, then C++, then C code. C is really only a step or two above assembler if you look at it honestly. The reason for the ease of maintenance had less to do with the language than it did with the design and with the logical way the problems were abstracted and factored down to interfaces.

So I'm not sure I believe that syntactic changes will make a huge difference, although I agree with you that coming more towards that Java-like middle ground syntax helps those less capable programmers pick things up faster.

Then there's the Java code I inherited that had one method named main ...

[pg]

I think, almost everyone of us at least had the feeling once that, to patch a software too often, you rather just redo it.

Perl 5 is an elegant language, even today. Its simpilicty and high performance is sort of fatal attraction for everyone.

However during those years, the programming world has largely changed, the need for Perl to either evolve itself or jump to Perl 6 is quite clear. My personal view is that, to patch is not the way to go, although may work for a while, it will not last too long.

[archen]

I think part of his argument was that the change in Perl6 is too drastic. I'm sure many like myself got into Perl and like it because it is what it is. I'll be the first to admit that Perl5 has problems. Personally I think OO programming in Perl is a disaster. Using objects is great, but coding them seems much more messy than C++ IMHO.

So yeah I'd like to see that change, but do I want the entire language to be overhauled? Not really, and I see a LOT of new things in Perl6 that I just don't like. I'm sure many of us are concerned that there may be a crossroads after Perl6 is released, where Perl5 is on the decline and Perl6 is the future. If it comes to that point for me, I will be programming in Ruby from that point forward.

[merlyn]

Perhaps what you keep forgetting is that what you're reading is the changes. The core of the language, that you have come to appreciate is still there. You'll still get an autovivified hash five levels deep from a three line diamond-split-assign-plus-equals loop. Really. Don't get hung up on the differences. The core is still there. Life is still good.

[fraktalisman]

I think it's quite important that both versions can co-exist for a longer time. There is so many working, tested Perl 5 code that has been developed over years. No need to abandon it just because Perl 6 is new. New projects can be started in Perl 6. Computers and webservers need the possibility for both code to be run, and some updating and bug-fixing of Perl 5 might need to go on for a longer time.