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.
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.
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
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.
There are limits for sure, but actually it's quite possible to write bash code at scale, but it requires some discipline and practice. It's hard to avoid it.
One reason I still use perl for is its better regexes. In particular, I tend to use `perl -pe 's/regex/replacement/g'` instead of `sed 's/regex/replacement/g'` when I need to replace something. sed's regexes are just not good enough for some tasks.
The regular expression syntax; sigils on (some) variables; shortcuts like `bar if foo`; optional parenthesis on function calls; `chomp()` and `chop()`; those are just a few things that come to mind.
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.
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.
Now that RedHat bought Ansible and is integrating it with Satellite it's going to be a tough sell in our office if someone wants to use something other than Python for DevOps projects.
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.
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.
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]).
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.
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.
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.
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.
I've done a lot of work on older systems that don't include Python or anything trendy, so Perl was my go-to language for a long time, so that I could avoid a mess of different shell languages and such. I always took pride in writing readable Perl that someone didn't have to be an expert in order to follow.
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.
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.
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 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.
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.
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.
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.
I personally don't use Perl much, but I've seen quite a few scripts written by members of my IT department that I could read top->bottom without any issue whatsoever.
I like Perl, but I can see the argument for why it's not readable. People often mistakenly use sections of code with crazy looking regexes as an example...that's not really the issue though.
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.
Yeah that's because it's written by people from IT department. They are supposed to write it in the most readable manner since it's their job.
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.
People think Perl code is unreadable and mysterious because the language design philosophy is different than other programming languages. Most languages strive for a limited, orthogonal set of built-ins and features without any repetition. Most languages enforce opinions about how things like OO and function calls are going to work.
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.
I don't know why my parent comment gets so furiously downvoted.
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.
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.
> 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.
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.
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!
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.
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?
>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.
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").
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.
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?
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.
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/
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.
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.
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.
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
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.
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.
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.
83 comments
[ 0.21 ms ] story [ 143 ms ] threadNow, 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.
-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
Does all the same with more commands and better error handling.
Odd. I see almost entirely Ruby. Especially with tools like Chef.
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.
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.
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...
[1] https://en.wikipedia.org/wiki/Shibboleth
Just because it was cool when it was invented, doesn't mean we need to keep using something when there are other better tools.
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.
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 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.
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.
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.
https://techcrunch.com/2016/04/07/devops-is-dead-long-live-d...
https://lionfacelemonface.wordpress.com/2015/03/08/devops-is...
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.
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
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.