4 ms·

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 c

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 http://cautery.blogspot.com/2010/09/concise-perl.html

daeken 14y ago
> 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.
- adrianhoward 14y ago
  LAMP originated with 'PHP' as the 'P' Source for that? I certainly recall it first being used as either "Perl" or "Perl | PHP".
  - UNIXgod 14y ago
    http://web.archive.org/web/20010304112803/http://www.onlamp.com/pub/a/onlamp/2001/01/25/lamp.html 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 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."
    - adrianhoward 14y ago
      Ah yes. I've a vague recollection at the lack of Ruby at the time ;)
K2h 14y ago
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.html http://curtisquarterly.blogspot.com/2005/05/perl-tutorial.ht...
- ceautery 14y ago
  You bet! As far as I know, you're the first person to read it.
lazyjones 14y ago
> http://cautery.blogspot.com/2010/09/concise-perl.html 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.
- kbenson 14y ago
  > 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?
  - ceautery 14y ago
Falling3 14y ago
>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?
- kbenson 14y ago
  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).
- ceautery 14y ago
  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.

daeken 14y ago

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

adrianhoward 14y ago
LAMP originated with 'PHP' as the 'P' Source for that? I certainly recall it first being used as either "Perl" or "Perl | PHP".
- UNIXgod 14y ago
  http://web.archive.org/web/20010304112803/http://www.onlamp.com/pub/a/onlamp/2001/01/25/lamp.html 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 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."
  - adrianhoward 14y ago
    Ah yes. I've a vague recollection at the lack of Ruby at the time ;)

K2h 14y ago

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.html http://curtisquarterly.blogspot.com/2005/05/perl-tutorial.ht...

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

lazyjones 14y ago

> http://cautery.blogspot.com/2010/09/concise-perl.html 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.

kbenson 14y ago
> 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?
- ceautery 14y ago

Falling3 14y ago

>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?

kbenson 14y ago
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).
ceautery 14y ago
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.