Perl 5.18.0 is now available • Hacker News Board

Re: Perl 5.18.0 is now available

#31

Post by prollyignored » Sat, May 18, 2013, 6:52 PM UTC

peteretep wrote: post #18

prollyignored wrote: post #15

Earlier quoted context omitted.

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…

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 memory in XS like perl.

C++ is a differnt story.

EDIT: Added JS

Re: Perl 5.18.0 is now available

#32

Post by lifeguard » Sat, May 18, 2013, 7:12 PM UTC

prollyignored wrote: post #15

hahainternet wrote: post #14

Earlier quoted context omitted.

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

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…

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.

Re: Perl 5.18.0 is now available

#33

Post by initself » Sat, May 18, 2013, 7:13 PM UTC

mhd wrote: post #10

rmah wrote: post #5

Earlier quoted context omitted.

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

Here's mst's suggestion for changing the name Perl 5 to "Pumpkin Perl":

http://shadow.cat/blog/matt-s-trout/pumpkin-perl-breakdown/

Re: Perl 5.18.0 is now available

#34

Post by jerf » Sat, May 18, 2013, 7:25 PM UTC

latk wrote: post #28

jerf wrote: post #27

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/~rjb…

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.

Re: Perl 5.18.0 is now available

#35

Post by latk » Sat, May 18, 2013, 7:28 PM UTC

prollyignored wrote: post #30

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

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 variable declarations closures? That is more of a dealbraker than non-experimental nested function syntax for me ;-)

Re: Perl 5.18.0 is now available

#36

Post by will1000 » Sat, May 18, 2013, 7:28 PM UTC

Is python 3 the new perl 6?

Re: Perl 5.18.0 is now available

#37

Post by snaky » Sat, May 18, 2013, 7:28 PM UTC

btilly wrote: post #25

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.

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?

Re: Perl 5.18.0 is now available

#38

Post by jerf » Sat, May 18, 2013, 7:29 PM UTC

btilly wrote: post #25

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.

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…

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

Re: Perl 5.18.0 is now available

#39

Post by jerf » Sat, May 18, 2013, 7:32 PM UTC

latk wrote: post #35

prollyignored wrote: post #30

Earlier quoted context omitted.

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

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

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.

Re: Perl 5.18.0 is now available

#40

Post by snaky » Sat, May 18, 2013, 7:34 PM UTC

mhd wrote: post #17

aduitsis wrote: post #12

Earlier quoted context omitted.

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…

There are some modules that don't support Perl 5.8, like Data::Show. RHEL's policy about Perl versions is just horrible.