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

Not Your Grandfather’s Perl

stackoverflow.blog

Post reply on HN
Print view View original

71–80 of 257 posts

Re: Not Your Grandfather’s Perl

#71

Post by shp0ngle »

orf wrote: post #59

Sorry, but what? The top features they highlight here are a print statement that adds a new line, a change to the bonkers default of creating some kind of implicit global named variable every time you open a file, representing time as an object (with a strftime function!) and… function signatures? I wouldn’t call this as “Perl moving forward”, I’d call this “Perl is still about 20 years behind everyone else”. Wait un…

It’s a weird feature set to highlight; most of this is available for a long time.

I didn’t know about the function signatures. It’s nice, I guess.

But I don’t want to write perl again anyway.

Re: Not Your Grandfather’s Perl

#72

Post by mikejulietbravo »

csdvrx wrote: post #69
mikejulietbravo wrote: post #51

Perl receives such an unnecessary amount of hate

> Perl receives such an unnecessary amount of hate I agree. We might deny it, because we are geeks, not fashionistas, but there's such a thing as "cool for geeks" like running Rust code on MacOS with some PostgreSQL sprinkled on, and such a thing as "uncool" like running Perl code over Windows and exchanging CSV files. Personally, IDGAF: I care about what works the best, not what's cool. I care about performance. I c…

This^

If your system isn't performant, it's shit. Performant is relative to what you're trying to do and how picky your users are, but at some point you're going to be optimizing for milliseconds without question.

Re: Not Your Grandfather’s Perl

#73

Post by shp0ngle »

HeckFeck wrote: post #61

It's not objective, but I find I have more fun in Perl than any other language. The initial jump was steep, but it helped that I already knew some shell. Now I think in references, I can guess what $_ is going to be, I slap in a big, my $val = s/ /other_thing wherever I want, I could go on! I think $_ belongs to a different era, before levelling everything to the lowest common denominator became seen as a good thing.…

ugh $_

I successfully hide away all my bad perl memories and now it’s coming all back

Re: Not Your Grandfather’s Perl

#74

Post by tyingq »

ksherlock wrote: post #47

Please don't blame bare word file handles on "C heritage" -- Some of the improvements were needed because in places Perl’s Unix/C heritage shows through a little more than we’d like it to in the 21st century. One good example of this is bareword filehandles. You’re probably used Perl code to open a file looking like this: open FH, 'filename.dat' or die;

Maybe the thinking was that Perl's STDIN, STDOUT, STDERR, came from c's (well, stdio.h's) stdin, stdout, stderr?

Which then inspired the bad idea of expanding on that?

Re: Not Your Grandfather’s Perl

#75

Post by HankB99 »

I've used Perl off and on throughout my career, even working at one job that was pretty much exclusively Perl. I've also used Java and C/C++. I've done a lot of work with embedded systems where C was the order of the day.

But back to Perl. I always thought one of the best things about Perl was CPAN. I could nearly always find a module that would accomplish a specific task I needed and then I was just left to write the glue to implement that function (or functions) for my particular needs. I'm surprised CPAN is not mentioned. I wonder if it is still active. I also wonder about security of CPAN in todays environment. I find stuff like pypi and npm to be pretty scary.

I haven't started anything in Perl in quite some time. All the cool kids are using Python so I've been sharpening my skills with that. (But it's all hobby projects these days.)

Re: Not Your Grandfather’s Perl

#76

Post by hpcjoe »

lloeki wrote: post #37
JackFr wrote: post #31

Maybe I’m missing the point of this piece, but it’s probably because I’m still reeling from the author’s idea that adding “say()” which is “print()” with a newline added, is somehow an improvement to the language.

The point is not about `say` itself (which has been there since Perl 5.10, released on 2007/12/18), it's only an example of how much Perl uses modularity (via `use`) to enable new features while ensuring a) code dependent on a new feature alerts on Perl versions without the feature and b) backward compatibility of new Perl versions with old Perl code. Compare: # Perl use feature 'say' vs: # Python from __future__ imp…

This. So much this.

At the $dayjob, writing some python assuming late model 3.10.x, and discovering that the API has changed when I have to make sure it works on 3.6.x and 3.7.x.

Nevermind important libraries like pandas changing the API so some functions you 've used for years just disappear.

I've got 30+ year old perl 5, that just works. And is readable. I wish 2 year old python could just work.

Re: Not Your Grandfather’s Perl

#77

Post by tyingq »

orf wrote: post #59

Sorry, but what? The top features they highlight here are a print statement that adds a new line, a change to the bonkers default of creating some kind of implicit global named variable every time you open a file, representing time as an object (with a strftime function!) and… function signatures? I wouldn’t call this as “Perl moving forward”, I’d call this “Perl is still about 20 years behind everyone else”. Wait un…

>“Perl is still about 20 years behind everyone else”

The version of Perl on your favorite Linux distro might be. I think that's the point the article was trying to make...that distros ship VERY old versions of Perl.

Re: Not Your Grandfather’s Perl

#78

Post by forgotmypw17 »

duskwuff wrote: post #17
forgotmypw17 wrote: post #4

With function signatures and state variables added in 5.010, I consider Perl feature-complete and have not really missed anything from it for as long as I've been writing Perl. What I do appreciate that's missing from many other languages and systems is the extreme committment to backwards compatibility. The knowledge that the next minor release won't break existing scripts is underrated, IMO. Solo project with ~23K…

Signatures were added in 5.020, and [edited:] were considered experimental until 5.036.

Thanks for the correction. I don't use them anymore (instead doing a few lines of sanity-check boilerplate in each sub) so that's why I made that mistake.

Re: Not Your Grandfather’s Perl

#79

Post by forgotmypw17 »

arthurcolle wrote: post #11
forgotmypw17 wrote: post #4

With function signatures and state variables added in 5.010, I consider Perl feature-complete and have not really missed anything from it for as long as I've been writing Perl. What I do appreciate that's missing from many other languages and systems is the extreme committment to backwards compatibility. The knowledge that the next minor release won't break existing scripts is underrated, IMO. Solo project with ~23K…

What is your project? Raku has some cool features and interesting syntax, I took a look at it before the rename, but find myself reaching for Python for basically everything.

Link is in my profile.

Re: Not Your Grandfather’s Perl

#80

Post by forgotmypw17 »

cryptonector wrote: post #58
forgotmypw17 wrote: post #4

With function signatures and state variables added in 5.010, I consider Perl feature-complete and have not really missed anything from it for as long as I've been writing Perl. What I do appreciate that's missing from many other languages and systems is the extreme committment to backwards compatibility. The knowledge that the next minor release won't break existing scripts is underrated, IMO. Solo project with ~23K…

Needs static typing. I'll let myself out now.

I make up for this by writing short subprocedures and many sanity checks.
Post reply on HN