One of the problems with people's impression of perl6 is that nobody pays attention to the things that are the same. All the procedural bits of perl5 are still there. Most perl6 will look mostly like perl5, with little differences, and mostly ones that don't effect how you think. $foo[5] becomes @foo[5]. Big deal. Keep on writing perl6 the way you wrote perl5, and you'll produce perfectly good perl6 code. OTOH, when you want to write things like if (any(@foo) == 5) {...}, they're there for you, as is if (5 < $x <= 10) {...}.

There are bits of perl6 that are probably overdesigned for most purposes -- but they're nice to have when you want them there, and when you don't want them there, they stay out of your way.

One of the problems with people's impression of perl6 is that nobody pays attention to the things that are the same. All the procedural bits of perl5 are still there. Most perl6 will look mostly like perl5, with little differences,

But the differences are important and there are *many*! Sure, I might need only a few relatively minor changes to *write* perl code that runs on perl6. But I (and many many others) need to *read* code too. The only people for whom your argument works are people who may need to *write* perl6 code once in a while. Once a shop decides to switch to perl6, everyone needs to learn the perl6 language (not just the minor syntax differences with perl5). It will be no less a leap than a shop switching from Perl to Python or to Ruby (and may even be harder just due to the perceived similarity).

But I (and many many others) need to *read* code too.

You learned how to read Perl 5. You learned how to use all of the libraries you know how to use. Heck, you either learned how to read the indentation, naming, idioms, and commenting style of all of your co-workers -- or you came to some agreement on a shared style.

What prevents you from doing the same thing here?

My personal view is that Perl 6 represents a case of second system effect. That opinion may be right or it may be wrong. It looks like it will be years before anyone can say, and that is an issue in itself. Another take on SSE

Exactly,

That's the whole point of this effect, Multics was so many years in preparation... and perl6 is positioned to do the same

OS/2? I remember looking at OS/2 just after Windows 3.0 came out. I liked it, even though it took 5+ minutes to boot. The reality was that I had already bought into the whole 3.0 fingered salute.....

cheers

tachyon

So, although in present day perl (and other non-java langs) are passe, near future might change that... we could see a renaissance of thought-intensive languages like lisp and functional programming

The point is, perl6 is looking nothing like perl5, it looks like an overdesigned language for CS students, not fit for real world, BUT, maybe, this is the best way to go?

I don't think overdesigned languages have anything to do with CS students. There were some bad "teaching" languages, but CS students should aspire to elegance, simplicity, and languages that smell of theory, mathematics, or really-funky-stuff. Those stiff languages are more "industry" things, which is how we ended up with Java. Corporate America twisted our once-cool computer science programs into becoming places to crank out "programmers" and only a select few (say 15% or less) of people coming out of Universities today really grasp what CS is about or what it could have been.

So, anyhow, continue to aspiring to the theory. I doubt corporate drones are going to embrace Perl6, it's already part of the Java culture to bash Perl upside the head, and I am having trouble getting some Java drones to even look at Ruby ... though they do somehow like Python. I don't get it really, though, Python is kind of ugly and mechanical, and makes you jump through contortions ... just like Java.

Anyhow, I may not be a Lisp-head, but Paul Graham seems to have it right about the Hackers & Painters bit, and how we're all really lost in a sea of people who "work at programming" versus people who really love it, understand it, and think about theory, extension, and enjoy "academic" languages (which are so ever increasingly being obliterated in the evil corporate realm).

But I think there is is hope. I see that today in Ruby (minus CPAN! They need a CPAN!), and Perl6 when it arrives may hopefully suplant that. I still use Perl for all of my major tasks, mainly because it is incredibly powerful and has a great user community. Functional perl can be very elegant, OO perl can be elegant after a few hoops are jumped through, but it is still incomplete as compared to the smoothness at which you can, say, redefine a class on the fly in Ruby.

because everyone knows java, and it has reputation of allowing cheap/poor programmers to contribute..

True! And sad, because I hate to work with these people. I'd rather have 2 good developers in a department than 2 good developers AND 10 poor ones. it also has a propensity for draining the souls out real hackers. Rage, rage, against the dying of the light...

Maybe the Java programmers like python cause of Jython, it flatters them or something.

Ruby is awesome, but I totally agree with you that they need a CPAN. Whoever said that CPAN is Perl's killer app was right.

long live Perl in whatever incarnation!

--rachel

We're living in different world now, procedural style rules, people program in PHP and they say it's 'easy' (because you don't have to think, you know) ....

First I've heard of prorammers reverting to procedural style. PHP5 is going The Way of All Java, leaving its procedural brethren in the dust in a desperate attempt to be accepted in corporate circles. A long way from Ramsus Lerdorf's "Personal Home Page" kit indeed.

I don't know about not having to think with PHP but it is certainly less idiomatic than Perl. It also suffers from a conflict of interest and identity. Witness Zend's endless commercial add-ons and the ongoing tug-of-war with MySQL. It just seems to be so concerned with the "industry".

As a web developer who has had to use PHP for client projects from time-to-time I always want to get back to Perl at the end. If anyone is interested in contributing I'm looking to devise a list of CPAN modules to provide Perl developers with the same features as is available in PHP's main web development functions.

Perhaps you should post a meditation about this. It sounds interesting and if there were places I could contribute, I would. I'd like to hear the enlightened and the rabble give RFC responses to the idea.

overdesigned language

Pointers to links that explain the above in easy terms would also be appreciated.

Many tia.

Update: I read Tachyon's links to second system effect. I understand that now, but am still unclear as to why Perl 5 is not overdesigned, while Perl 6 might be.

Btw, it seems to me that simple and elegant might not be mutually exclusive from overdesigned. If anything, it might take way much more design and care to make something simple and elegant.

You are correct in pointing out that the word "overdesigned" doesn't actually mean what it says. Mostly it's just an epithet that people fling at any interface that does more than they're interested in at the moment. More specifically, it's how you describe an interface that, by trying to make too many hard things possible, ends up making easy things hard as well. In this second sense, the interface is "overdesigned" in the sense that it would have been better (for typical tasks) if the designer had stopped adding features earlier.

Perl 6 is certainly "overdesigned" in the first sense. Indeed, every version of Perl has intentionally been overdesigned in that sense. However, it is the second sense that we worry about in the design of Perl 6. Only time will tell if we've worried about it enough that Perl 6 will be perceived as not just overdesigned, but also elegantly designed. There are a lot of elegant ideas in Perl 6--the main question is whether there are too many of them, tied together inelegantly.

People keep trotting out the phrase "second system effect" like some kind of cargo-cult mantra, not seeming to understand that we already know about second system effect, and that part of the reason Perl 6 is taking so long is precisely because we're taking the time to try to compensate for it. That's why our slogan is "Second System Syndrome Done Right!" Of course, it could be one of those things that gets you recursively even if you take it into account, like Hofstadter's Law. But we try to take that into account too, for what it's worth. :-)

There's some merit to the idea that Perl 1-4 was the first system, Perl 5 is the second, and Perl 6 will be the third.

The point is, perl6 is looking nothing like perl5, it looks like overdesigned language for CS students, not fit for real world, BUT, maybe, this is the best way to go?

There is no singular 'Perl Community'.

People that want this pragmatic perl I started using years ago are working on perl 5.6.x and 5.8.x,

perl was created as a tool to do the job. perl6 will be language... and one can already see that it'll take years before we've got perl6 that we can use, and decades before we can dump perl5 the way we dumped perl4.

You still haven't said why perl6 isn't pragmatic i.e why do you think it won't let you 'do the job'. Perl 6 compiler now has its own mailing list, so perl6 isn't as far in the future as it used to be.

And why the hurry to dump perl5?

it looks like an overdesigned language for CS students, not fit for real world

What would you have said in the era of Perl4, having closures coming your way? I'm pretty sure these would have looked bizarre. And yet they're one of the Perl5 features I sorely miss in every language that doesn't have them.

Anyway. Forget anything you read about Perl6. Erase it from your mind. Pretend you never saw or heard it. Then, go download one of Damian's talks about Perl6 and listen. See Download of Damian Perl 6 talk audio for a good recent one.

I'm pretty sure you'll come out with a vastly different new opinion.

Bare feature lists inherently look abstract. If you're a C programmer, reading a description of how closures work won't help you. If you're not experienced enough with a concept to extrapolate its usefulness, have its applications explained to you by someone who can.

... or J2ME?

Would you mind rewriting that in something more nearly approximating English?