Perl 5.14.2 is now available(nntp.perl.org)
nntp.perl.org
Perl 5.14.2 is now available
http://www.nntp.perl.org/group/perl.perl5.porters/2011/09/msg177618.html
6 comments
Cool. Nice to see the updates coming but it's rather lightweight and minor. Of all my pet projects and scripts, Perl ones hold the most value. Lala.com music downloader comes to mind.
This is just a maintenance update to 5.12, ie. the latest stable version of Perl.
The next version (5.16) is due in Spring 2012 and there are regular (monthly) updates to this on the 5.15 development track:
* 5.15.0 - http://search.cpan.org/~stevan/perl-5.15.3/pod/perl5150delta...
* 5.15.1 - http://search.cpan.org/~stevan/perl-5.15.3/pod/perl5151delta...
* 5.15.2 - http://search.cpan.org/~stevan/perl-5.15.3/pod/perl5152delta...
* 5.15.3 - http://search.cpan.org/~stevan/perl-5.15.3/pod/perldelta.pod
The next version (5.16) is due in Spring 2012 and there are regular (monthly) updates to this on the 5.15 development track:
* 5.15.0 - http://search.cpan.org/~stevan/perl-5.15.3/pod/perl5150delta...
* 5.15.1 - http://search.cpan.org/~stevan/perl-5.15.3/pod/perl5151delta...
* 5.15.2 - http://search.cpan.org/~stevan/perl-5.15.3/pod/perl5152delta...
* 5.15.3 - http://search.cpan.org/~stevan/perl-5.15.3/pod/perldelta.pod
Opps typo! Its maintenance update to 5.14
I like and use Perl and love seeing Perl news on HN, but do we really need the announcements of minor maintenance releases? Since people are voting it up, there is obviously some interest in it, but I don't get it. Plus, there's not even a changelog at the above link.
From the link above:
You can find a full list of changes in the file "perldelta.pod" located in the "pod" directory inside the release and on the web at:
https://metacpan.org/module/FLORA/perl-5.14.2/pod/perldelta....
Thanks for the correction, I missed the "on the web" part.
Sometimes I think that whether or not something gets updated is a function of what else there is to upvote at the time.
People hop onto HN and upvote the things that are interesting. If a Perl release is the only interesting thing, then so be it. You could borrow a meme from slashdot.org and call it a 'slow news day.' (I realize that the phrase is older than slashdot)
People hop onto HN and upvote the things that are interesting. If a Perl release is the only interesting thing, then so be it. You could borrow a meme from slashdot.org and call it a 'slow news day.' (I realize that the phrase is older than slashdot)
it may just be an exucse to talk about Perl once in a while.
Yup, I think it's that, it's nice for perl users to find each other. Every second job I do seems to involve writing a lot of perl code. The release notes reminds me how much I still don't know about perl.
It makes me mostly sad; I can't use features after 5.8. Moo(se) et al is what I do after $work. :-(
Pretty much all of the CPAN stuff I care about - Moose, Catalyst, DBIx::Class etc. supports as far back as 5.8.5 still - specifically for the people stuck with old RHEL systems and similar.
While it's disappointing that you don't get to use a newer perl at work, you should still be able to play with most of the shiny modules. There's plenty of CPAN authors still happy to do the legwork to make that so, because we don't want to exclude a bunch of people just because their perl5 VM sucks.
While it's disappointing that you don't get to use a newer perl at work, you should still be able to play with most of the shiny modules. There's plenty of CPAN authors still happy to do the legwork to make that so, because we don't want to exclude a bunch of people just because their perl5 VM sucks.
I would have been excited to see Perl6!
The last release of Rakudo (Perl6 on Parrot) was in July: http://rakudo.org/2011/07/29/rakudo-star-2011-07-released/
The next release is due soon and this includes some heavy refactoring so will be a lot quicker: http://rakudo.org/2011/08/19/rakudo-2011-08-release-status/ & http://rakudo.org/2011/09/09/nom-branch-default/
The next release is due soon and this includes some heavy refactoring so will be a lot quicker: http://rakudo.org/2011/08/19/rakudo-2011-08-release-status/ & http://rakudo.org/2011/09/09/nom-branch-default/
Perl 6 is an entirely different language than Perl 5.14 with an entirely different development path. I don't see Perl 6 as "the next version of Perl". Perl 5 continues to thrive and will for some time.
Perl has been completely replaced by Python for me. Perl was the second language I learned in around 1995 after learning Turbo Pascal in my pre-teens. Perl allowed me to learn the programming arts freely, the programs I wrote weren't pretty back then but they ran and performed a function. It let me experiment with CGI, GUIs and writing video games.
Thanks Perl. Pity you were so ugly and we had to break up but Python is "cleaner"[1] and I just couldn't stick with you.
[1] Personal preference I am not looking for a fight :)
Thanks Perl. Pity you were so ugly and we had to break up but Python is "cleaner"[1] and I just couldn't stick with you.
[1] Personal preference I am not looking for a fight :)
> Pity you were so ugly
> [1] Personal preference I am not looking for a fight :)
Your wordings don't align with the disclaimer. That's like saying "you are an idiot, but hey, it's a personal perspective - I am not looking for a fight".
FWIW, I have used perl heavily, and now a days mostly do Python and Ruby. My reasons for Python/Ruby are basically Nltk/Flask/Gevent, Rails etc and don't have much to do with the languages themselves. They are pretty interchangeable with some syntax difference.
> [1] Personal preference I am not looking for a fight :)
Your wordings don't align with the disclaimer. That's like saying "you are an idiot, but hey, it's a personal perspective - I am not looking for a fight".
FWIW, I have used perl heavily, and now a days mostly do Python and Ruby. My reasons for Python/Ruby are basically Nltk/Flask/Gevent, Rails etc and don't have much to do with the languages themselves. They are pretty interchangeable with some syntax difference.
If you still consider Perl, I recommend checking out: Plack, AnyEvent::*, Catalyst/Dancer (depending on required complexity) for web stuff.
Perl libraries made a huge leap forward. And for me it was unnoticed.
Perl libraries made a huge leap forward. And for me it was unnoticed.
If I'm not mistaken, libev and AnyEvent are designed by the same guy (and I think AnyEvent was what libev was created for).
Also, check out Coro (coroutines), Tatsumaki and plackperl.org for other awesome libraries and tools that rival and even surpass their counterparts in other languages.
Also, check out Coro (coroutines), Tatsumaki and plackperl.org for other awesome libraries and tools that rival and even surpass their counterparts in other languages.
My words do. Beauty is in the eye of the beholder, I prefer many things about Python over Perl not just the syntax. I wasn't claiming that I think others are stupid for liking or using it, just my personal preference of what I like in a language.
Perhaps I could have worded it a little less flame bait like:
Pity I didn't like your idioms and we had to break up as my eyes and heart prefer Python.
Any better?
Perhaps I could have worded it a little less flame bait like:
Pity I didn't like your idioms and we had to break up as my eyes and heart prefer Python.
Any better?
On the other hand I see a massive drop in Python's popularity these days. Earlier it used to get all the talk. Coffee tables, forum discussions, debates what not. Also few days back, I used to run into people choosing Python as a language for their project all the time. That seems to falling rapidly now.
The popularity and fan boy crowd seems to have moved to server side JS these days.
We are only days away from how people bash Python for more recent fancier options.
The popularity and fan boy crowd seems to have moved to server side JS these days.
We are only days away from how people bash Python for more recent fancier options.
>>I prefer many things about Python over Perl
I have been doing Python a bit now and am of the opposite opinion.
Except for CPAN I miss the advanced stuff like Moose (better OO) and extensible syntax.
I might be too new to the language. E.g., I don't really get the list comprehension -- it looks like a kludge around the lack of multi line code blocks, so Python can't have nice a map() syntax. But people seems to love the that syntax, so there should be more to it than a kludge?
But sure, Python has a minimal and elegant notation; it just changes a bit too slowly.
Also, try posting a flame comment like yours about Python in a Python thread; you'd be at minus ten in five minutes and stupid comebacks would be up voted to orbit. The fanaticism makes RoR kids look mature.
I have been doing Python a bit now and am of the opposite opinion.
Except for CPAN I miss the advanced stuff like Moose (better OO) and extensible syntax.
I might be too new to the language. E.g., I don't really get the list comprehension -- it looks like a kludge around the lack of multi line code blocks, so Python can't have nice a map() syntax. But people seems to love the that syntax, so there should be more to it than a kludge?
But sure, Python has a minimal and elegant notation; it just changes a bit too slowly.
Also, try posting a flame comment like yours about Python in a Python thread; you'd be at minus ten in five minutes and stupid comebacks would be up voted to orbit. The fanaticism makes RoR kids look mature.
List comprehension is one of those things I miss every I use another language. I am not sure what you mean with: it looks like a kludge around the lack of multi line code blocks could you provide and example?
Don't you know what map is? But you claimed to be an old Perl programmer?
I wrote "Python can't have nice a map() syntax", because of its lack of code blocks. And that list comprehensions seems like a one-statement kludge of the map functionality.
How could I have been clearer?
OK... second attempt to explain this point: :-)
List comprehension seems to me like a one statement replacement of a map function (and that one-statement often makes you think of Perl golf.)
And a third attempt: :-)
It seems to me that list comprehension would never have been implemented -- if Python had added (optional) support for ';' (+ '{'/'}') and hence code blocks. That is because Python would then use map() instead of list comprehensions (like all other scripting languages, lisps, etc).
(Also, a side effect of optional ';' support would mean that Python wouldn't be worthless garbage as a bash cmd line tool.)
But please enlighten me about use cases not done clearer/better with code blocks?
I note that you don't argue about the fan bois point... :-)
I wrote "Python can't have nice a map() syntax", because of its lack of code blocks. And that list comprehensions seems like a one-statement kludge of the map functionality.
How could I have been clearer?
OK... second attempt to explain this point: :-)
List comprehension seems to me like a one statement replacement of a map function (and that one-statement often makes you think of Perl golf.)
And a third attempt: :-)
It seems to me that list comprehension would never have been implemented -- if Python had added (optional) support for ';' (+ '{'/'}') and hence code blocks. That is because Python would then use map() instead of list comprehensions (like all other scripting languages, lisps, etc).
(Also, a side effect of optional ';' support would mean that Python wouldn't be worthless garbage as a bash cmd line tool.)
But please enlighten me about use cases not done clearer/better with code blocks?
I note that you don't argue about the fan bois point... :-)
But Perl IS ugly. You haven't noticed that before? The truth hurts.
People complaining about Perl being ugly is a bit like people complaining that clay is ugly. Yes, you can build tremendously ugly Perl, but you can also build code of breath-taking beauty, combining the best parts of functional programming and OO...
So, it's a general purpose programming language like a lot of other languages are too? The complaint is obviously that Perl is uglier than it needs to be. You can see this when you compare it to other languages that are just as (if not more) powerful but not as ugly.
"There's more than one way to do it" (TMTOWTDI or TIMTOWTDI) is a Perl motto. Perl was written with that idea
in mind. This can allow developers to write "ugly" Perl -- or quite the opposite, as @peteretep said.
Show me a modern, general purpose language for which there isn't more than one way to do most things and I'll show you a language you don't know very well.
Even Python, who's motto would be closer to "one right way to do it" always has more than one way. So you're statement doesn't explain anything I'm afraid.
Even Python, who's motto would be closer to "one right way to do it" always has more than one way. So you're statement doesn't explain anything I'm afraid.
I don't think the things you two are saying are mutually exclusive. Perl is ugly in inexperienced or rushed hands, and other languages do have flexibility and general purpose. I will say that I have found my muse in Perl, and that it allows me to express ideas succinctly and beautifully but that's not to the detriment of Python (with which I made a livelihood for a few years).
If you want beautiful Perl, pick up Kaufmann's "Higher-Order Perl." It has a number of functional design patterns and ideas which are useful and elegant. The author claims that where most people write C in Perl, his book is an attempt to convince you to write Lisp in Perl.
If you want beautiful Perl, pick up Kaufmann's "Higher-Order Perl." It has a number of functional design patterns and ideas which are useful and elegant. The author claims that where most people write C in Perl, his book is an attempt to convince you to write Lisp in Perl.
I understand you're not bashing other languages, I just get tired of these tautologies getting trotted out anytime someone complains about perl so I decided to challenge them.
>The author claims that where most people write C in Perl, his book is an attempt to convince you to write Lisp in Perl.
Wouldn't it be less work to just write Lisp in Lisp?
>The author claims that where most people write C in Perl, his book is an attempt to convince you to write Lisp in Perl.
Wouldn't it be less work to just write Lisp in Lisp?
Lots of people would be happy to use lisp instead of Perl or other scripting languages.
For instance, the CPAN module Devel::Declare is a sad excuse for real lisp macros but, afaik, it is still better than most anything else.
(Lisp dialects are sadly seldom possible to use for lack needed libraries like good Unicode support, etc.)
(Btw, Mark Jason Dominus wrote "Higher-Order Perl" http://hop.perl.plover.com/)
For instance, the CPAN module Devel::Declare is a sad excuse for real lisp macros but, afaik, it is still better than most anything else.
(Lisp dialects are sadly seldom possible to use for lack needed libraries like good Unicode support, etc.)
(Btw, Mark Jason Dominus wrote "Higher-Order Perl" http://hop.perl.plover.com/)
I had one of those days where I read the publisher's name, not the author's. Sorry, Mr Dominus!
Any idea on 5.14.0 for Strawberry Perl? Doesn't send a good signal when the Windows version starts to fall behind.
The maintenance of Strawberry Perl is not in parallel with the development of Perl in general. I'm sure the developers are working on it. It has its own architectural issues that go beyond merely compiling Perl and releasing it.
If you really want to know the release date, check in with the guys at #win32 on irc.perl.org.
If you really want to know the release date, check in with the guys at #win32 on irc.perl.org.
ActivePerl provided builds for 5.14 for a while. It's sure not as 'pure' as Strawberry but still very usable.
No news. Strangely, it's apparently quite easy to compile 5.14 source with the dmake and compiler coming with strawberry perl 5.12.3, so I don't know what can be the problem.