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

141–150 of 257 posts

Re: Not Your Grandfather’s Perl

#141

Post by jandrese »

anthk wrote: post #16
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.

Perl's bindings for Win32 and OLE are amazing.

While you can use them, I do not recommend it. The problem is when you want to convert a script into an EXE so not everybody has to install Strawberry Perl. Apparently some viruses are written in Perl because Windows Defender flags any exe you build as a virus and deletes it. Also, changing the application icon doesn't work, so you're always distributing a Camel app.

It's a shame too because as you say the Win32 API stuff works great up until the antivirus kicks you in the nads.

Re: Not Your Grandfather’s Perl

#142

Post by fijiaarone »

lupire wrote: post #129
singingfish wrote: post #114

Earlier quoted context omitted.

One of my criteria for good tools is that they scale well from the smallest possible use case to absolutely massive. Git meets this criterion for example. Anyway I manage a 250kline code base written over 20 years which is in surprisingly good shape consider it's age and how many people have touched it. Last time we upgraded the perl for the first time in a decade - going through the addition of many features and maj…

"Perl makes easy things easy and hard things possible."

What we need from a programming language is to make medium complexity things, at worst, medium difficulty.

I don’t care about hard problems, and easy problems.

Re: Not Your Grandfather’s Perl

#143

Post by jandrese »

flukus wrote: post #137
balthigor wrote: post #131

PERL was the duct tape of the early Internet. Remember CGI scripts in PERL on FreeBSD? Good Times.

I deal with so many over complicated enterprise solutions that would be much better with this level of abstraction. CGI scripts are basically FaaS on your own machines.

Amazon Lambda is basically just CGI scripts hiding behind fancy math words.

Re: Not Your Grandfather’s Perl

#144

Post by jandrese »

avyjit wrote: post #19
csdvrx wrote: post #3

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

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.

Re: Not Your Grandfather’s Perl

#145

Post by Spooky23 »

alxmdev wrote: post #134

I think of Perl as a Python-PHP hybrid. A pragmatic product of its time that will endure, and while I'm grateful for never needing it, I'm glad that it's a solid option still for those who do.

I used to write automation for systems management with an old IBM product called Tivoli.

It was the best job ever. The systems monitoring tool used ancient Perl4 (this was circa 2001 when Perl4 was like a decade old) and Prolog to handle event management.

Re: Not Your Grandfather’s Perl

#146

Post by weare138 »

senorsmile wrote: post #63
yakubin wrote: post #35

Earlier quoted context omitted.

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

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 great book but for anyone new make sure you get a copy of the 7th addition. It originally came out in '93. The 6th edition is 12 years old now.

Re: Not Your Grandfather’s Perl

#147

Post by wainstead »

singingfish wrote: post #120
wainstead wrote: post #101

Earlier quoted context omitted.

CPAN was definitely the envy of other languages for many years but I feel most have caught up by now.

Kind of caught up. I don't think there's much like cpantesters and the strong emphasis on testing elsewhere.

Agreed, and the cpan shell too.

Re: Not Your Grandfather’s Perl

#148

Post by kamaal »

paulryanrogers wrote: post #139
usefulcat wrote: post #91

Earlier quoted context omitted.

The fact that it's possible to craft deliberately obfuscated code in a language doesn't actually tell you much about the language.

My guess is that for many people it's hard to write non-obfuscated Perl code. It has so many operators and ways of doing things that walking into someone else's code may feel like having to learn everything from scratch. (Higher Order Perl and such not withstanding.)

In all honesty I have read more unreadable code in Python, than Perl. And I have written nearly equal of both over my career.

You can write bad code in any language. Bad variable names(sometimes single alphabet names), functions running pages long, duplicate code, algorithmically inefficient code, no error handling, master try/catch statements, OO abuse, functions with unpredictable side effects etc etc.

Early internet saw a flood of newbie programmers, and therefore a flood of badly written code too.

For that matter you also see badly written C/C++ code from those days. How do you think C++ got its reputation for being too bloated beyond practical use?

Re: Not Your Grandfather’s Perl

#149

Post by wainstead »

0xbadcafebee wrote: post #50

I still use Perl whenever I need to get something complex done quickly. Whether it's the handy command-line switches and features for easier one-liners, or just easier stream text processing, or easier external command execution, or the huge library of modules that often support things Python doesn't, Perl is my "fuck it, I just need to get this done" language. I can't wait for the day that programming languages as a…

For me it’s any kind of text processing; especially code generation for some one-off task, like churning out SQL or bash scripts/shell commands. Faster than doing it by hand. __END__ is one of my best friends because I can dump the input data right into the script. On the rare occasion I am irked whatever language I’m working in does not have format/write, which comes from the Fortran tradition iirc.
Post reply on HN