Perl6 for Mortals

horos1 writes: "Hey all, I just ran across an article over at O'Reilly - Perl 6: Not Just For Damians which covers a lot of the negative commentary posted by slashdot on perl6 'featureitis'. Very interesting read, and IMO makes a hell of a lot of sense."

Comments

Re:Perl 6 is the way forward.

[TomK32]

I think the reason why people don't like progress/evolution is that they are used to the old things and don't want to learn something new. It was hard enough to get used to the old Perl syntax which is allready strange enough...

Re:Is it really. - FUD

[Pengo]

Hmm.. I hear the same fud when people talk about using Python for simple , quick and dirty scripts, etc. Just because Python gives you the ability to create classes , as well as advanced OOP features for a scripting language, doesn't mean that you have to use it at all.

I have seen and written many useful python scripts that do nothing more than impliment one function and the rest is just run out of the main.

With Perl moving (IMHO) maybe it's worth putting a few Python books aside and giving perl another look. (I haven't touched it for 2-3 years since I started doing Java programming and discovered python).

But these features are only as complicated as you force them to be.

BTW, Java can be as fast, if not faster, than perl for many many tasks. It all depends on how you write the code. Bad code can be written in any language. But frankly I wouldn't write Perl code where I would use Java, as I don't do that with Python. Like trying to use Bash scripts where perl / python would be needed.

Pros and Cons of Perl

[lkaos]

To me, perl seems to have so many good points but at the same time seems to have a bunch of bad points.

The great thing about perl is that you can do anything in it. It also provides a good mechanism to abstract high-level concepts from the end-developer. The fact that it also provides low-level interfaces allows for one of the most flexible languages that I've ever used.

The problem with perl is that it is bloated. IMHO, a good programming language is simply, yet eligant. There should not be five ways to do something. There should also not be duplicate operators that accomplish the same purpose.

Operator overloading is one of those dangerous areas of C++ because it used improperly, it can create code that is unbelievably mantainable. Unless strict standards are followed when developing perl, perl is almost doomed to be horribly unmaintainable.

Even with all my criticisms, I would still use perl any day to lisp... It's great for little scripts. Perl6 seems to be moving in a general direction to make code even more unmaintainable.

Re:Pros and Cons of Perl

[Piers Cawley]

Now there I have to disagree with you. I think that the changes in Perl as we move to Perl 6 are going to make it easier to write clearer code. The new function definition semantics for instance will move all the code for dealing with function arguments out of the body of the function, so someone reading/maintaining that code can concentrate on the meat. Replacing $self->foo with .foo is nice too. The emphasis gets shifted to the things that are important.

Of course, many of these tools will allow criminal bastards who shouldn't be allowed anywhere near a production codebase to perpetrate monstrosities. But they can do that already in any language they choose to pollute. And Larry has been making noises about allowing folks to write their own versions of things like strict, which, when taken hand in hand with the more accessible parser should mean that sites that want to can enforce their own rules for coding.

If you want to be good, Perl 6 is going to let you be better.

Re:Is it really.

[ajs]

Now can you please tell me why the fsck do I need a full-fledged object-oriented language to write scripts for cron jobs and CGI?

You don't. So don't use objects.

I agree with most of your response, and am happy that someone was so level-headed about it. However, I write cron jobs all the time that use LWP, which would be a major pain if it were not OO.

• 
  my $ua = new LWP::UserAgent;
  $ua->timeout(10);
  my $rq = new HTTP::Request('GET','http://x.y.z/');
  my $rsp = $ua->request($ua);
  die "$0: x.y.z is down!\n" if $rsp->is_error;
  

The bottom line is that TMTOWTDI.

Re:Perl 6 is the way forward.

[Skald]

Why is it that people dislike change (read: progress) so much ?

Why is it that people who want to change things inevitably choose the label 'progressive'? ;-)

Perl isn't perfect, nor ever was. But that doesn't mean that any change is a good change. Not to say those developing Perl have made mistakes before... I'm not that bold... but let's just say that indirect object syntax was a rather dubious feature. :-) And prototypes are... well... broken. Pseudo-hashes really could have been done a lot better. Going way back, was making $a and $b special variables for the benefit of sort() really a good idea?

If you don't like a particular feature of the language don't use it.

Some of the changes you can indeed ignore... and most Perl people are pretty tolerant both features they don't use and ambiguity in their conceptual model of the language. You don't have to fully understand Perl to use it effectively... which is good, because very few people understand it fully.

Some of the changes you can ignore at the cost of some effort. The dot-operator nonsense falls into this category. Yes, they're fixing something that ain't broken, and trying to appeal to the sensibilities of people from other languages at the expense of veteran Perl hackers. But Conway has a good point. In Perl 6, you can redefine operators. This means you can have your -> and . operators back to 'normal' without much effort.

Of course, if you thought tie() made things hard to read, this and the Unicode support could wind up producing not only different dialects, but different languages. But that's another story.

After all, the motto of perl is 'there's more than one way to do it'

That motto should properly end, '...except when there isn't.' Perl presently has reliable destructors, but circular references are the responsibility of the programmer, and may produce a memory leak if you're not careful. Soon (if all goes well), circular references will be garbage collected, but we'll lose reliable destructors. Either way, not everyone was going to be happy.

Pardon me for cutting this short, but I have to get back to work. Suffice it to say, there are good reasons to be excited, but many of people's concerns are legitimate too. There is both opportunity and danger in change.

And I bet most of the moaners and whiners never wrote a line of open source code in their lives

Would their arguments be less valid if they hadn't? Would they be more valid if they had? This is argument ad hominem, and makes no interesting point.

Re:Filehandles

[Piers Cawley]

What version of perl are you using? In 5.6.0 and later

open my $fh, $file or die;

will give you a nice shiny, lexically scoped filehandle.

And yeah, $| = 1 is a historical PITA. It's going away in Perl 6 though. Hurrah!

Re:Filehandles

[mrpotato]

my $fh = open $file or die;

That works well with Perl 5.6...

'$| = 1' to autoflush a stream is ugly

Then use the full variable name? $| is in fact a shortcut for $OUTPUT_AUTOFLUSH (just make sure you Use English;)

I really don't see what you are complaining about, all you want to do is there, right here right now.

Perl going the way of C++

[mikec]

Perl6 suffers from the same problem that C++ has had over the years. In both cases, people tend to look at lots of tiny examples and come up with cool ideas to make things "nicer" for that example. The problem with this approach is that there are a very, very large number of cool ideas that make one situation or another "nicer." So lots of them get stirred into the mix. Adding two or three hundred cool new features to each version makes for a very complicated language after a few versions, especially when they interact and get used in unexpected ways. This is exactly the problem that C++ has had over the years, and the reason that other languages (Java, etc.) have gained in market share.

So, here's what will happen. Perl gurus will follow along. After all, Perl6 isn't that much more complicated that Perl5. Incrementally speaking, it's not too bad. But more and more newcomers will go with something a lot simpler: Python, Ruby, or the Next Big Thing. Why? First, if you look at Perl6 from ground zero, it is extremely daunting. The Perl6 Camel book is going to come in three volumes if it tries to maintain the same sort of coverage. Second, the design of a lot of Perl6 will be inexplicable except to people who know Perl5 and understand the history of the language. Finally, new programmers, especially good ones, want to really understand their tools from the inside out. They don't take kindly to the idea that they should learn 10% of the language, start using it, and catch up with the experts in a few years. So, over time, interest in Perl will dwindle. The old timers will retire or go into management, the newbies will be using something a lot simpler and more elegant. By the time Perl8 or Perl9 roll out, no one will care.