

Perl 5.17.6 is now available - Phra
http://www.nntp.perl.org/group/perl.perl5.porters/2012/11/msg195659.html

======
LoonyPandora
In case it's not clear, this is a development version along the road to the
stable 5.18 release, expected in May 2013.

The Perl core team are getting very good at timeboxing their development and
releasing on time.

------
ojosilva
Here's the delta with the changes:
[https://metacpan.org/module/RJBS/perl-5.17.6/pod/perldelta.p...](https://metacpan.org/module/RJBS/perl-5.17.6/pod/perldelta.pod)

~~~
jerf
5.17.6: "The seed used by Perl's hash function is now random. This means that
the order which keys/values will be returned from functions like keys(),
values(), and each() will differ from run to run."

Wait, what?

5.8.1: "Mainly due to security reasons, the "random ordering" of hashes has
been made even more random. Previously while the order of hash elements from
keys(), values(), and each() was essentially random, it was still repeatable.
Now, however, the order varies between different runs of Perl." -
[http://search.cpan.org/~jhi/perl-5.8.1/pod/perldelta.pod#Has...](http://search.cpan.org/~jhi/perl-5.8.1/pod/perldelta.pod#Hash_Randomisation)
, Sept 25 2003

When did that get undone?

Edit: Admittedly, I just tried to verify that this actually happened in 5.8.1
and none of 5.8.8, 5.10.0, or 5.14.2 appear to be actually randomizing key
order, at least according to the keys function.

~~~
broquaint
Relevant discussion on perl5-porters:

[http://www.nntp.perl.org/group/perl.perl5.porters/2012/10/ms...](http://www.nntp.perl.org/group/perl.perl5.porters/2012/10/msg194813.html)

~~~
draegtun
Some more relevant links:

* _Hash order randomization is coming, are you ready?_ \- <http://perlmonks.org/?node_id=1005122>

* _Hash randomisation breaks CPAN_ \- <https://rt.perl.org/rt3/Public/Bug/Display.html?id=115908>

------
new299
I'd be genuinely interested in reasons why I should learn Perl? I've been
hacking away at some Perl interfaces lately but finding it difficult. It seems
like a big language (I'm reading Perl Programming, which is certainly a big
book).

So rather than just hacking away, is there a good reason I should learn the
language properly and push through "Perl Programming" or say learning Ruby,
Python or golang really well. Will Perl remain relevant in 15 years time? Or
at least more relevant than other current languages with similar applications?

I should say that I come from a background of C and C++ programming, which may
effect my mindset somewhat.

~~~
jnazario
i'll wade in. note that i'm bigoted against perl, i'll say so clearly up
front.

perl is better than shell scripting at automation, this much is true. perl has
a strong use case there. had, i'll argue.

perl's idioms and structure promotes wonky, hard to read and hard to maintain
code. it's true. get even the most die hard perl fan a beer or two and they'll
wind up admitting it, sheepishly and quietly. but yeah, perl too easily
promotes a mess. and when you have to maintain code, borrow code, etc ..
readable code matters.

my biggest complaints about perl usually fall into the bucket that perl fans
claim are its strengths. brevity, wit, etc. those wind up confusing almost all
perl developers and users, in my experience, because you have to shift gears
mentally to figure out wtf a piece of code is doing, what the developer
intended it to do, and thus diagnosis is a pain. too many perl users just
laugh and say, "yeah, i can't figure it out either." funny until you realize
they're laughing about wasting your time. my second biggest complaint falls
into the reusability of perl by its design. not so modular without some
surgery (minor or major, depending). the C (or ruby or python) code that
people trained on perl develop is, almost always, horridly inefficient.

CPAN is nice, i wish my language of choice (python) had as extensive a library
so easy to use. and then you get into the mess of CPAN, which is littered with
half completed, poorly documented modules. you wind up having two or three
modules that do the same thing but are dependencies elsewhere or actually
implement some promised functionality, etc. (cheeseshop, pip, etc yes ... but
so much stuff isn't deployable like that is my point...)

the perl documentation library was a big selling point about 10 or 12 years
ago, not so much now. everyone else caught up is my point. python, ruby, etc
are now mainstream.

the "perl is everywhere" mantra used to be compelling, too. but python and
ruby are just as widely available on systems and ... far more suited to long
term development and maintenance than perl is. again, "better" languages for
long term use and development are now mainstream. they weren't before.

i tend to sum all this up for someone with "perl sucks" or "don't use perl, it
promotes brain rot". and no, i wont revisit my thinking. perl had its day, but
i think the sun has set and rightfully so.

~~~
pyre

      > "don't use perl, it promotes brain rot"
    
      > and no, i wont revisit my thinking.
    

"I don't think this is the tool for the job, THEREFORE IT ROTS YOUR BRAIN! If
you try to talk to me about that, I will chant, "I'M NOT LISTENING" over and
over with my hands on my ears."

Really?

~~~
jnazario
"Really?" yes.

like another commenter said it's a discussion i've had before and haven't
heard compelling arguments in favor of perl, so no i'm not interested in
revisiting it.

that said it IS context dependent. i wont fire you for writing perl one-offs
to maintain some systems or process some files. but i would argue against you
for wanting to ship perl for the reasons i stated, with my main thesis being
that your decision would jeopardize the project's future (assuming it had some
future). i've heard the arguments before, like "you can write clean and
maintainable perl" (which has analogues with "high performance java" and
"long-term maintainable PHP"). the counterpoint is "sure, one can. but people
rarely do. other tools promote those features more readily. pick one of them."

~~~
pyre
None of the reasons in your post would lead me to believe that Perl will 'rot
your brain.' I didn't consider the majority of your post to be a flame/troll,
just your honest opinion. It was the "Perl eats babies, and you can't convince
me otherwise, nyah!" at the end that sort of irked me.

~~~
jnazario
i very firmly believe the following:

first, that some languages promote decent coding practices, while some
actively encourage bad ones, either through crappy idioms, bad docs and a
lousy community, or a lack of immediate penalties.

second, that where you spend much of your time coding has a significant effect
on how you think about problem solving, consequences, etc. the practice of
programming builds behaviors, modes of thinking, and values.

finally, if it isn't clear, i consider perl's features to be substandard to
long term coding. the values it places on hacked up gimmicks (under the guise
of "more than one way to do things" and "see! it's a one liner!") is a large
part of this.

therefore "brain rot" in this case isn't equivalent to years of meth use, but
rather a failure to appreciate crap designs, a failure to perform sound
engineering when you write code, and a failure to think about the future of
your code. i've seen the products of people who write code professionally,
with them having learned through years of coding perl, and it is not pretty.
lots of them.

keep calling me closed minded on the topic, i wont disagree. but the end
result is that when someone tells me that perl is their language of choice and
i'm hiring for a person to write code, it's a deep hole they have to get out
of right away or i won't hire them, nor will many of the people i work with.

~~~
pyre

      > the values it places on hacked up gimmicks (under the
      > guise of "more than one way to do things" and "see!
      > it's a one liner!") is a large part of this.
    

I'm curious where there is official documentation of Perl as a language
putting emphasis on "See! It's a one-liner!" Sure Perl has things like Perl
Golf[1], but I could equally point you to The International Obfuscated C Code
Contest[2]. That doesn't prove that C _as a language_ encourages you to
intentionally obfuscate your code.

    
    
      > when someone tells me that perl is their language of choice
      > [...]  i won't hire them
    

Perl isn't my language of choice, but I'm not sure that I want to work for
someone that has such a view of the world. You're attempting to use a small
piece of data ("I like to program in Perl") to extrapolate a whole lot about a
person.

[1]: <http://en.wikipedia.org/wiki/Perl_Golf_Apocalypse>

[2]: <http://www.ioccc.org/>

~~~
buster
I am wondering why it is as it is. I think it may be because of perls
abundance of short cryptic symbols that people feel somehow "proud" to 1) know
what "while(<>){print if($.==2 || $& && !$x++); $.=0 if (/^--+$/)}" does and
2) to make it even shorter. Because with )(!§&/$?(=)% with hell a lot of
meanings you could write entire perl scripts based on special characters.

A good example is
[http://www.nntp.perl.org/group/perl.beginners/2009/01/msg106...](http://www.nntp.perl.org/group/perl.beginners/2009/01/msg106031.html)
that i just found googling for perl one liners. The OP want's to know what
this line does, the first answer is "you can make it even shorter!". Somewhat
explains what i try to say ;)

Surely there is a lot of clean perl code out there but from my experience at
customers (i'm consultant) what happens in-house in some development
departments looks very very very different. Then again i've seen a lot broken,
half-tested and unmaintained CPAN modules as well.

~~~
draegtun
One liners are an (extreme!) _optimisation_ and programmers feel quite _proud_
when they able to optimise code :)

And it's not restricted to Perl: <http://news.ycombinator.com/item?id=4906370>

_> Then again i've seen a lot broken, half-tested and unmaintained CPAN
modules as well._

You also get this in PyPi, Gems, NPM, etc. Just more proof that _Sturgeon's
Law_ exists.

------
peteretep
Good to see so much active work on Unicode support. Really feels like Perl is
coming in to its own as the language to use with Unicode text...

~~~
hahainternet
Unless you've been living under a rock Perl has been the goto language for
Unicode support for half a decade now.

~~~
mpyne
Indeed, the "Unicode support" in question is tracking changes to the Unicode
standard itself. Perl 5 has long been one of the top-flight Unicode
implementations (and not just _implementation_ , but a community-wide set of
best practices, documentation for use, etc.).

~~~
buster
I must say, when Perl is the "top flight" implementation for unicode i don't
want to be a programmer anymore..

[http://stackoverflow.com/questions/6162484/why-does-
modern-p...](http://stackoverflow.com/questions/6162484/why-does-modern-perl-
avoid-utf-8-by-default) Just scroll to the end of the first comment,
boilerplate code.. jesus....

~~~
draegtun
This is very thorough boilerplate code for dealing with all corner cases when
using utf-8 data with Perl.

Instead of dismissing or dissing Tom Christiansen excellent post I would
highly recommend reading into his _The Good, the Bad, & the (mostly) Ugly_
presentation from OSCON 2011 [1] where he compares Unicode handling across
mainstream languages and then see how this code (and Perl) shapes up in
comparison.

In the meantime pragmatic Perl programmers can cover most of that utf-8
boilerplate with just:

    
    
      use 5.016;
      use warnings;
      use utf8::all;
    

Or if you're like me and use _perl5i_ [2] then its just:

    
    
      use perl5i::2;
    
    

[1]: <http://training.perl.com/OSCON2011/index.html>

[2]: <https://metacpan.org/module/perl5i>

------
agranig
Oh, we've done a little Perl code challenge to win some free beer lately:
<http://www.sipwise.com/news/jobs/hiring-by-curiosity-part-1/>

The free beer event is already over, but it's still fun to try if you can make
it :)

------
z3phyr
Thank you perl! You taught me ruby..... And you taught me, how to be dynamic
...

------
rnadna
Fifteen years ago, people would have found this interesting.

~~~
lloeki
Despite being a pythonista at heart and a rubyist at work, Perl is still my
go-to language for when I notice bash scripts getting messy and growing out of
scope and destined to enrich my personal long-term unix toolset.

Yes, Perl is still very relevant today, for me and for countless others[0]

[0]: <https://github.com/languages>

~~~
mogrim
Out of interest, why do you go to Perl instead of Ruby?

~~~
lloeki
1\. It's everywhere. By that I mean my code will work everywhere, without much
thinking about it being installed, versions, or packages, or whatnot.

2\. Ruby is too 'core' and needs too much additionals gizmos to be efficient

3\. Ruby is concise and conventional, while implicitness and terseness are
idiomatic of Perl

4\. I'm no Perl monk but things in my head translate to code structure more
easily in Perl for this use case (unix tools, text/binary/file content stream
manipulation)

5\. Perl strict mode

6\. Occasionally, Perl suid support

7\. Bonus: performance under Windows, or rather lack thereof for Ruby

Mind you, Ruby is extremely apt and I enjoy working with it (especially - but
not only - with Rails), but this is more a matter of using the right tool for
each problem.

