
With the Rise of DevOps, Perl Shows Its Muscle - MilnerRoute
http://www.i-programmer.info/programming/perl/9649-with-the-rise-of-devops-perl-shows-its-muscle.html
======
ram_rar
When I was @ yahoo! in mid 2000s, I used to argue with my principal engineer
to great lengths on why he should consider Python for DevOps. Writing code in
perl felt like a pissing contest on who can obfuscate and make the code do
insane things with least amount of characters.

Now, I have barely seen anyone use anything but Python (Golang maybe...) for
this. Bottom line - readability matters! people have moved on and perl has
outlived its purpose.

~~~
SteveNuts
I feel the same way with Bash.

It's great for one liners, but it breaks down when doing simple things like
checking if a variable is a string or integer.

~~~
brobinson
Ugh. If I have to write Bash, I try to enforce some level of basic sanity
with:

    
    
        set -euo pipefail
    

I've seen way too many scripts catastrophically fail because of unbound
variables or one side of a pipe failing and the script continuing anyways,
etc.

~~~
DCoder
I use the verbose version for readability:

    
    
        set -o errexit
        set -o nounset
        set -o pipefail
    

Some commands need custom error handling, which means turning off -e:

    
    
        set +o errexit
    
        ansible-playbook ...
    
        if [[ "$?" != "0" ]]; then
            echo -e "\e[1;31m""Error when executing ansible!""\e[0m"
            exit 1
        fi
    
        set -o errexit
    

And if you use -e , you will probably need the default value helper to
validate input arguments:

    
    
        # the :- operator means "use the right side value if the left side ($1) is not set"
        env=${1:-}
        
        inventoryFile="${baseDir}/env/${env}/inventory"
    
        if [[ -f "${inventoryFile}" ]]; then
            echo -e "\e[1;31m""Invalid environment specified!""\e[0m"
            exit 1
        fi

~~~
Ded7xSEoPKYNsDd
I feel your first example is better written like this:

    
    
        if ! ansible-playbook ... ; then 
            echo -e "\e[1;31m""Error when executing ansible!""\e[0m"
            exit 1
        fi
    

But generally when I need to work around errexit, I tend to add something like
" || true" or " || xyz_failed=true" to the end of the command line instead of
turning it off and on again.

------
theonemind
Perl gets panned as unreadable. I find this mostly a function of the people
using it. Larry Wall aimed to take whatever worked from other languages and
throw it in. Perl expressly permits you to optimize for whatever you want to,
including readability. You can throw pod documentation right into your
modules. You can purely procedural code, or mostly OO code.

Personally, I find most of the criticism misguided. I can see why many people
collaborating might prefer the comparative straight-jacket of Python to coming
up with their rigorous style guidelines. Perl just doesn't dictate, and that
comes with a lot of advantages and disadvantages. I might go as far as to say
that on average, perl makes a bad trade-off for teams, as having a language
with a narrower philosophy (Ruby aiming for pure OO, Python aiming for
readability) relieves you of making and enforcing those decisions. However, I
do enjoy programming perl when working alone, as perl lets you do the right
thing, whatever _you_ think it is.

~~~
jcoffland
There is a simple test. Grab a random piece of Perl code and try to read it.

~~~
cutler
Grabbed, read and understood. Your point?

~~~
coldtea
That it might work for you, but for most people it doesn't.

Obviously what's "readable" is not constrained to what some people find
readable, but to what most people do.

~~~
chromatic
> Obviously what's "readable" is not constrained to what some people find
> readable, but to what most people do.

That's hardly obvious to me at all. Leaving outside language syntax debates,
the important readability concerns of code I deal with tend to include:

* the business domain

* the ecosystem of existing code in the organization

* the experience level of other developers

* coding standards and guidelines

* deployment and maintenance concerns

* the organizing concepts, architecture, and metaphors of the code in the small and large

* the context of where the code lives -- is it a one-off, is it structural code to get from one design to another, is it long-term code that has to meet certain criteria to be maintained for years

A random piece of code waved in front of a random person tells me nothing of
interest with regard to those criteria.

~~~
cocktailpeanuts
it's pretty obvious to me. It's not about "you". You don't matter in this
equation. What matters when talking about a language is the people who use it
as a whole.

So even if you have no trouble using Perl and writing "readable" code that you
can read yourself, that doesn't mean rest of the people can read what you
wrote.

~~~
chromatic
_What matters when talking about a language is the people who use it as a
whole._

Seems like that argument has moved the goalposts from "most people" to "most
people who use the language", and it's still not clear why that's an
interesting barometer.

Even acknowledging that this is a thought experiment, what does the ability of
J. Random Perl Hacker to grok a piece of random code from a domain and context
with which he or she may not be familiar indicate? Surely a one-bit "is this
readable" test has lost so much signal from the interesting criteria that it
means very little!

~~~
cocktailpeanuts
Ironically, this comment of yours is a great analogy to explaining this
situation.

I have no idea what your run-on sentence is trying to say, and don't want to
bother trying to figure out what you're trying to say either. And this is my
point. Being too "expressive" makes it hard to share ideas. That's why they
teach you to not use run-on sentences at school, but people still use them
sometimes because it's easy to get carried away.

In a normal human language like English this flexibility and expressiveness is
not always a bad thing since it allows all forms of art, but programing
languages are not meant for avant garde navel gazing. They are for getting
stuff done. And I don't want any run on sentences on my application.

~~~
cafard
I agree that chromatic is not the best test case; he has published a lot about
Perl, and his code examples are very readable.

However, it is possible to right miserably bad code in a variety of languages.
The Perl that one finds (for example) on CPAN is generally straightforward and
understandable. One can write lucid and powerful Perl.

And I have no trouble understanding any of the sentences of the parent
comment. Is your complaint that the verb "indicate" falls after the clause it
refers to?

------
uptime
i owe my career to Perl. I was a liberal arts major and in 94 there was a
language i could use because it was designed for folks who needed to use what
they could understand at any time without knowing it all, with the aim of
building cumulative mastery. Kind of like unix, learn useful things and piece
them together.

This was by design as Wall treated Perl to be acquired the same way we learn a
spoken language.

That is why we have really good and really bad perl5 code out there.

I remain a learn-by-debugging programmer instead of a play-with-a-lang-from-
squareone type. My pattern is, if there is a compelling app i'll learn the
language/framework. (bonus points for pg support.). Bricolage got me into
HTML::Mason and mod_perl. Discourse got me into ruby. Actionhero got me into
nodejs. Flask in python. PHP became unavoidable (sigh).

I find PHP to be my language of "wow i can't debug this at all" but good php
is really good - the same way perl detractors see perl.

Low barrier to entry (perl php browser js) is a gift and a curse, but a good
dev can make anything a joy to use.

With perl anything done after the faux-OO world blew up takes a lot of effort
to understand even though it should be the reverse.

I still use perl for scripting in linux but have avoided it for new apps.
After a lot of nodejs async, I am tempted to use Mojolicious and avoid the
Mooseshaving

------
eropple
The overwhelming majority of devops-related stuff I see is in Ruby, not Perl,
and Python is a (distant) second to Ruby in that. I keep up with all three on
the off hand that a client really has a burning desire to use Perl or Python,
but it's Ruby as far as the eye can see in these parts.

Even stuff not written in Ruby invariably ends up with a Ruby DSL around it so
mere humans can use it successfully.

~~~
crdoconnor
For me it used to be like that about 4 years ago - everything was built with
puppet (ruby). Now people seem to have moved on to ansible.

Perl is nowhere to be seen. Bash still crops up occasionally.

~~~
eropple
Yeah, that's definitely true, and it depends on the composition of the shop in
question. I see Ansible mostly in smaller shops with simpler needs. I see Chef
more often once those needs grow a little bit (granted, I also endorse Chef
when asked, because I'd rather have a real programming language to better
express my intention--Puppet has the same issue). But I see most of that Ruby
outside of the CM, dealing with the billion little glue problems involved in
cloud crap. Bash too, of course, for obvious reasons.

------
hoodoof
I simply don't believe that Perl is making a comeback. This is the ONLY time
I've ever heard such an assertion being made and I've never seen any sort of
indication that it is true.

~~~
wyclif
DuckDuckGo uses Perl a lot. So are many other startups. Isn't that evidence
that it's making a comeback of sorts, since there was kind of a dead zone in
new development between Perl's heyday and the newer, "Modern Perl" (i.e., Perl
5.2x) movement?
[http://onyxneon.com/books/modern_perl/](http://onyxneon.com/books/modern_perl/)

~~~
cutler
Who are these "many other startups"? Last year's London Perl Workshop was
largely populated by the usual suspects who've been there since the early
2000s. I didn't hear the word "startup" mentioned either in conversation or
the literature.

------
cocktailpeanuts
There are many good new languages that can do what perl's good at AND
readable.

Just because it was cool when it was invented, doesn't mean we need to keep
using something when there are other better tools.

------
yellowapple
Perl was my first real foray into programming (I'd dabbled in BASIC and C++
previously, but neither really appealed to me). It just "fit". Even nowadays,
Perl feels nice to work with, probably because of how expressive it is.
There's a lot to learn, though; every time I jump back into Perl for
something, I end up learning something wacky and new.

~~~
guitarbill
> I end up learning something wacky

You pretty much summed up the problem :)

~~~
yellowapple
Guilty as charged :)

I've been working on a lexer/parser/interpreter/compiler/whatever for a pet
programming language project, and in the process of trying to figure out how
to keep track of line numbers in the source files I'm parsing, I inadvertently
discovered that Perl already tracks that for me (in "$."). Who knew?

(I mean, Larry Wall obviously knew, of course, but whatever.)

------
gtirloni
It doesn't look like that: [http://www.tiobe.com/tiobe-
index/perl/](http://www.tiobe.com/tiobe-index/perl/)

------
alrs
I have some pet not-hip technologies that I'm occasionally defending. I always
try to not sound like one of the OS/2 dead-enders circa 1998. If you swap the
names of the technologies, this reads like a straight-outta-the-90s USENET
post with "Team OS/2!" somewhere in the .sig.

------
mattbillenstein
If you build any sort of deployment tools in perl today, the next guy who has
to maintain them is going to curse your name forever.

------
brobinson
What is the Perl equivalent of Chef/Puppet/Ansible?

~~~
Moto7451
Rex. [http://rexify.org](http://rexify.org)

~~~
arc_of_descent
Wow, thanks for the link.

------
kodfodrasz
When someone cites TIOBE as evidence for anything God kills a kitten.

~~~
rwallace
What ranking of language popularity do you think is more accurate than Tiobe?

~~~
kodfodrasz
I think all are irrelevant. They can help to give an overview on popularity,
maybe, but are not in any ways sources to consier for a decision, like (all
numbers are made up) the following example:

Oh, Java is 10% more popular than Python, but both are going down, while
JavaScript is more popular, and going up, so I need to write my System in
JavaScript to have cheap and good labour to help on the job!

I beleive these rankings, if used for anything more serious than having some
perspective on long-time trends for someone not following the industry closely
are useless, and usually are used in arguments like kids in the kindergarten
usually have:

\- My dad is stronger than yours!

\- Yes, but my dad has a red car!

What do you want to use such metrics for? Are you a decision maker? Then you
should not rely on this, but on the facts that cheap labour is usually
freshmen from the uni, where java, c, c++, c# and Python are usually thought
(and lisp at some palces), so you should stick to these.

For other perspectives, this is irrelevant:

If you want to know what language you need to know to get a job simply write a
web scraper in your favourite language, and analyze a job marketplace portal.
You will have fun, learn something, and get some insight on demand. Ultimately
it is not the languages that matter in my experience.

If you need to get sh1t done Quick, just stick to what you already know well.

If you want to know what language is the best fit for a task, then you need to
do other Research, a magic google trends, or a github filetype histogram will
not tell you the truth.

------
russellbeattie
Amazon's codebase is (famously) an amalgamation of 20+ years of internet
development, including a hefty chunk of Perl. Every time I stumble into that
stuff I shake my head as it's sort of comprehensible, but not really... I wish
I had just sat down and learned Perl in the 90s, because I'm sure as hell not
going to try now.

------
m23khan
Perl definitely had its place in the world of scripting particularly sysadmin
automation tasks as well as early days of CGI scripting. Since then do, other
languages (with easier syntax - IMHO) have taken the lead.

I guess like everything in life, nothing is permanent and what is hot tech.
today will be a legacy product Tomorrow.

Perl's story reminds of yet another language -- REXX. It's powerful as a
scripting/text parsing language but due to it's Mainframe label, 99% of
programmers Today haven't worked with it.

------
cutler
I wish it was true as I reluctantly switched from Perl to Ruby and Python
years ago when the job market demanded it. This article is flawed on 2 counts:
the author is "director of engineering at ActiveState" and he bases his
conclusion on the ridiculous TIOBE index. If you search Indeed.com for
title:ruby, title:python, title:perl in the U.S the results are 1506, 847 &
137 respectively.

------
digitalpacman
I do devops. This is yuck.

~~~
intellectronica
This article is so poorly researched and written, that it's not really worth
taking seriously. I hope no-one does. The writer clearly doesn't understand
DevOps or PERL, and just grabbed some superficial ideas from here and there to
fill a low quality journalistic word count.

~~~
asdfasdfa11112
People who are familiar with, and use Perl on a regular basis, are already
aware. (TLDR: never capitalize the full PERL; the language is Perl, the
executable is perl, and anyone with much experience understands and
communicates this difference.)

It is worth noting this SO answer[0], which is a reasonable heuristic when
people are talking about Perl. (And, IMO, one of the few times to ignore
pedantry is when it's being used as a Shibboleth[1]).

[0] [http://stackoverflow.com/questions/72312/how-should-i-
capita...](http://stackoverflow.com/questions/72312/how-should-i-capitalize-
perl)

[1]
[https://en.wikipedia.org/wiki/Shibboleth](https://en.wikipedia.org/wiki/Shibboleth)

------
judezhu87
glad to see that many people disagree with it.

~~~
yellowapple
I'd chalk that up to there being relatively little cross-section between "Perl
users" and "HN visitors". Sure, some of us do exist, but for a lot of the
current-gen programmers, suggesting the use of Perl might as well be
equivalent to suggesting the use of Fortran or COBOL, and for good reason:
there are plenty of perfectly good programming languages out there from which
to choose, many of which include PCRE (Perl's regexes being a huge selling
point for using Perl).

I'm willing to bet that quite a few of the naysayers even on this thread
haven't seen much Perl beyond perhaps some deliberately-unreadable code-golf-
style Perl one-liners. Yeah, those are fun to write (and only slightly less
fun to decipher), but real in-the-wild Perl is usually surprisingly readable.

~~~
BuuQu9hu
Perl gives you plenty of rope to hang yourself with. That isn't a good thing
in any language.

~~~
yellowapple
Sure, but it ain't a "bad thing", either. It's just a thing about Perl,
neither good nor bad. It's pretty easy to avoid self-asphyxiation in Perl, and
that rope can be used to tie all sorts of knots other than just nooses.

~~~
PeterisP
It _is_ a bad thing, since while it usually is easy to avoid self-
asphyxiation, when given enough rope to hang themselves people invariably use
it.

When I've had to read/bugfix/adapt Perl code, most of the time all the bad
things people say about Perl were there, that's just the way how the world
works, that's how people are.

The same applies for other languages. Get a task for maintaining random C
code, you will have to fix memory handling problems; get a task for
maintaining random JavaEJB code and you will invariably see unreasonable extra
layers of indirection added; get a task for maintaining random Perl code, and
you will have readability problems.

For maintainability, you want something that prevents people from tying all
sorts of interesting knots whenever standard, idiomatic solutions can be used.

~~~
yellowapple
I'd rather have enough rope to hang myself than not enough rope to climb a
mountain.

"When I've had to read/bugfix/adapt Perl code, most of the time all the bad
things people say about Perl were there, that's just the way how the world
works, that's how people are."

This might very well be confirmation bias. If code needs fixed, it's unlikely
to be high quality to begin with. The similar examples for other languages
demonstrate this effect.

Really, all languages have their strengths and weaknesses. In Perl's case, its
strengths also happen to be its weaknesses. :)

"For maintainability, you want something that prevents people from tying all
sorts of interesting knots whenever standard, idiomatic solutions can be
used."

True, but when standard, idiomatic solutions don't exist for the problem
you're trying to solve, being able to tie interesting knots is a lot better
than being totally out of luck.

One of Perl's underlying philosophies is "Easy things should be easy; hard
things should be possible". There are some things that really could and should
be easier (FFI being among them: without installing third-party packages, the
"recommended" way is to splay open Perl and start fiddling with its C
internals, which is absolutely absurd; something like FFI::Platypus really
ought to be included by default), but Perl has an "anything is possible"
mentality that is invaluable for solving hard problems.

------
viraptor
Is anyone actually using the inline::otherLanguage modules for anything
serious? I find that idea awful for production for many reasons, but maybe
there's some real use case?

------
jcoffland
Rise of DevOps? Perl the hero? DevOps was a big deal some years ago but it has
since been heavily criticized. You could have said DevOps was on the rise in
2009 but that's hardly so today.

[https://techcrunch.com/2016/04/07/devops-is-dead-long-
live-d...](https://techcrunch.com/2016/04/07/devops-is-dead-long-live-devops/)

[https://lionfacelemonface.wordpress.com/2015/03/08/devops-
is...](https://lionfacelemonface.wordpress.com/2015/03/08/devops-is-bullshit-
why-one-programmer-doesnt-do-it-anymore/)

------
tudorconstantin
All of the Perl bashers seem to be people who think that in programming the
syntax of a language is the hard thing to learn.

~~~
cocktailpeanuts
Nope. just read this entire thread and you'll learn why.

~~~
topspin
I've read the entire thread and haven't discovered your _why_. I think the
most insightful thing that appeared is the assertion that there isn't much
overlap between HN folks and Perl types.

I keep turning to Perl. For the man pages. For the stuff in C-PAN. For the
one-liner concision that obviates awk, sed, bash and the rest. I've learned
much and gone far with many other things, but Perl keeps getting play with me.
It continues to be the shortest distance between two things that no one else
has ever had to connect. All the classic protocols have serviceable Perl
implementations that have been mature since the late 90's. It's a special
little programming language and I believe I'm going to continue pulling off
little miracles with it when necessary. That's what it was designed to do and
it's still fit for purpose as far as I'm concerned.

~~~
cocktailpeanuts
Ok i'll play. The reason is because it's unreadable. Yeah i'm sure you can
write your perl program with ease and it can do all kinds of magical things. I
believe you.

But the problem is it's one of the worst languages when it comes to
readability.

I also used to write perl, especially doing natural language processing, etc.
so I know pretty much what you are talking about in this department. But I
would always find myself wondering what the hell i wrote 6 months ago when I
used perl. That doesn't happen with other new languages I picked up along the
way.

So if you're just a lone coder working on your own thing that no one else will
use, then no one's stopping you. Go ahead. But if you're trying to maintain a
large project with many developers, perl is very inefficient.

~~~
khedoros1
It's unreadable if you write it that way. It's a flexible language with a
dozen ways to do most things, and some of those are more legible than others.

I use Python for a lot of the things I used to use Perl for, and one of the
biggest benefits is that it constrains your style a lot more, and things look
more consistently readable.

~~~
sagichmal
> It's unreadable if you write it that way. It's a flexible language with a
> dozen ways to do most things...

Yes, these are precisely the properties that makes Perl unreadable. This
permissiveness is a weakness!

