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

181–190 of 257 posts

Re: Not Your Grandfather’s Perl

#181

Post by cutler »

jbullock35 wrote: post #124
senorsmile wrote: post #63

Earlier quoted context omitted.

The "Learning Perl" book from O'Reilly is the best book to do this (and imho is one of the best written programming books).

Learning Perl is a classic of the form---the best intro programming book that I've ever seen, at least for smart readers who've done some kind of programming (any kind, with any language) in the past. The contrast to Learning Python is noteworthy. The latter book is useful, too, but it's about ten times bigger and much less focused on introducing a language.

I find Mark Lutz's writing style extremely tedious, having forced myself to wade through "Learning Python".

Re: Not Your Grandfather’s Perl

#182

Post by thatwasunusual »

HankB99 wrote: post #75

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

> I'm surprised CPAN is not mentioned. I wonder if it is still active.

CPAN is indeed alive and kicking; https://metacpan.org/

Re: Not Your Grandfather’s Perl

#183

Post by cutler »

btilly wrote: post #94
stjohnswarts wrote: post #48

Earlier quoted context omitted.

I would argue that ruby as almost all the strengths of perl and conciseness with more coherency if you want a perl-like fluidity and terseness. I personally like python for anything that becomes more than a 100 lines of bash.

Due to poor coding practices (eg monkeypatching) and a weaker testing culture (by default Ruby does not run unit tests when installing libraries) I've found Ruby to be substantially less reliable than Perl. However the world has moved on to Python. So I curse every time I again have to look up how subprocess works for what I'd do in Perl with backticks.

To be fair to Python subprocess is not simply a substitute for backticks in Perl or Ruby. It's supposed to protect you from some of the more obscure problems which can happen with shell expansion.

Re: Not Your Grandfather’s Perl

#184

Post by cutler »

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.

Anyone remember smart match? Oh dear - a real low point for Perl.

Re: Not Your Grandfather’s Perl

#185

Post by cutler »

thatwasunusual wrote: post #182
HankB99 wrote: post #75

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

> I'm surprised CPAN is not mentioned. I wonder if it is still active. CPAN is indeed alive and kicking; https://metacpan.org/

The thing is back in the day 35,000 modules on CPAN was a big deal but if you look at https://modulecounts.com that's since been dwarfed by Python/PyPI (398,000), Ruby/Rubygems (173,000), PHP/Packagist (351,000) and JS/npm (2,116,000).

Re: Not Your Grandfather’s Perl

#186

Post by cutler »

ra88it wrote: post #112

When I was about 20, I went to the local Barnes and Noble to find a book about programming. Picked up the O'Reilly Javascript book from around 2000. Had no idea what javascript was, just wanted to learn how to program and trying to pick the most popular language. $40 later, I got home and started reading! Very confusing, the first half of the book covered the language runtime (I think?) and the second half covered th…

That would be "Programming Perl" by Larry Wall. For me too it was the only programming book of that size I was compelled to read cover to cover. Larry is a great writer but maybe that's to be expected from a linguist. If Python is the number cruncher's favourite language Perl (and subsequently Ruby) must be the linguist's favourite. I got into programming after being intrigued by regular expressions in the advanced section of a chapter on Search And Replace in Dreamweaver 3 Bible back in 2000. At the end of the section there was a footnote to Jeffrey Friedl's "Mastering Regular Expressions" which I read cover to cover. Most of the examples were written in Perl as it was the only language with regex support so deeply baked-in so I had to then go to the source - "Programming Perl" by Larry Wall.

Re: Not Your Grandfather’s Perl

#187

Post by cutler »

wistlo wrote: post #13

"Bare bones" seems to be a good thing for Perl. I use Strawberry Perl on Windows and it is orders of magnitude faster than Powershell for processing large files of text strings using regular expressions. I hope the addition of a "new object-oriented programming framework" won't take away the "bare-bones" speed of the current release.

Don't worry. The Perl community, which I love BTW, has bee fighting over Moose, Mouse, Moo and the inclusion of a Meta Object Protocol in the core since the mid-2000s which, I would argue is partly responsible for its decline. So for Perl OOP will always remain an option unless you count blessed hashrefs.

Re: Not Your Grandfather’s Perl

#188

Post by cutler »

justinator wrote: post #55
rurban wrote: post #49

Earlier quoted context omitted.

The best OO frameworks Mouse and cperl make it faster. Moose, Moo and Corinna signicantly slower. Guess which frameworks are recommended

Corinna is essentially the working spec of the new class system in Perl. I’m not sure being performant was ever the goal.

I think this is where Ruby's reputation for being slow is a bit misleading. Perl is faster because it doesn't have OOP baked-in. Pre-load Moose and Perl's performance isn't that different than Ruby's.

Re: Not Your Grandfather’s Perl

#190

Post by gyulai »

So, this is on the stack overflow blog. And Joel Spolsky famously thinks that to rewrite a codebase from scratch is the "single worst strategic mistake that any software company can make" [1].

I wonder if this is how you end up being a Perl user in 2022.

[1] https://www.joelonsoftware.com/2000/04/06/things-you-should-...

Post reply on HN