Slashdot Mirror
Perl's Extreme Makeover
PurdueGraphicsMan writes "There's an article over at Yahoo! about the upcoming version of Perl (version 6) and some of the new features (RFC list). From the article: "Although Perl 5's expressions are the most sophisticated available and aspired to by other programming languages, "no one pretends for a moment that they're anything but hideously ugly," said Damian Conway, a core Perl developer and associate professor at Monash University in Australia.""
If you want the real scoop on the on-going planning of Perl 6, you might want to check out Larry Wall's Apocalypse articles: 1, 2, 3, 4, 5, 6. On the down side, they are dense. Very dense. For that reason, I actually recommend Daimon Conway's Exegesis articles: 2, 3, 4, 5, 6. They provide alot more context on what the changes actually mean to you and why they're good.
Search 2010 Gen Con events
I cannot claim to intimately know Perl 5, but I started learning it a few years back. I belong to the camp of Perl programmers (and I know there are a few of these) who are adopting a "wait and see" attitude to Perl 6.
If you're interested in learning Perl now, you should probably go for the cookbook approach, ie: get a copy of OReilly's Perl cookbook and just try applying the solution to your problem. Then, trying tweaking and figuring out how it works.
As for learning Perl 5, I'd probably point out that there are still some places that run 5.005_03 (certainly Solaris used to ship with that version by default), and that version is at LEAST 5-6 years old :) There are even some places I've heard of that run Perl 4 :) So, I think there is plenty of time to have your investment in learning Perl pay off before people start switching to Perl 6 en masse.
Wall won't mess it up don't worry. I've been lurking on Perl 6 lists and ocassionally adding a dime for almost 18 months. What people misunderstand about Perl is that it is a rather hybrid ad-hoc and over inclusive language by its nature. In many ways it's like Linux and OSS in general, it's diverse deep and wide, has a long pedigree which itself inherits from a rich history of shell and Unix syntax. Most of what is going on in 6 is reconciling and consolidating some of this ugly middle age spread. It is the Borg of all languages. As an 'expert' C programmer I took to Perl very nicely. It is a working mans language. Something you use to _get_the_job_done_. And there's always more than one way to do it :)
Eventually you will all grow to love your new Perl 6 overlords. You will be assimilated.
Personally, I found that perl was kind of odd and not fantastic until I learned perl with regexes [via O'Reilly's Mastering Regular Expressions, highly recommended]. Then alot of the little nuances made alot more sense. Alot of the examples in that book were things perl does easily in a few lines, but would cause most programmers to gouge their eyes out if they needed to do it in C.
You mean like:
Doc
http://www.ruby-doc.org/
http://www.rubycentral.com/book/
Unit Testing
http://testunit.talbott.ws/
http://www.rubygarden.org/ruby?RubyUnit
Library Repository
http://raa.ruby-lang.org/
Portability
Source compiles on anything vaugely Unix like
Windows binaries available
User Community
comp.lang.ruby
So, what were you on about again?
TODO: Something witty here...
Perl was first released in 1987. Y'know, I could've sworn the internet already existed back then...
(especially since Perl was released in a post to alt.sources)
Repton.
They say that only an experienced wizard can do the tengu shuffle.
Maybe I'm missing your point, but Perl certainly isn't having core revisions every year in terms of the language. Perl5 has been around for about 10 years now, and will probably still be pretty widespread in another 5 years. 15+ years isn't a really bad lifetime for a langauge, and it isn't like there are no plans to continue support for Perl5 code. Indeed, they are currently re-implementing Perl5 on top of the Parrot engine, so Perl5 and Perl6 code will be able to interact. This means systems can gradually move from Perl5 to Perl6 if they need to, without needing a full re-write.
You might be interested in Ponie, then. Ponie is the project to create a Perl5 interpreter for Parrot. It should let you get much of the speed benefit of the new virtual machine without having to learn the new Perl6 syntax. Of course you may still want to learn the new syntax, since it will add many powerful new features, but Ponie will ensure that Perl5- and all of the work you've put into your Perl5 scripts- won't be completely abandoned just because Perl6 has come out.
There's no point in questioning authority if you aren't going to listen to the answers.
Start now. It's gonna be a while before six is out - and even longer before companies will trust it in production environments.
And come over to The Monastery to get help when needed. A great resource for new (and experienced!) Perl hackers.
.02
cLive ;-)
-- Trinity in high heels carrying a whip: The donimatrix - there is no spoonerism
Finally, remember that most other Perl programmers will be in the same boat as you are in learning the new language, so Perl 5 should remain well supported for some time to come.
A few points to ponder ..
You've all heard the "you can write unreadable code in any programming language" argument, so I'll spare you the repetition.. (No, wait.. I didn't, did I? ) *grin*
But also bear in mind that Perl is the first language that I know of that used the foreach construct in the same form as the more sought after languages.. Java has iterators and enumerators, but they introduced a foreach because it is darn easy to understand.
Perl innovated in regular expressions. Even Jeffery Friedl's Mastering Regex (sic) says that other languages aspire to be called "Perl 5 compatible" when they don't necessarily support all the features of Perl 5.6". Love it or hate it, regular expressions are like the microwave in your kitchen. Once you get used to it, it's darn hard to manage without :)
I am not going to go into Perl 6 the moment it is released. But I guess that's ok, because I didn't adopt 5.8 the day it was released either. I just think that Larry Wall has made enough good calls in the language so far, to be worth trusting him for another version. Even one that promises to break some of the idioms that I am accustomed to in it's present incarnation. Hey, I didn't like Perl 5 when I first saw it either, but I notice the difference in my productivity when I got the hang of things.
I have a small involvement with Parrot (e.g. I've contributed a few small, insignificant things, mainly fixes for Win32). It's not vaporware, it's just that designing a stable, efficient, multi-threaded virtual machine that runs on a wide range of different platforms isn't an easy task. You can go and do a CVS checkout of Parrot now and play with some of the toy compilers, or if you use Windows grab yourself the Parrot On Win32 compiled version:-w /
http://www.jwcs.net/developers/perl/po
The 0.1 release may be coming by the end of this month - and if this release isn't 0.1, I'm pretty sure the next one will be. That means Parrot has objects, some of the threading stuff is in place, JIT is working on various platforms and more. There's a lot of hard work going in by a lot of very good developers (not me!), and I'm confident that Parrot will be completed and will be a hot target for dynamic languages.
Redundant bitching: Redundant means that the post or something close has already been made earlier in the discussion. Since this was the third post - highly unlikely. Checking the two posts before confirms this.
As far as the joke goes, it's an old joke by egg troll that seems to have made its way around. If you had a factory that made characters, and it blew up, and there were characters everywhere... that would be Perl code.
God, someone shoot me for explaining that.
No, I mean like:
..pales in comparison to...
...in addition to the mailing lists.
Doc
Something a little more thorough.
http://www.perldoc.com/
Unit Testing
Not just wrappers, but something a little more thorough and mature like say from executable to module.
Unit Testing
Library Repository
http://raa.ruby-lang.org/
http://www.cpan.org/
Portability
[Acorn] [AIX] [Amiga] [Apple] [Atari] [AtheOS] [BeOS] [BSD] [BSD/OS] [Coherent] [Compaq] [Concurrent] [Cygwin] [DG/UX] [Digital] [DEC OSF/1] [Digital UNIX] [DYNIX/ptx] [EMC] [Embedix] [EPOC] [FreeBSD] [Fujitsu-Siemens] [Guardian] [HP] [HP-UX] [IBM] [IRIX] [Japanese] [JPerl] [Linux] [LynxOS] [Macintosh] [Mac OS] [Mac OS X] [MachTen] [Minix] [MinGW] [MiNT] [MPE/iX] [MS-DOS] [MVS] [NetBSD] [NetWare] [NEWS-OS] [NextStep] [Novell] [NonStop] [NonStop-UX] [OpenBSD] [ODT] [OpenVMS] [Open UNIX] [OS/2] [OS/390] [OS/400] [OSF/1] [OSR] [Plan 9] [Pocket PC] [PowerMAX] [Psion] [QNX] [Reliant UNIX] [RISCOS] [SCO] [Sequent] [SGI] [Sharp] [Siemens] [SINIX] [Solaris] [SONY] [Sun] [Symbian] [Stratus] [Tandem] [Tru64] [Ultrix] [UNIX] [U/WIN] [Unixware] [VMS] [VOS] [Win32] [WinCE] [Windows 3.1] [Windows 95/98/Me/NT/2000/XP] [z/OS]
User Community
A little more world wide and established.
http://www.pm.org/
So, what were you on about again?
From the parent parent parent poster. "Ruby has almost all of the power of Perl, with none of the ugliness" isn't quite a fair statement, considering Ruby is lacking or behind on almost everything else Perl is superior at. Ruby is still playing catch up, and depending on who you ask, can also be considered ugly.
No.
Long-term, Parrot hopes to be at the core of not just Perl 6, but also Python, FORTH, and what-have-you. Then applications could support Parrot, and users could script the applications in their favorite language. Python users could call into Perl CPAN code. That sort of fun thing.
Parrot's home page is: http://www.parrotcode.org/
The Parrot FAQ is worth reading. There are some really entertaining sections. One of my favorites:
Another:
So, my next question was: if they want to become the core of languages like Python, what does Guido van Rossum (the architect of Python) have to say about that? A few google searches later, and I found an interview at linuxfr.org, which contained this:
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
Parrot will be a virtual machine like the JVM and .NET runtime, yes. This means you can call functions and use objects from code written in the various different languages that target Parrot, compile stuff to bytecode that will run wherever Parrot will compile and more. Like .NET and JVM it uses JIT techniques to provide fast code execution.
.NET/JVM is that they are more targetted towards statically typed languages. Languages like Perl, Python, etc that are likely to target Parrot are dynamic languages. This isn't just related to dynamic typing, but also to dynamic languages needing their parsers to be available at runtime. You can also do more stuff at runtime that non-dynamic languages would prefer you didn't. Parrot is designed with this in mind, which means it can offer these sorts of languages better performance.
.NET bytecode to Parrot bytecode convertors, but I'm not sure how much speculation that is. I'm not really certain how easy it'd be, though my initial guess is "not very".
The main difference between Parrot and
I have heard things along the lines of JVM and
Hope this answers some of your questions.
a) Ruby uses brackets or end statements to delineate blocks, not indentation.
b) Why would anyone have a problem with this? Python code is remarkably easy to read and modify, primarily because there are no block delimiters to deal with. Maybe your editor is faulty?
there *is* a full backward compatibility : Parrot will run your Perl5 code. And if you don't want to run old perl5 code, there will be a script to convert your code.
and you don't have to care about migration for now - not until the next two years. Perl6 is not ready.
the "lunatics", as you said, seem to be very serious and competant...
Abandon Perl! Python is the future!
Consequently, Perl 5 code should run faster under Perl 6.
Well, the only valid point on your list is the large selection of Perl libraries. But that's like saying Windows is better because thousands of programs are available..
Not quite analagous, because that also means your definition of "better" for Ruby is like saying MacOS is better because there are fewer programs available.
For instance, docs and unit testing are pretty much the same in Perl, Ruby, Python, PHP, Java...
I must have screwed up my terminology. The unit testing I am referring to, is the built in stuff that comes with the Perl build process, the module build process, etc. Perl is second to none in testing. I would agree Perl, TCL, and Java docs are similiar in completeness. When I say complete, I mean documentation on how to embed and extend is available, is thorough, and all the intricacies are spelled out. Ruby, Python, and PHP are lacking. For example, at my command line I can type: perldoc perlxs, perldoc perlapi, perldoc perlembed, perldoc perlguts, and I have 10x more information about the innards and what is going on than the other languages.
The Perl and Python communities are full of people trying to show off.. it gets old after a while.
Not sure what you mean by show off. Ruby coders seem to be just as desperate as Python coders to demonstrate how their language is almost as powerful as Perl. When Ruby clutches the title of being the swiss army chainsaw in the industry, I think Ruby too, will have a reason to "show off".
One great think about Ruby community though, is that it's still small and friendly.
One awful thing about the Ruby community is that they pipe up about how they are almost as good as Perl whenever Perl is mentioned.. it's offtopic, untrue, and gets old after a while.
No.
Object Oriented Perl
The "Programming Perl" book voers it, as does (briefly) the "Perl Cookbook", which is a must-have.
Most CPAN modules have an OO interface, so it's worth understanding at least a little of it.
or were you just kidding and/or trolling?
"that's not encryption - it's a new perl script that I'm working on..." - from some Matrix parody
lameness filter won't let me space the comments neatly, but I'm sure you get the idea.
.02
cLive ;-)
-- Trinity in high heels carrying a whip: The donimatrix - there is no spoonerism
Thank god threading is at the top of the list.
I've been a perl programmer for six years - I still use it daily - but perl5's support for threading absolutely blows. There are plenty of modules for whipping together a multithreaded TCP server, but no reliable way to share a resource such as a database connection pool between those child threads. Have had to put at least one project on indefinite hold due to this failure.
I assume its that oldskool anti-threading anti-OO attitude. Perl5 still isn't compiled with threading support by default and it breaks a tonne of modules and apps when it is.
Perl6 can't get here soon enough.
No, I did not read the f***ing article!
The example i gave was off the top of my head. In the real world, for example, we've been dealing with a JavaScript HTML editor that has its own quirks (to say the least :). We do not have the time to learn enough OO javascript to perfect the code we're using. So we've had to hack how it works. Before presenting a page for edit, we have to remove certain elements and then re-insert them after edit. Without comments, we'd be returning to this code at a later date wondering *why* we're hacking it like this. Comments make it absolutely clear.
In reality crap code is used a lot because of deadline pressure. But that doesn't make it OK.
You're missing the point. If I can see what a coder *thought* they were doing, I can find their weaknesses easier and help them improve - rather than trying to second guess based purely on the code. I can spot inaccurate assumptions, illogical trains of thought and many other things that just don't jump out quickly from pure code.
Even if I can read and understand what your code does, if an issue comes up that needs fixing quickly (say, a security issue affecting 60,000 web sites), I need to identify where the issue could be as quickly as possible. By reading comments along with the code, it's a lot easier to spot mistakes made by a developer.
Here's another example. Let's say I'm chasing down a problem and I come to a regular expression that I think could be the issue. If the coder in question has commented it ( "Grab all URLs on the page that link to external sites", say) and I glance at the regular expression and see it doesn't do what the comment says it does, that sets alarm bells ringing. I can also gain an insight into what they were thinking when they coded the method.
In an ideal world, everyone would cover every possible issue and everything would be watertight. But, in the real world, I'm often dealing with work by coders with different strengths and weaknesses. And it's a lot easier to coach them on their thinking if I have some idea as to what's going on in their head.
I didn't mean to sound rude in my last post, but if you were working on my team, you would be expected to comment your code well. If you intend never to work with others and only maintain your own code, you could probably get away without commenting, but i wouldn't recommend it.
A few months ago I spent 3 days working on what ended up being 20 lines of code that recursively built a menu for a Template Toolkit page from a DB table. Although from reading it, it makes sense, I commented *every* line of those 20, explaining why I did what I did and what issues I was coding to avoid - and what I hit along the way. Even now I find the notes useful. Or perhaps you think you'd remember how and why you created a hashref of arrayrefs of hashrefs of arrayrefs for the data structure - and how that fitted in with the particular template - instinctively?
When taking on new team members (as we are at the moment :), I would be very wary of considering someone who doesn't comment.
But that's just me. And what I've found works in building Perl apps over the last 7yrs :)
cLive ;-)
-- Trinity in high heels carrying a whip: The donimatrix - there is no spoonerism