Which still has many of the terrible problems of the shell, because its original design was an imitation of several different shell scripting languages.
If all you know is Perl and you're incapable of learning any other languages, or for some perverse reason you like the way Perl scripts look just as incomprehensible as shell scripts, and you're absolutely sure nobody else will ever need to look at or maintain your code, then by all means use Perl. But if you don't hate the people who will have to clean up after you or decipher and maintain what you're done, then please use Python or JavaScript instead of Perl or shell scripts.
> and you're absolutely sure nobody else will ever need to look at or maintain your code
By "nobody else" you really mean "other people with the same mindset who aren't willing to invest some time in getting used to perl syntax". Thing is that modern javascript is just as incomprehensible to sysops/devops people who're not familiar with the new JS syntax. You come from one world and think that's the "normal", they come from the other and expect that everyone already knows perl as it is half bash, half C. And in the end it's really much more about how much time did you spend working in it, than in one language being so much clearer than the other.
Too many people have for too long treated Perl as way to blackmail their employers into not firing them, by developing an unmaintainable code base that nobody else can understand. Do you really want to be "that guy", or clean up after them yourself? (I say "that guy" because the Perl community is historically hostile to women, with the "hooters girls" at trade show booths, etc.)
And have you ever tried to hire a competent experienced Perl programmer? They're extremely hard to find, and very expensive, and usually would rather be working with some other language. Sure, incompetent ones are a dime a dozen, but hiring those and setting them loose just starts the vicious cycle again.
All of the competent Perl programmers have long since been hired up by companies desperately trying to find people qualified to work on their old toxic legacy code bases that they're stuck with. Like Booking.com for example.
And writing new code in Perl is insane. There's absolutely nothing special about Perl 5 or Perl 6 that solves any problems you can't easily solve in most other languages.
Perl's much larger problems totally overwhelm the minor conveniences from its "syntactic syrup of ipecac" that perversely appeals those few people who think saving a few keystrokes at the expense of readability, instead of spelling words out with letters instead of line-noise punctuation and acronyms, is the sole goal of software development.
Perl 6 is a joke, a slow moving parody of itself that missed the boat decades ago, and it's absolutely never going to catch up with JavaScript or Python.
If you really want to optimize your career for programming toxic legacy code that's too ugly for anyone else to touch, you should have learned COBOL before the Y2K "crisis". But in the long term, you might have regretted it:
Perl is doing well, thank you. Perl6 is interesting, but I don't have a project for it yet. There are jobs in perl, there are needs, and we (perl devs) aren't appreciably more expensive than non-perl devs, though some of us may be better at negotiation than the dime-a-dozen developers in more "common" languages.
There is just so much that is wrong with the post above. Its actually sad.
I can understand Python (it has a library in stdlib for running subprocess, and it is specially good after Python 3.4). However AFAIK JavaScript is bad for shell scripting. You need a external library to have sane subprocess call, unless you give up and allow command injection inside your scripts. Last time I looked even the alternatives in npm were not as good as what Python offered in stdlib.
Actually, I don't know many languages that have a good way to call subprocess in stdlib. Ruby's Open3 comes in mind, however the API is kind horrible.
You didn't think I meant running JavaScript in the browser, did you??!
Of course JavaScript has an external library for sane subprocess calls, and is perfectly fine and commonly used for writing process management and system administration scripts. Please google "node.js" and "npm".
Yeah, I was referring to Node.js. And no, what Node.js offers by default seems horrible[1]. It pass its entries to system shell, that is completely insane.
Python's subprocess actually run the process inside a Python process, so there is no possibility to hang youself up in case of a vulnerability in shell code. You can explicitly run the subprocess in shell script if you need shell capabilities (glob expansion comes in mind), however you shouldn't.
Perl is still one of the best glue/high level systems languages around, partisan missives not withstanding. Debian's apt system is based upon it, as is git (though it uses C for parts that are intensive), and many other tools.
Python is fine as a systems language if you don't mind the insane indentation issues, and the extra boilerplate you need to do for "simple" things.
Honestly, I see Julia as the up and comer here. Julia has IMO the best syntax, is JIT compiled, is a real programming language, and is IMO python done right.
If you are stuck believing python is a good language to develop new projects in, great. Knock yourself out. I personally find myself most productive in Julia, Perl, C, Octave/Matlab, and yes, even Fortran.
> Honestly, I see Julia as the up and comer here. Julia has IMO the best syntax, is JIT compiled, is a real programming language, and is IMO python done right.
I think Julia is very exciting, and yes, the core language is very good. But so far I see very little uptake outside numerics. Hopefully it will get there.
It's got the support in the core language. That's what is so exciting to me ... its not just numerics, its an excellent programming language in and of itself, before you even get to the interesting type system.
It is JIT compiled, though some of us who like to deploy apps would love to have an AoT compilation. Likely we could work around that with a singularity container on linux.
Unlike many other languages, parallelism is a first class citizen, be it SIMD, GPU, distributed machine, and combinations.
It also works very nicely on FBSD 11.x. I've tried compiling it on recent 12.x nightlies, but not had great luck.
I am actively looking to find projects to work on in it.
I haven't really seen enough Python code in my life to have an opinion about readability of Python code in the wild. But I have seen quite a lot of unreadable (unminimized) Javascript code.
In the end it really depends on how much the developer is suffering from some form of impostor syndrome: if they're not, you have a good chance they will create code that will be unmaintanable even for them in a few months time. Regardless of language.
Of course there are incompetent programmers in every language. But in absolute numbers, there are vastly more competent JavaScript programmers available to hire than competent Perl programmers. There really is no comparison.
Can you name any schools that teach Perl to undergrads on a non-trivial scale? Maybe there's a reason you can't. But I can name a lot of them that teach Python and JavaScript.
And of course Python code is more readable and maintainable than Perl code, by its very design and nature, and also by its widespread culture and philosophy, which is 180 degrees opposite of Perl's philosophy and culture.
It's not just a matter of "There's more than one way to do it" -vs- "There should be one -- and preferably only one -- obvious way to do it." The Zen of Python goes much deeper than that.
There's also the idea that instead of using arbitrary idiomatic and personalized punctuation and line noise in "more than one way" to accomplish the same task, you should simply use letters, by combining them to form words, connected by underscores or CamelCaseCaps to form coherent phrases, which have meanings, that communicate with the person reading the code, explaining the ideas and intentions behind the programmer who wrote the code. Subtle little things like that, you know.
Line noise and random punctuation do not make self documenting code. That's why it's traditionally used as a stand-in for censored obscenities, because it's meant to obscure its true meaning.
Again, pure FUD. Once you bring the "line noise" mischaracterization up, you've blown your credibility.
I encountered this last in the mid oughts with insufferable Pythonistas. Seems not all of them have had time to think deeply as they gaze at go/rust/julia coming along to eat their lunch.
Perl continues to advance, people continue to start projects within it. Code continues to be contributed. CPAN (and CPAN6) continue to grow.
Which still has many of the terrible problems of the shell, because its original design was an imitation of several different shell scripting languages.
If all you know is Perl and you're incapable of learning any other languages, or for some perverse reason you like the way Perl scripts look just as incomprehensible as shell scripts, and you're absolutely sure nobody else will ever need to look at or maintain your code, then by all means use Perl. But if you don't hate the people who will have to clean up after you or decipher and maintain what you're done, then please use Python or JavaScript instead of Perl or shell scripts.