
Perl 5.18.0 is now available - yko
http://www.nntp.perl.org/group/perl.perl5.porters/2013/05/msg201940.html
======
acqq
The changes:

<http://search.cpan.org/~rjbs/perl/pod/perldelta.pod>

------
Su-Shee
Perl 6 releases itself monthly for YEARS now.

<http://rakudo.org/how-to-get-rakudo/>

<http://rakudo.org/downloads/rakudo/>

~~~
rmah
Perl 6 isn't perl.

~~~
mhd
I think there should be some kind of changing of names. For a while it looked
like it's another incremental step, if a big one. Which obviously requires
running two implementations in parallel for a while -- similar to Python 2 and
3, or several operating systems and distros.

But right now, especially once Perl development really picked up, it might be
time to "divorce" the two languages. It seems more like Algol60 vs. Algol68,
or Modula-2 vs. Modula-3. Sure, there's a number in there, but it isn't just
about the version of the main implementation.

Having said that, kudos to the Perl team. I really like that they now release
new versions pretty regularly, which is a good sign to show people that Perl5
ist still very much alive and nobody needs to hold their breath for the time
being.

If only I could use something more recent than 5.8 at work...

~~~
espadrine
Perl5 users won't switch to Perl6 because they're working on Perl5 code and
don't want to change their habits.

Non-Perl devs won't switch to Perl6 because the P word scares them.

So, yes, changing the name might be a good idea.

And making an enjoyable web-based tutorial.

~~~
flogic
Lets assume that I'm switching from Perl5. Why would I switch to Perl6 over
something else? Even assuming Perl6 were to be become production ready
tomorrow, there is a cornucopia of good languages these days. I'm sure Perl6
can claim to be more expressive than most but is that enough?

------
jerf
Can someone explain the point of the lexical subroutines? [1]

In particular, I'm lost on the difference between

    
    
        sub outer {
            my $closurevar;
            my $inner = sub {
                ... use $closurevar...
            };
        }
    

and

    
    
        sub outer {
            my $closurevar;
            my sub inner {
                ... use $closurevar...
            }
        }
    

(I mean this as an honest question. That said, I do hope that I'm missing
something and this is more than just a syntax gloss.)

[1]:
[http://search.cpan.org/~rjbs/perl-5.18.0/pod/perlsub.pod#Lex...](http://search.cpan.org/~rjbs/perl-5.18.0/pod/perlsub.pod#Lexical_Subroutines)

~~~
latk
In the end, everything is syntax. In the first solution, the inner sub would
be called as "$inner->()" or "&$inner()". With lexical subs, we get the much
nicer syntax "inner()". This decreases the syntactic pain when structuring
your code to use nested functions, thus encouraging good design.

Oh, and I guess lexical subs can have prototypes, which were ignored when
calling a coderef with `&` or `->()`. This allows to create really nice, but
properly scoped pseudosyntax.

~~~
prollyignored
> This decreases the syntactic pain
    
    
        use 5.018;
        no warnings "experimental::lexical_subs";
        use feature "lexical_subs";
    

Don't use perl experimental features. Not portable. Not well thought.

May break horribly.

"state sub creates a subroutine visible within the lexical scope in which it
is declared. The subroutine is shared between calls to the outer sub."

So you should be using "state sub"

Or use python which has non-experimental "inner functions"

~~~
latk
You make some very good points esp. wrt verbosity. However, I don't care about
portability or not using experimental features for personal or exploratory
projects: stability is silver, conciseness is gold. The "state" subs are a
consequent extension of the variable declaration keywords "my", "state", and
"our". I can see myself using "my subs" in the future, the other possibilities
have less practical use. "my subs" are proper closures, so they are not
shared.

But, somebody will probably write a "lexsub" pragma that does away with the
"no warnings ...", and portability becomes less of an issue over the course of
time, much like I can nowadays treat the features of v5.10 as given.

Perl had nested functions since v5, just with akward syntax. Does Python have
proper <del>variable declarations</del> closures? That is more of a dealbraker
than non-experimental nested function syntax for me ;-)

~~~
jerf
Because accessing an "uninitialized" variable is a crash, rather than an
implicit value, Python's need for "proper" variable declarations is much less
than in a language that will happily just fill in a value. It may not be quite
as good as proper Perl "use strict", but it's much closer to that level of
goodness than Perl without "use strict". Python has seen fit to introduce a
"use strict" for that very reason; Perl was in a world of hurt before it,
Python is manifestly not.

I scare-quote "uninitialized" because what it really is is _nonexistant_ ,
which isn't the same thing.

------
btipling
The dynamic scoping in Perl seems a bit troublesome to me. Maybe even a
security issue. Can you prevent functions you call from accessing variables in
your scope? Do you have to somehow sanitize your scope if this is an issue?
Seems a little bit worrying. With the exception of closures inside nested
functions, I wish functions just had their own scope and if you want them to
have anything else, just pass it in.

~~~
btilly
This is why wise Perl programmers turn on use strict, and then declare
variables with my. Now attempting to dynamically scope stuff is a compilation
error. (Except for some built in variables, like $_. Which you don't use in
real programs.)

This has been standard advice since the last millennium. But you can't change
it without breaking backwards compatibility.

That said, I do have several good uses for local. But not normal ones. My
favorite is to use local to dynamically scope entries in a hash. I wind up
using this every year or two to put in an automatic check to catch infinite
recursion.

~~~
snaky
> _variables, like $_. Which you don't use in real programs_

Oh really? What's wrong with $_ and since when it is?

~~~
sliverstorm
It's kind of obtuse. If you have to type out "$_", you might as well declare
it and give it a good name.

I personally have no issues doing:

    
    
        foreach @array {
          chomp;
          print;
        }
    

But as soon as I have to type "$_" I make a real variable.

~~~
snaky
What's wrong to type $_ if you want to print "`$_'\n" in your example? Etc. I
don't see any problem with that as $_ is clearly states that's a loop counter.
And let's don't even talk about map/grep/sort and schwartzian transform.

~~~
pfortuny
I don't think he sees that as a Problem. Only he thinks _using it explicitly_
is not to his taste. I have a similar attitude: make it explicitly a new var
if it is going to appear in the code.

Your example is perfectly OK.

TIMTOWTDI, really.

------
greyman
Just curious: Is Larry Wall still involved in Perl development? Haven't heard
from him for a long time...

~~~
sigzero
He is solely working on Perl 6 now.

~~~
colomon
And is fairly active there: <https://github.com/TimToady>

------
alberth
Only 82 more minor releases until Perl 6 will be available.

~~~
latk
Almost ;-) The current perl version is 5.018000, so that would take 982
releases until the numbering scheme breaks down. Of course, Perl v-strings can
have elements of INT_MAX each, but I doubt such high numbers would ever be
used, for back-compat reasons.

------
creaktive
perlbrew install -j 8 -v
[http://cpan.metacpan.org/authors/id/R/RJ/RJBS/perl-5.18.0.ta...](http://cpan.metacpan.org/authors/id/R/RJ/RJBS/perl-5.18.0.tar.bz2)

------
mpyne
I understand why smartmatch is labeled experimental, but what's the "modern
Perl" replacement for given/when? I only use it as a stupid switch statement
but I don't want it breaking with Perl 5.22 either...

~~~
jevinskie
I feel like I was given the impression that they wanted to get smart match
"right" and not abandon it. I guess my use of smart match was a mistake. =(

------
prollyignored
I was a Perl lover once.

And now it seems I understand the haters.

 _Just don't use Perl_.

The language seems fine, productive, even sublime at first but you will
encounter some horrible design features.

Just read the following,

<http://markmail.org/message/h2spyi5za4qheuft>

\-- Perl's data structure serialization is leaky. Thought you made an int ?
Whoa ... serialized as a string.

[http://blogs.perl.org/users/rurban/2013/02/no-indirect-
consi...](http://blogs.perl.org/users/rurban/2013/02/no-indirect-considered-
harmful.html#comment-370624)

\-- A language feature causing a burnout ? Well fuck me !

That's just a tip of the iceberg.

PHP, a fractal of bad design ?

Perl, a quantum bomb, waiting to tick off.

The Modern Perl movement is like saying "I'll close my eyes and crime ceases
to exist."

No best practices will save you from broken language features.

The people who maintain Perl source code, are not a _ _fan_ _ of Modern Perl.
They won't make "strict" the default or introduce signatures or better
OOmodel.

The people who proclaim "Modern Perl" won't fork.

Even this release shows how clueless Perl maintainers are !

* They released a switch statement long long back

* And now they mark it even as "experimental" because of the leaky "my $_" scope.

Oh God ! I will never emotionally invest in another tool.

EDIT: Neutral language.

~~~
hahainternet
I downvoted you because of

a) The poor formatting of your post as a stream of conciousness

b) The condemnation of a language based on a single relatively minor bug

c) The unsupported assertions and unrelated criticisms like not enabling
strict by default

~~~
prollyignored
I use points as I am a bad writer.

* Don't use $a, $b for variable names, affecting sort

* Don't use each for iterating over hashes

* Global effects of ..

* next operator is dynamic
    
    
        sub foo() {
            next; #breaks while loop
        }
    
        while(defined (my $e = shift @items)) { # "0", 0 is false
           foo();
        }
    
    

* <http://www.perl.com/doc/FMTEYEWTK/versus/perl.html>

* Exception model based on $_ and $@

* print "$foo's fun!";

* `use constant` is broken

* my $a, $b ... declares a global $b. Not DWIM at all.

These language features are not worth the debugging time.

Regarding c) I am not a fan of use strict. If the community's priority is
introducing more features like "my $_" than sane exception handling, I don't
want to be a part of it and I won't recommend that language to my boss or the
next FOSS project.

Did I mention XS bugs ?

~~~
lifeguard
Perl is old. By old I mean powerful, mature, stable, and well known.

Some say it is hard to read. I don't know since I have been using it in
production since version 4.

~~~
lifeguard
v 3 actually...

------
will1000
Is python 3 the new perl 6?

