Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Perl 5.18.0 is now available

nntp.perl.org

Post reply on HN
Print view View original

41–50 of 69 posts

Re: Perl 5.18.0 is now available

#41

Post by sliverstorm »

snaky wrote: post #37
btilly wrote: post #25

Earlier quoted context omitted.

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 no…

> variables, like $_. Which you don't use in real programs Oh really? What's wrong with $_ and since when it is?

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.

Re: Perl 5.18.0 is now available

#42

Post by snaky »

sliverstorm wrote: post #41
snaky wrote: post #37

Earlier quoted context omitted.

> variables, like $_. Which you don't use in real programs Oh really? What's wrong with $_ and since when it is?

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.

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.

Re: Perl 5.18.0 is now available

#43

Post by chromatic »

btipling wrote: post #21

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.

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.

Re: Perl 5.18.0 is now available

#47

Post by sigzero »

prollyignored wrote: post #31
peteretep wrote: post #18

Earlier quoted context omitted.

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 for i in [1,2,3]: print i print i # still visible Only functions introduce lexical scope in Python/JS. JS has the ===, this, undefined 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…

Then you don't know anything about Ruby and Python warts. Take yourself out of the conversation please or at Google before you blather.

Re: Perl 5.18.0 is now available

#48

Post by chromatic »

jerf wrote: post #34
latk wrote: post #28

Earlier quoted context omitted.

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…

"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.

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.

Re: Perl 5.18.0 is now available

#49

Post by hello3 »

sigzero wrote: post #47
prollyignored wrote: post #31

Earlier quoted context omitted.

Honestly, AFAIK only PHP comes with a bigger laundry list. The only python wart I know is no block scope for i in [1,2,3]: print i print i # still visible Only functions introduce lexical scope in Python/JS. JS has the ===, this, undefined 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…

Then you don't know anything about Ruby and Python warts. Take yourself out of the conversation please or at Google before you blather.

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.

Re: Perl 5.18.0 is now available

#50

Post by 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...
Post reply on HN