What is Perl 6?

chromatic writes "Perl.com has a new article entitled What is Perl 6?. It analyzes the changes to the language in light of the good and bad points of Perl 5 and provides new information about the current state of the project: Perl 6 exists, you can write code in it today, and it's more consistent and easier to use than Perl 5."

Comments

Re:What is Perl 6?

[Perey]

That's the thing, though. PHP is the big name (from management's perspective), at least in the P category of LAMP, right now. Not that Perl's gone away by any stretch of the imagination, but the existing Perl shops are happy to keep on doing what they're doing, while the PHP advocates crow about how many new jobs are being done in their language.

So is Perl 6 going to bring about a Perl revival, or is it (as I suspect) going to fall flat when faced with Perl 5's quietly entrenched support and PHP's proclaimed grip on new uptakers? TFA mentions the reasons for cutting backwards compatibility (or at least reducing its priority) far too often for me to be optimistic there.

I think Perl 6 will catch on, eventually... but it's going to be more of an alternative language, not an upgrade, to Perl 5 for a long time yet.

No language that I like better

[BadAnalogyGuy]

I never really understood Data Structures until I learned Perl. I was consistently and thoroughly confused in my DS class. The language used there was C++. There was simply too much baggage in the language that obfuscated the very points we were being taught. If you can't get past the template syntax, how in the world are you going to be able to understand the data structure concepts?

Then I met Perl (5.003). What a difference it made! The data structures were built in, and on top of that, it was EASY to nest structures to build complex data types. It was like having a semester of Data Structures immediately made clear.

Then I found myself back with C++ again. First I wrote my own List classes. However I soon realized that STL made available exactly the types of data structures that Perl has. Maps, Lists, Vectors. And since I understood what I was doing in Perl, it was so much easier to catch on with C++.

Perl taught me C++. Who would have thought?

Re:No language that I like better

[AuMatar]

Ignore the analogies, OOP has nothing to do with obkects at its core. OOP is basicly encapsulation and interfaces. You design your program so that its broken into parts. Each part handles one bit of functionality- networking, or database communication or the like. Each part is self contained, no 2 parts should know how the other part is coded- they only communicate with each other through a set of functions. These functions are called an interface. The functionality of each part is said to be encapsulated, because the actual design of the code is not known to the outside world.

In C, you do this with functions in a .h file and call it a library or a module. Sometimes you use a struct to pass around data. A great example is the stdio library- you have a bunch of library functions to do IO. You don't know how those are implemented. ANd since you can have open IO on more than 1 file at a time, you need a bit of data to hold the state of an IO. Thats why you pass back and forth FILE* parameters.

In C++, you put the data and the functions together in one package and call it a class. Think of a class as a C struct with a bunch of function pointers in it. So instead of calling myfunction(mystruct) you call myclass.myfunction(). Its conceptually the same (in fact, the machine code is almost identical).

By now you should be thinking "damn, that sounds like what I do in C already". It is. Good C programmers did OOP before OOP was a buzzword. languages like C and Java just add some syntactic sugar like inheretance (one of the most abused language features ever, especially in Java) and autoatic constructiors and destructors into the mix.

PDL

[LordMyren]

The article talks about some of the defining features for perl. Well, one of the defining features in my perl experience has been Perl Data Language, pdl. PDL _is_ whipitupitude. Its a wonderful wonderful matrix library. And it comes with the best perl shell I know.

I had to break down a equation into a sequence of linear equations. So I hacked up some PDL in like 2 hours to do that. Couldn't have been easier, even though I'd never used PDL or its perldl perl shell; I just started typing in the interactive shell until it worked as expected and until I knew what I was doing. Then I needed the results in interger, so I rounded everything down, built a permuter and sorted the permuted results for each individual segment. That took three hours, but only because I kept botching the matrix multiplication. Even with huge datasets, generating hundreds of thousands of linear equations, each spanning dozens of datapoints, permuting the linear equations, sorting them and selecting the optimal, PDL would run it all my slow arse 800mhz crusoe laptop in seconds. Matlab couldnt touch it.

Thats the other really truly thing about PDL; the performance. If someone else would chime in and do it better justice, but my crude understanding is that it generates some kind of extremely optimized machine code on first use and runs whatever equations you've thrown at it like silk from that point on.

Little late and a little off topic, but PDL really is just a masterpiece of perl hackability. The PDL perl shell is truly spectacular; get some symbolic integrators and differential equation solving packages in there and I wouldn't need to break open Mathematica or Matlab ever again. Ok, long way away, pdl is really just about matricies, but it is really really sweet, and its shell is good for anyone who just wants to try something out really quickly in fully interactive perl.

That being said, I really cant wait to see where the perl6 VM is going.

G'night!
Myren

About 3 years too late

[Colonel Panic]

Ok, Perl6 does indeed look cool. Lots of interesting things there. Sure, you can apparently write Perl6 code today and run it on PUGS (a Haskell implementation of Perl 6; that's gotta be speedy, eh?). But as is mentioned in the article, Perl6 was announced at OSCON 2000; that's 5.5 years ago. It's now become the posterchild for vaporware in the open source world, hence this article to keep the faithful hopeful (and to keep'em from sneaking off to Ruby, Python or even Io). Really, it just looks like the purpose of the article is to say "yes, we're still here working on Perl 6. We're working hard, we really are. Please, don't lose hope. This is hard work. It'll be here one day and it'll be great", while a lot of Perl folks who yearned for something better have already moved on to Ruby or Python.

I really hope that Perl 6 arrives one day. I'm pretty deep into using Ruby these days having left Perl 5 behind long ago (the part of the article about what's wrong with Perl 5 was really superfluous; maybe it was intended to convince the remainingn Perl folks who are happy with 5 to check out 6), but I'll give Perl 6 a look when it arrives. The grammar support alone looks pretty awesome; it'd be great to have a viable lex/yacc alternative. In the meantime I want to learn some languages that have a bit more immediate promise like Io. It seems that maybe the plans for Perl 6 were just too ambitious. Yes, it's great to start with a clean slate and try to revolutionize, but often it's evolution that wins out.

Re:Perl 6 is evolving the language into awesome!

[Anonymous Coward]

I like the use of "." for concatenation

"+" as an operator sugguests that the order of the items being operated on has no effect on the answer...

eg. 2 + 3 == 3 + 2

but
"two" + "three" != "three" + "two"

Re:Perl 6 is

[TheP0et]

Not just another virtual machine nobody needs. Perl6 is also a consequent implentation of language development paradigms. Java started some of it with its so called "platform independent" VM. Microsoft jumped on that train with DotNet and its intermediate language for the CRL. Perl6 bundles those ideas together, gets rid of hierarchy constraints inherited from the old OO drafts, and adds complete costumizability to syntax and grammar while trying to keep the number of built-in functions as small as possible.

No other language does make it so easy by now to adapt the language itself to the needs of the special environment. You could for example write a module that forces strict inheritance to all of your objects, or implicitly puts all variables and values into a protected memory range, or dump your current program state onto a disk, everything within the blink of an eye.

Other implementations of introspection, like Java's Reflection API, provide the needed self-awareness of the code and the means for dynamic object handling up to some point, but that point reached, things tend to get rather ugly. Perl5 provided some "dirty hacks" for a part of that, but couldn't cover everything without breaking compatibility and, most of all, performance.

Still Perl6 won't be the sole answer to every question - as allways TMTOWTDI. But it's certainly interesting enough to keep an eye on it.

Perl 6 = COBOL 9x

[scottsk]

Perl 6 reminds me of the super-revamped, object-oriented COBOL that came out in the 90s -- by the time this perfect language was created (and it was a decent upgrade, although the OO stuff was so verbose it wasn't funny), COBOL 85 had such a huge installed base that COBOL 9x was irrelevant. The amount of code written to the COBOL 85 standard was immense, and most new development had moved on to other languages. Maybe Perl 6 can escape the Fortran 9x and COBOL 9x trap of being really great languages about a decade too late. The biggest hurdle Perl 6 is going to face is its own installed base. It will have to be 100% compatible with Perl 5 to get people with a code base of Perl 5 code to even think about using it. Plus, it needs to have a compelling story to tell. I was excited about Perl 6 five or six years ago.