That's the number one reason I don't code in Perl, I can't even read my own code 6 months later... Perl is not a programming language, it's closer to real languages and you can sort of invent stuff and it works...
Is it the for loops? The if statements? The function calls? I've written lots of Perl. It doesn't have to look that much different than any other language. If you find a terse 1 liner on the Internet and use that as a solution, you might not be able to read it a week later.
I suspect it's the wide range of special operators, variables and default arguments. Knowing, for example, that shift() shifts @_ by default. That <> iterates over @ARGV. That chomp chomps $_. Messing with @INC changes library search paths, etc.
Or, perhaps the syntax for dealing with elements in a somewhat deep data structure, like: push(@{$TV{$family}{kids}},"anotherkid");
Sometimes, people are just griping about regex syntax though, which seems disingenuous, since many languages use the exact same pcre expressions.
I like perl, but if it's been a while, there's definitely some back and forth with books to decipher something I wrote some time ago.
It largely depends from whom you learn. Most people google and run with the first thing google throws up and perl has many, MANY (due to its age) really shitty learning resources. Even the most popular one, the book Learning Perl, has as of its 6th edition (2013), grave flaws and miseducates newbies severely.
Some comment from the position of someone familiar with Modern Perl, which is largely what's practiced on CPAN:
> shift() shifts @_ by default
This is discouraged, precisely because it messes with @_. It has valid uses, but people tend to make sure it's clear from the code why it's used. (Mainly in OO helper stuff.)
> <> iterates over @ARGV
Almost nobody uses that, precisely because it's very unreadable. It only exists for compatibility reasons and was made to serve people used to sed/awk.
> chomp chomps $_
I haven't seen code use chomp in ages. I've never used it myself.
> Messing with @INC changes library search paths, etc.
This is rarely used as well. Mainly only when doing release engineering. It's also most often done via `use lib 'whatever';`.
push(@{$TV{$family}{kids}},"anotherkid");
That is an outdated way to write that. In a decent modern style it would be written like this:
Yes, I think the biggest issue with perl was the devil-may-care culture around it. That was far from the only issue, though. It had (has?) some gratuitous features which are bound to cause hard to find bugs, like implicit conversion of numeric strings to numbers in certain contexts. That particular feature was the reason I chose to learn python in the mid 90s, rather than perl.
> implicit conversion of numeric strings to numbers in certain contexts.
In Perl 6 at least, and to a large degree Perl 5 too, context only "causes" bugs if coders make assumptions that are invalid in Perl.
For example:
say $foo + $bar
adds two numbers. So the context for $foo and $bar is numeric. So Perl coerces them to be numbers. If you didn't mean to add two numbers, don't use a numeric operation such as `+`.
If you want Perl 6 to make sure $foo and $bar are numbers already, then add a type to their declaration:
Your comment actually made me scroll back to the top to double check this thread was actually about Perl 6, not Perl 5!
Part of the point of Perl 6 was to address problems in the language and Larry (and/or those who wrote the original Perl 6 RFCs) considered several of the things you named to be problems.
> wide range of special operators, variables and default arguments
In Perl 6:
* The only special op I'm aware of is assignment.
* The only variables considered special are the "it" and "them" variables ($_, @_ and %_), the current match object ($/), and the current exception list ($!).
* There are still predefined variables, such as a DISTRO variable which contains an object representing the OS etc. on which Perl 6 is running, but I haven't found those problematic.
* Almost all use of default arguments in built-ins has been eliminated. The main exception I'm aware of is that subs and ops related to matching still default to operating on "it".
The Perl 5 <> op is gone.
> Or, perhaps the syntax for dealing with elements in a somewhat deep data structure, like: push(@{$TV{$family}{kids}},"anotherkid");
This would be something like this in Perl 6:
my %TV;
my $family = 'foo';
push %TV{$family}<kids>, 'another';
> Sometimes, people are just griping about regex syntax though, which seems disingenuous, since many languages use the exact same pcre expressions.
This is talked of in Perl 6 circles as being ironic because regex syntax has been thoroughly cleaned up (and massively powered up too) in Perl 6.[1]
> I like perl, but if it's been a while, there's definitely some back and forth with books to decipher something I wrote some time ago.
One of the many downsides to Perl 6, imo, is that this back-to-the-book-oh-yeah aspect is still there -- but there's only incomplete doc and no books yet written by the likes of Larry.
I can write readable Perl by writing it as if it were Python, adding extra braces where required, a couple of use declarations at the top, and wrapping some system functions with clearer names. But if that's what you want then it's easier to just write Python. Perl's USPs like regex literals and $_ rely on you writing in an unreadable style.
So, Python regexps are suddenly more readable, even though they need
additional layer of backslashes?
$_ does not rely on unreadable style. First, it's a common idiom, so it's in
no way less comprehensible than list comprehension in Python. You just need to
understand what it means. Second, it's not an obligation to use $_. I often
avoid it if it doesn't make my code reflecting my intentions better. Funny
thing, I do the same in Python, C, and Erlang.
And I hear about $_ and regexp literals as unique selling points (if I read
your acronym correctly) only from people that don't really write in Perl.
> So, Python regexps are suddenly more readable, even though they need additional layer of backslashes?
Python encourages a style that makes less use of regexps. (And you don't need extra backslashes, you can use r'...').
> And I hear about $_ and regexp literals as unique selling points (if I read your acronym correctly) only from people that don't really write in Perl.
Nice ad hominem. Go on then - what's your USP for Perl? Why should one use it over Python/Ruby/...?
> Python encourages a style that makes less use of regexps.
Yes, even in the places where regexp would help very much. And even if you'll
insist on using regexps, Python makes them highly inefficient or cumbersome
(or both), because if you're careful, you'll either get code that needs to
store compiled pattern somewhere vaguely related to the code at hand, or code
that compiles the pattern on every use. If you are not careful enough, you'll
get the two at the same time.
> Nice ad hominem. Go on then - what's your USP for Perl? Why should one use it over Python/Ruby/...?
Thank you, though I wasn't refering to yourself. It was pretty clear you don't
write Perl much.
My reason to use it is because it was my primary language for over a decade.
For other people? I don't know. All three are similar in what they can do and
how does it look afterwards, as all of them are scripting languages in OOP
land.
Combine that one and Perl's learning curve, and you'll get why Perl usage was
declining over the last decade.
"_" in Scala is not a magic variable like in Perl. It's a very mechanical syntax transformation, it just expands to "x => x" (or equivalent, and without colliding with any "x" that's already defined).
In practice maybe the use is similar. But having a comprehensible theoretical model makes all the difference in terms of making sure you can actually read the code and understand what will happen.
There is nothing particularly magical about $_. It is merely a global variable that is optionally used implicitly in various builtins, as well as scope-localized by loop control constructs.