Not Your Grandfather’s Perl
21–30 of 257 posts
Re: Not Your Grandfather’s Perl
#22Damn Pythonistas! Get off my lawn!
Re: Not Your Grandfather’s Perl
#23Even on modern hardware with vectorization, the speed of perl is hard to match for stream processing. I write and deploy brand new perl code in 2022 to replace some clunky python and javascript - for real! AMA!
I'm working in Windows (employer's choice) and need to process some huge data files on the desktop. Perl (Strawberry Perl for Windows) is much faster than native Powershell (or CMD) scripts. A few Perl one-liners and I have 2 GB processed in a couple of minutes. Big fan of Perl here.
This matches my experience: my task is IO bound, processing tens of GB in a matter of minutes.
> I'm working in Windows (employer's choice)
Work prefers MacOS, Windows is my personal choice :)
Windows 10 and 11 are a pleasure to use: between the Windows Terminal and tools like AutoHotKey, there's no Linux equivalent, even for a commandline geek.
Using Windows (and Perl, and other weird things I like) may not be fashionable, but it's hard to beat.
Re: Not Your Grandfather’s Perl
#24Even on modern hardware with vectorization, the speed of perl is hard to match for stream processing. I write and deploy brand new perl code in 2022 to replace some clunky python and javascript - for real! AMA!
1. What's your top technique for keeping it fast? 2. Are you hiring?
Using the stock install as much as possible.
Since a perl interpreter is available about everywhere, this makes the scripts cross platform very easily too.
> 2. Are you hiring?
Maybe? You have no email in your profile. Can you please send your CV to my nickname at outlook dot com?
Re: Not Your Grandfather’s Perl
#25With 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.
No, 5.36 stabilised them.
https://perldoc.perl.org/perldelta#Core-Enhancements
> The 5.36 bundle enables the signatures feature. Introduced in Perl version 5.20.0, and modified several times since, the subroutine signatures feature is now no longer considered experimental. It is now considered a stable language feature and no longer prints a warning.
Re: Not Your Grandfather’s Perl
#26Even on modern hardware with vectorization, the speed of perl is hard to match for stream processing. I write and deploy brand new perl code in 2022 to replace some clunky python and javascript - for real! AMA!
What's the difference when compared with other scripting languages? Is it just all-around faster or it's about some particular application?
Compared to every other scripted languages I've tried, it's always faster - so much that it often rivals compiled code (even with extra optimizations as explained before)
> Is it just all-around faster
Yes - also faster to deploy, and harder to break in deployment due to dependencies rarely evolving. No need to pip install whatever.
Consequently, tracking modules' versions (say in python) and their break in compatibility is a thing of the past. Some may say it's because it's dead. I guess I'm a necrophiliac then, because it makes my life so much easier that I'm loving it :)
Re: Not Your Grandfather’s Perl
#27Damn Pythonistas! Get off my lawn!
Re: Not Your Grandfather’s Perl
#28Even on modern hardware with vectorization, the speed of perl is hard to match for stream processing. I write and deploy brand new perl code in 2022 to replace some clunky python and javascript - for real! AMA!
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.
IDK. I didn't waste time checking why.
My guess is that due to the much smaller code size, it reaches a sweetpoint where it fits nicely in the L1 or L2 cache.
But it's just a hunch, I couldn't prove it.
Re: Not Your Grandfather’s Perl
#29I'd argue perl's major value is from stability in the sense that what the perl developers write today can be run on the perl available on any machine, new or old. If a lot of perl developers end up use'ing lots of these new features that feeling of compatiblity will go away.
If you need new code you write today to run on 20 year old systems, don't use the newer features. Perl 5.36 is backwards compatible to code written for Perl 5.6 after all. If you need 20 year old code to run on new machines, the same thing occurs - you hand it to a recent Perl 5 and it works. Compare and contrast the last 20 years of PHP or Python.
You're only noticing half of the picture.
If you want to write code that'll still run in 20 years, do the same.
Re: Not Your Grandfather’s Perl
#30Earlier quoted context omitted.
Signatures were added in 5.020, and [edited:] were considered experimental until 5.036.
> and are still considered experimental No, 5.36 stabilised them. https://perldoc.perl.org/perldelta#Core-Enhancements > The 5.36 bundle enables the signatures feature. Introduced in Perl version 5.20.0, and modified several times since, the subroutine signatures feature is now no longer considered experimental. It is now considered a stable language feature and no longer prints a warning.