Perl 5.18.0 is now available(nntp.perl.org)
nntp.perl.org
Perl 5.18.0 is now available
http://www.nntp.perl.org/group/perl.perl5.porters/2013/05/msg201940.html
68 comments
Perl 6 releases itself monthly for YEARS now.
http://rakudo.org/how-to-get-rakudo/
http://rakudo.org/downloads/rakudo/
http://rakudo.org/how-to-get-rakudo/
http://rakudo.org/downloads/rakudo/
To be fair, so does Perl 5. Perl 5.18.0 happens to be the yearly major release.
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.
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.
From the perspective of somebody who needs a production-grade Perl implementation, Rakudo doesn't cut it, I'm saddened to say.
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.
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.
Perl 6 isn't perl.
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...
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...
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.
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.
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?
> Perl5 users won't switch to Perl6 because they're working on Perl5 code and don't want to change their habits.
I will.
I will.
I am already switching to Perl6.
You can use perlbrew to install any version of Perl your heart desires in a local directory of your choosing. You can also install multiple versions and easily swap them.
We deploy to a RHEL server where the stock Perl is 5.8.8. Sure, migrating that to a perlbrew/local::lib setup with up-to-date CPAN modules would be really nice, but would require some major testing, and right now nobody has the time for that. Never change a running system sigh...
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 "//="...
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 "//="...
There was a big argument on a name change. It isn't going to happen.
Here's mst's suggestion for changing the name Perl 5 to "Pumpkin Perl":
http://shadow.cat/blog/matt-s-trout/pumpkin-perl-breakdown/
http://shadow.cat/blog/matt-s-trout/pumpkin-perl-breakdown/
No. Just no. That is stupid as stupid can be.
Can someone explain the point of the lexical subroutines? [1]
In particular, I'm lost on the difference between
[1]: http://search.cpan.org/~rjbs/perl-5.18.0/pod/perlsub.pod#Lex...
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...
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.
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.
"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.
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.
That feature's been on the wishlist for many, many years. It was also one of the early features specified for Perl 6, if that means anything.
> This decreases the syntactic pain
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"
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"
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 ;-)
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 ;-)
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.
I scare-quote "uninitialized" because what it really is is nonexistant, which isn't the same thing.
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 ;-)
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.
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 use python which has non-experimental "inner functions"
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.
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.
Aside from the syntactic differences, I would assume that lexical subroutines can have prototypes while subroutines stored in variables cannot.
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.
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.
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.
I like local for two big uses: One, in unit testing, it's a cheap way to completely mock out a function within some scope. I know there's various test methods for that, but frankly local'ing a glob is so easy both to use and to make do exactly what I need that it's often still easier than even invoking the library.
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....
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....
>variables, like $_. Which you don't use in real programs
Oh really? What's wrong with $_ and since when it is?
Oh really? What's wrong with $_ and since when it is?
The problem is that $_ is global and always in package main.
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.
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.
It's also lexicalized in every loop, so writing to it doesn't affect anything else. The only time I can think of you would have to worry about this is if some function modified $_ without any loop, and I would consider that a bug (similar to any function that set a static class variable indiscriminately).
For example, the following code performs as expected, and prints "123"
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;
}
It is not lexicalized, it is localized.
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 $_.
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 $_.
Sorry, that's correct. I have lexical on the brain.
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.
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.
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:
I personally have no issues doing:
foreach @array {
chomp;
print;
}
$_ is pronounced "it" and should only be used in small blocks of code. This is in much the same way that in a paragraph of text "it" should only be used for transitory sentences on the same topic as the previous one.
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.
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.
Your example is perfectly OK.
TIMTOWTDI, really.
When I first started using perl, I too, worried about this and other similar issues. But after 10+ years of using perl, I've never -- not once -- actually run into this problem in the real world.
I have not been so lucky. I've had to submit patches to CPAN modules because their use of $_ broke dynamically scoped access to $_.
Can you prevent functions you call from accessing variables in your scope?
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.
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.
Just curious: Is Larry Wall still involved in Perl development? Haven't heard from him for a long time...
He is solely working on Perl 6 now.
And is fairly active there: https://github.com/TimToady
He's not involved in Perl 5 development anymore AFAIK.
Only 82 more minor releases until Perl 6 will be available.
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.
Perl 5 will not ever go to Perl 6. Although you probably forgot the sarcasm tag. :)
perlbrew install -j 8 -v http://cpan.metacpan.org/authors/id/R/RJ/RJBS/perl-5.18.0.ta...
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...
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. =(
[deleted]
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...
-- 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.
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.
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
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
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
* 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 ?
* 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 ?
You seem to have to magically figured out the art of creating software without bugs.
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.
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.
What modern language do you use that doesn't also have a laundry list of warts?
Honestly, AFAIK only PHP comes with a bigger laundry list.
The only python wart I know is no block scope
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
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
Then you don't know anything about Ruby and Python warts. Take yourself out of the conversation please or at Google before you blather.
Enlighten us.
Python has its own wiki about them for one (first Google hit):
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://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.
Why doesn't he know anything about Python or Ruby warts? I think his complaint about Python is valid. The other wart I would add is Python having a default empty list in a method signature. In successive calls to the function if you modify the list it retains it's value. (The solution is to have it set to None in the method signature). Read
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.
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.
> my $a, $b ... declares a global $b. Not DWIM at all.
> 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.
> 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);Is python 3 the new perl 6?
http://search.cpan.org/~rjbs/perl/pod/perldelta.pod