Hacker News Reader

Comment by ceautery | Hacker News Reader

It's still difficult to beat perl in a production Unix environment to fix a hot issue, especially if you know your way around regular expressions. When I hear comments like "now you have two problems", or "it's harder to read than to write", or references to the P in LAMP being Python or PHP, I chuckle to myself.

Here's an example of how I use perl, off the cuff, in day to day production life: http://cautery.blogspot.com/2010/09/concise-perl.html

View on HN

> http://cautery.blogspot.com/2010/09/concise-perl.html

This illustrates the use of Perl in quick one-liners and helps understand why Perl isn't suitable for writing maintainable code. I've seen far too many cases of (and done it myself too often) assumptions like "there's no other tags ending in 'nk'" and "I can parse this XML/HTML content with simple regexps" in the quick & dirty code that is typical Perl (it works, let's use it...). This is where much of the productivity gains and "fun" comes from in the short term and where all the maintainability problems come from in the long term.

Evangelists will preach "modern Perl", good style and Moose to you, but these are half-baked, tacked-on solutions, they aren't fun and the overhead destroys the perceived advantages over other languages while not alleviating the massive disadvantages Perl has (performance, dynamic typing, lack of proper threading support...) over modern languages for medium to large size projects.

So, use if for one-off jobs and one-liners but don't get sucked into it for anything that intends to grow into a few 100 lines or more.

Disclaimer: I've used mostly Perl for ~15 years now and built a company with assorted technical debt, so this is biased on my personal hindsight. YMMV.

> This illustrates the use of Perl in quick one-liners and helps understand why Perl isn't suitable for writing maintainable code.

That's seems like a bit of a stretch to accept from a single anecdote.

> I've seen far too many cases of (and done it myself too often) assumptions like "there's no other tags ending in 'nk'" and "I can parse this XML/HTML content with simple regexps" in the quick & dirty code that is typical Perl (it works, let's use it...)

So you blame Perl for programmers making poor choices in how they parse their data?

> Evangelists will preach "modern Perl", good style and Moose to you, but these are half-baked, tacked-on solutions

How are they half-baked and tacked on?

> while not alleviating the massive disadvantages Perl has (performance, dynamic typing, lack of proper threading support...)

You mind supplying evidence for any of these? For some, dynamic typing is a feature. As for threads, I make heavy use of them every day, and while they have their quirks, they work quite well in some circumstances. Performance?

> So you blame Perl for programmers making poor choices in how they parse their data?

That wasn't a poor choice. I didn't propose "si.+?nk" as a general rule, and I would have used another method if there had been conflicting tags in the file.

I also take issue with the parent comment about perl not being usable for long scripts; that's nonsense. A comm framework I wrote in perl in '04 still sends payroll data for our 18k employees to the bank. It weighs in at around 400 lines, makes calls to gnupg, a database, has a scheduling engine that can parse cron entries, has support for EDI wrapping/unwrapping functions, logging, error alerting, other bells and whistles I'm forgetting right now.

There was nothing in the language that made this absurd or unsupportable.

> That wasn't a poor choice. I didn't propose "si.+?nk" as a general rule, and I would have used another method if there had been conflicting tags in the file.

I wasn't really speaking to any criticism of you in particular, but to the general statement about assumptions when using Perl.

I myself have used a regex to pull out well formed XML chunks and then re-parse them with a regex to build a hash out of the attributes of each chunk. It turns out it's 10x faster that any XML solution I could find (and there's quite a lot on CPAN!). The fact that it was a few hundred MB of XML and with a regex I could step my way through it probably had a lot to do with that...

I read through your perl posts and ended up at your summary article for perl features written in 2005. As a somewhat novice user I have run across a need and had to find most of this on my own. Thanks for such a great writeup and explanation.

http://curtisquarterly.blogspot.com/2005/05/perl-tutorial.ht...

You bet! As far as I know, you're the first person to read it.

>It's still difficult to beat perl in a production Unix environment to fix a hot issue, especially if you know your way around regular expressions.

That may have been true at one point, but what advantage does Perl now have to any number of other languages with great RegEx support?

First, it's not just just good regex support, it's easily accessible features from the command line so you can quickly iterate to a solution.

I'll often need to pull some very specific information out of a very large log file, and often Perl is the quickest way to achieve that. i.e.

    # pseudo-code
    head -n10000 LARGE_FILE | perl -ne 'next unless my ($foo,$bar) = /include/gsmi; ${foo}+=$foo, $h{$bar}.=$bar}; END { print %h }'

Once you're happy with results on smaller data sets with head, replace with cat. I used a similar technique to quickly identify, classify and determine the user account for a large set of hacked Wordpress accounts at an ISP I worked for.

Secondly, Perl is still the leader in regex development. They are still adding features that other languages are adopting (there have been a few good ides from outside they've taken as well, such as named captures, so credit where it's due).

In my production environment, it has the advantage of being installed as part of our default Unix build. Most of our devs use tools like Weblogic, webMethods, Informatica, etc., and a few of us old fogeys are still around supporting Korn shell and perl scripts we wrote a decade ago.

We don't have many bleeding-edge Linux hackers pushing Ruby, Python, Mongo, etc., which in my opinion is a shame.

> references to the P in LAMP being Python or PHP

LAMP originated with 'PHP' as the 'P'. It's also by far the most common, for better or worse; 1.4M hits for 'linux apache mysql php' versus 50k for 'linux apache mysql perl' on Google.

LAMP originated with 'PHP' as the 'P'

Source for that? I certainly recall it first being used as either "Perl" or "Perl | PHP".

http://web.archive.org/web/20010304112803/http://www.onlamp....

diff that against this one:

http://www.onlamp.com/pub/a/onlamp/2001/01/25/lamp.html

I love the obvious later edit:

"Of course, there are plenty of excellent open source variants for any of the pieces of LAMP. Let the L stand for Linux, FreeBSD, NetBSD, OpenBSD, and Darwin/Mac OS X, all of which are open source operating systems and all but the latter have open source GUI layers. Let the M stand for MySQL and PostGreSQL. Let the P stand for PHP, Perl, Python, and Ruby."

Ah yes. I've a vague recollection at the lack of Ruby at the time ;)

Reply on news.ycombinator.com