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

151–160 of 257 posts

Re: Not Your Grandfather’s Perl

#151

Post by asicsp »

yakubin wrote: post #35
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…

I’ve had very limited contact with Perl, but for scripting purposes it does seem like the best option, so I intend to sit down to it and learn it better. It looks like a great next step after sed and awk (perl -pe). I love the ability to write terse scripts, reasonable speed for a scripting language and, as you said, backwards-compatibility (such a stark contrast compared to Python).

I wrote ebooks on CLI one-liners featuring grep/sed/awk/perl/ruby/coreutils/etc. These are free to read online: https://github.com/learnbyexample/scripting_course#ebooks

Plenty of examples and exercises.

Re: Not Your Grandfather’s Perl

#152

Post by wainstead »

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

A few years ago I pulled out Higher Order Perl and started playing with some of the advanced features/techniques available in the language. And it was really fun! I think Perl was the first popular multi-paradigm language.

Re: Not Your Grandfather’s Perl

#153

Post by sigzero »

throwaway111555 wrote: post #118
jrochkind1 wrote: post #88

Earlier quoted context omitted.

No, and if it is, who knows what version it is. I think that's the main thing preventing one from using ruby like this. It is otherwise preferable in pretty much every way. Perl is kind of pre-installed on virtually every Unix-like system for what are at this point historical/legacy reasons. It is unlikely any other language can ever achieve this at this point.

AFAIR, Red Hat stopped including Perl by default since RHEL8 (

RHEL 9.0 provides the following dynamic programming languages:

    Node.js 16
    Perl 5.32
    PHP 8.0
    Python 3.9
    Ruby 3.0

Re: Not Your Grandfather’s Perl

#154

Post by int_19h »

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.

https://amoffat.github.io/sh/

Re: Not Your Grandfather’s Perl

#156

Post by int_19h »

duskwuff wrote: post #108
theonething wrote: post #98

Earlier quoted context omitted.

are Perl function signatures the PHP/Python equivalent of type hints?

This may shock you, but: historically, Perl functions did not have declared arguments. Like, at all. The function just got arguments implicitly passed to it as an array (@_), and parsing that into individual variables was up to the function -- so most functions would start like this: sub myFunction { my ($self, $arg1, $arg2) = @_; ... } Or, in older code, you might even see this: sub myFunction { my $self = shift; #…

> If you passed too many or too few arguments to a function which worked this way, the extra arguments would silently be ignored, or missing arguments would silently show up as undef.

This part probably won't shock anyone given the prevalence of JS today. Which is kinda sad, given that it's 35 years since Perl was first a thing.

Re: Not Your Grandfather’s Perl

#157

Post by weare138 »

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.

https://metacpan.org/pod/types

Re: Not Your Grandfather’s Perl

#158

Post by int_19h »

jandrese wrote: post #144
avyjit wrote: post #19

Earlier quoted context omitted.

When you refer to modern hardware with vectorization, are you saying perl beats software that makes use of vector instructions? If so wow! Afaik perl is a plain old interpreted language with no JIT, what makes it so fast? I had an idea of perl as in the same performance category as Python, Ruby and friends.

Perl does a kind of half JIT when you start a script. It doesn't compile fully down to native machine code, but it does parse and lex the script to build an internal representation. The code is then interpreted, but since it doesn't have to parse each line again it runs very fast and also you can interpret code on the fly in a variable so you get the best of both worlds.

This has been the usual way to implement interpreted languages for decades; Perl isn't special in that regard. JIT generally refers to generation and execution of native code specifically.

Re: Not Your Grandfather’s Perl

#159

Post by btilly »

int_19h wrote: post #154
btilly wrote: post #94

Earlier quoted context omitted.

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.

https://amoffat.github.io/sh/

The documentation for that says, "Specifically, Windows is not supported."

My use case was for scripting git operations. And the list of target environments included Windows.

So no, that wouldn't have worked for me.

Post reply on HN