To my knowledge, Rakudo hasn't reached the point where its developers call any Star (runtime plus libraries) release a "major release" of the sort that users ought to use in the wild for a year or more.
Monthly releases are a good step in the right direction, but they aren't very useful to those of us who need something more robust.
Perl 5 currently offers this robustness, while Rakudo unfortunately does not. The other Perl 6 implementations end up being worse than Rakudo in this respect, as well.
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...
In particular, I'm lost on the difference between
sub outer {
my $closurevar;
my $inner = sub {
... use $closurevar...
};
}
sub outer {
my $closurevar;
my sub inner {
... use $closurevar...
}
}
[1]: http://search.cpan.org/~rjbs/perl-5.18.0/pod/perlsub.pod#Lex...
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.
OK, I can think of some chunks of code I've written where that would make modest sense.
While my benefit/cost threshold for adding a syntax feature is generally much higher than the Perl team's (... much, much higher...), this does seem to fit in with their other additions then. Thanks.
use 5.018;
no warnings "experimental::lexical_subs";
use feature "lexical_subs";
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"
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.
Second, I love it for security-related stuff where I really don't want something to escape a scope. I have a value that represents the current user I am processing a request for, which is used for security checks, and by local'ing the variable in the context of the handler, I can be very confident that it absolutely, positively will not escape into the next request.
It also turns out to mean that if you're in a code base that has some unfortunate "global" variables, that local lets you turn them into much less "global" variables, as you can local them with confidence about how it won't escape out of scope. Of course, the better solution is to not do that, or to fix it, but we don't live in a perfect world....
Oh really? What's wrong with $_ and since when it is?
Perl's access control model uses a metaphor of polite permission. Without hardware enforcing memory protection, any memory protection at the language level is a modest barrier for the determined anyhow.
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...
-- 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.
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
* 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();
}
* 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 ?