With the Rise of DevOps, Perl Shows Its Muscle
i-programmer.info
i-programmer.info
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.
It's great for one liners, but it breaks down when doing simple things like checking if a variable is a string or integer.
set -euo pipefail
-e Abort at the first failed line
-u Abort when undefined variable is used
-o pipefail Piped commands return the status of the last failed command, rather than the status of the last command
set -o errexit
set -o nounset
set -o pipefail
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
# 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 if ! ansible-playbook ... ; then
echo -e "\e[1;31m""Error when executing ansible!""\e[0m"
exit 1
fi
Does all the same with more commands and better error handling.
Odd. I see almost entirely Ruby. Especially with tools like Chef.
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.
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.
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.
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!
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.
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?
This may subvert your point about the effort "most programmers" put into reading code. I think it's a superficial criticism.
Obviously because one's code has to be maintained by other people.
Plus, if anything, going from "most people" to "most people who use the language" has moved the goalposts closer, not moved them apart (which is what people complain what one "moves the goalposts").
Certainly, but that makes the criteria in my post much more interesting. The people in the new set are more likely to understand the features of Perl and how to look them up in the documentation or use formatting/linting tools to de-obfuscate code.
Unless the argument is that Perl as a language has some features which make it impossible for anyone to decipher, the context around any piece of code seems important to understanding it.
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
Even stuff not written in Ruby invariably ends up with a Ruby DSL around it so mere humans can use it successfully.
Perl is nowhere to be seen. Bash still crops up occasionally.
That's hardly the proof of Perl making a comeback. If it was Google or Facebook or some major company or unicorn that might had a leg, but DuckDuckGo?
And while "many other startups" might use it, many other startups also use all kinds of languages that won't go anywhere.
Just because it was cool when it was invented, doesn't mean we need to keep using something when there are other better tools.
You pretty much summed up the problem :)
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.)
I put together a client-side configuration system, using Perl, which pulls recipes to apply from a remote rsync/git/http server:
https://steve.fi/Software/slaughter/
Sadly it never really caught on, but I've used it on and off for a few years. Even if nowadays I've secretly switched to using a combination of puppet & fabric for my own personal servers.
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.
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.
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...
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.
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.
"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.
It's a very obedient language, in the shoot-yourself-in-the-foot kind of way. I still use it as a convenient way to access PCRE in short scripts, but the longer it is, the more likely I am to switch to Python.
https://techcrunch.com/2016/04/07/devops-is-dead-long-live-d...
https://lionfacelemonface.wordpress.com/2015/03/08/devops-is...
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.
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.
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.
Yes, these are precisely the properties that makes Perl unreadable. This permissiveness is a weakness!
To me, it's a combination of two things:
- The culture that it's good to have many ways to do the same thing.
- The abundance of sigils on variables ($, %, @, etc), and how that gets unmanageable once you have complex data structures. Especially once you mix in references.
But like others on the thread said, the inherently extreme flexibility makes it hard to write a consistently readable code. You literally need some sort of discipline to consistently write a readable code.
Perl is designed to be maximally expressive. It is designed to be instantly familiar to someone who writes shell script, uses sed and/or awk and writes C for Unix environments. If you don't have this background, it can be a lot to absorb.
Here are some big things that Perl outsiders find troublesome at first glance:
1. Sigils are mysterious and scary--other languages don't have them. In practice, they're rather nice--they distinguish between functions and variables. They act sort of like a minimalist form of hungarian notation.
2. Built in regexes. Regex syntax is dense and messy. Putting it right in the language makes them easy to use. It also can make things hard to read. Perl didn't invent regexes and tt hasn't stopped most languages from implementing regex libraries. That's why Perl offers the expanded syntax that makes it easy to document complex regexes.
3. Special variables - $_, @_ are odd enough, but when add in the whole panoply from perlvar, it's pretty gross. In reality you really only need to know a few ($_, $@, @_, and $! are the only ones I use regularly), but they are terse and must simply be memorized.
4. Function calls in Perl are weird. Most people use one of the two common forms of argument unpacking that give you pass by copy semantics, but you can also pass by reference. Once you get the hang of it, it's not that complicated, but it is different and can be more than a little confusing for newbies.
5. List flattening. When you call a function like so: foo( @bar, %baz, $qux ), it gets one big list of arguments, the members of @bar and %baz get expanded. It's sort of the opposite of destructuring on assignment.
As a Perl dev earning a living by doing web development in Perl, I am quite interested in the show stopping downsides of the language. I really have my skin in this game.
Not only have I read this thread, I've read the countless Perl bashing articles that keep appearing on the internet and the main complain is the syntax.
Indeed, one can write unreadable Perl but that is also possible with Python, Ruby and even brainfuck (if you can believe that).
I have to tell you this: in my over 10 years of being a paid programmer and over 7 years of being a 100% Perl dev, the syntax is the easiest thing to grasp.