Perl 5.18.0 is now available(nntp.perl.org) |
Perl 5.18.0 is now available(nntp.perl.org) |
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.
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 ?
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.
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 ;-)
I scare-quote "uninitialized" because what it really is is nonexistant, which isn't the same thing.
Python has had proper closures forever, just with awkward syntax. But there is nothing you can do with closures in Perl that I can't translate directly into Python code that does the exact same thing in the exact same way. (I may need to switch from a scalar to an array with 1 element so that modifications in a child scope are visible in the outer, but conceptually things remain the same.)
I'm not saying that you should use Python - I switch it up but Perl is my goto language - however you shouldn't spread incorrect rumors about Python.
Or most languages in the ML family (like OCaml or Haskell), where multi-argument functions are actually implemented as a series of nested one-argument functions.
Its time for you to produce your magical programming language and claim your fields medal.
Till then, there are people who are using and will be using Perl with endlessly growing user base for three decades.
As a side note and talking of bugs, Perl easily has the best testing culture in the entire open source language scenario.
Some say it is hard to read. I don't know since I have been using it in production since version 4.
The only python wart I know is no block scope
for i in [1,2,3]:
print i
print i # still visible
The only ruby wart for me is the difference between block/lambda/Proc and perly features.
Java/Go/Lua don't turn you into a omlette, with their language features. Nor do they leak memory in XS like perl.
C++ is a differnt story.
EDIT: Added JS
> Regarding c) I am not a fan of use strict
Apparently you also aren't a fan of use warnings, otherwise you would have seen that that my $a, $b doesn't do what you think it does.
# perl -E 'use strict; use warnings; my $a, $b;'
Parentheses missing around "my" list at -e line 1.
my ($a, $b);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.
I will.
But hey, generally it's not a big hassle, from a programmer's perspective that version ain't that outdated. About the only thing I really miss is "//="...
http://wiki.python.org/moin/PythonWarts
Here is one of the first Google hits for Ruby:
http://jgaskins.org/blog/2012/05/16/ruby-warts/
Every languages has warts. Lots of them.
http://docs.python.org/3/tutorial/controlflow.html#function-... section 4.7.1 if you're curious
Generally though I'd say Perl has hundreds (or maybe thousands) of warts for every one Python or Ruby has.
A specific problem that fixed this in my memory was a bug in my co-worker's code which boiled down to his looping over an array with $_, then calling a function in his loop that was in a CPAN library that assigned to $_. The result was that he wiped out his whole array.
Whenever you are calling out to code that someone else wrote, you don't know if issues like that could exist, and therefore it isn't safe to use $_. Conversely if you're writing code that someone else will call, be a good citizen and don't assign to $_ either implicitly or explicitly.
For example, the following code performs as expected, and prints "123"
use 5.016;
use warnings;
my @a = qw(1 2 3);
for (@a) {
my @b = qw(4 5 6);
for (@b) {
$_ = 1;
}
print;
}
use 5.016;
use warnings;
sub test {
my @b = qw(4 5 6);
for (@b) {
$_ = 1;
}
}
my @a = qw(1 2 3);
for (@a) {
test;
print;
}
use 5.016;
use warnings;
sub test {
$_ = 1;
}
my @a = qw(1 2 3);
for (@a) {
test;
print;
}
And yes, I both fixed my coworker's code to not use $_, and submitted a patch to the CPAN library with the bug. But the experience taught me to be cautious about $_.
I personally have no issues doing:
foreach @array {
chomp;
print;
}
Your example is perfectly OK.
TIMTOWTDI, really.
I just think saying not to use $_ in real programs is a bit extreme. Truthfully, I don't use it in for loops at all, but my code invariably uses a lot of maps and greps. To throw away the expressiveness of map and grep because there may be a problem in some third party library I use at some point is too high a price for me. Especially because by the nature of how I use map and grep I think I'm less likely to run into problem code in those cases, and if I do I think it will be fairly obvious.