Perl is a general purpose programming language. The Perl interpreter and language are stable, it's not going anywhere soon. Perl and its syntax have been around a lot longer than most other languages and is very similar to C, C++, JavaScript and PHP. What do you consider normal syntax?
The most obnoxious parameter passing in existence? The magic variables everywhere? Perl code is an unreadable heap of spaghetti, I’d much rather be figuring out unallocated memory bugs in C then read Perl.
But why obnoxious? Do you know how old Perl is? Have you written shell scripts before? My point is, some of choices Larry and others made wouldn't necessarily be made today, but there's a history, a lineage, a reason for all of this. I actually like the magic variables, but as I said in my other comment, you need to learn it first. X language is an unreadable heap of spaghetti if the programmer writes X language in an unreadable way.
Not to someone who doesn't know Perl. But this is the same for every language. No one should be picking up a new language and working with it if they don't know it.
EDIT: To clarify, I mean there should never be the expectation that you can start working in a language in earnest without properly learning it.
What makes that less obvious is when you work with references to arrays; the reference itself is a scalar, so it gets the scalar sigil. You can dereference it, though, by sticking an array sigil in front of it, thus telling the interpreter "hey, this is a scalar reference to an array".
1 out of 100 might be understating it, though. Or it might be overstating it. Who knows?
As another data point, I've had very few good experiences with Python. The primary exception has been with PyQt5, and chiefly by going with Qt's conventions instead of Python's (i.e. being as Qt-like and un-Pythonic as possible).
> I want to run this on a production Server with ubuntu 16.04. My Sysadmin tells me that I shall not use pip or github repository, because of ... something wrong with using anything but apt ... he says.
Sysadmin is right.
First response?
> sudo apt-get install python-pip
Now there are ways to convert modules to debs (or rpms on redhat style machines) so they can be managed cleanly across an estate, but that's not the python way.
Which one? Python 3.5.x or 3.7.x or something else? Version 3 should be version 3. Anything written in 3 ought to work on every Python 3. Not so in the Python world. And that makes it a mess to use (unless you Dockerize every script).
Perl 5.001 is really old (25 years or so), and lots has changed since then. v5.10 introduced a barrel-full of new features; other important features like the "use v5.10" syntax for supporting older scripts didn't land until much later (v5.16).
Where I work, a few of our legacy systems are still dependent on ~v5.10, which can be a real pain when trying to port code back to legacy. I agree that the Python versioning problem is perhaps more prominent, but Perl 5 doesn't really get a free pass here.
The "use VERSION" syntax is fundamentally much older. It used to strictly just assert a minimum version. It also, pre 5.6, required floating point versions ("use 5.005"). In newer versions of perl, this syntax will also invoke "use feature <stuff new in your version and all versions before>" which allows the use of incompatible new features in its lexical scope. One example is that "use 5.12;" and above will turn on "use strict" in the lexical scope. I fought long and hard for that one. Makes the language strictly better (pun intended).
It strictly does! :) I knew that "use 5.12" implied "use strict" but I didn't know the mechanism, or that it could enable other features as well. That's pretty cool!
Perl documentation online applys to versions of perl that are installed. Python stuff is all bleeding edge - you'll research why something isn't working and after 30 minutes find it's expecting python 3.7.
The whole concept of "virtualenv" gives me an impression of fragility I don't get with perl.
Wanted to use Python 3 for some processing but the Sysadmin said that only Python 2 was available for that distributions version and "didn't want to frankenstein the box"
FreeBSD ships perl5 in base, but python is an addon. I suspect other BSDs may be similar. The only thing more ubiquitous is POSIX compatible /bin/sh but that's much less featureful.
Because of the stability of perl5, I barely care what version of perl5 that ends up being. (Perl 5.10 and up is pretty much what I want, 5.8 and 5.6 are a drag if i might need unicode)
Look across a bunch of common languages - Java, Perl, Python, Javascript, PHP, and of course C/C++/C#/ObjC, braces + semicolons. Even Bash and Go have braces.
>>> from __future__ import braces
File "<stdin>", line 1
SyntaxError: not a chance
Back to the topic, while I don't think its ranking doesn't generally reflect the actual popularity, the TIOBE index [1] is a good definition of "common enough" languages. So let's see... oh! There are 5--7 programming languages out of top 20 that do not generally use both braces and semicolons! (Python [not-so-strictly-necessary semicolon only], Visual Basic .NET, SQL [semicolon only], Assembly language, MATLAB, Visual Basic and Delphi/Object Pascal [semicolon only]). I also happen to know less popular but well-known programming languages that do not use both braces and semicolons at all (ML, FORTRAN, Lua, Forth and of course all lisps). So please allow me to reword your claim: why should braces and semicolons be normal?
Almost anything can "work"
> 2) Is ubiquitous
So is awk, don't write software in it.
> 3) Is stable
This will become questionable as Perl slips into non-maintained mode.
> 4) Is normal (semicolons, braces etc)
Perl syntax is very far from "normal"