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...
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.
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");
push @{ $TV{ $family }{kids} }, "anotherkid";
push $TV{ $family }{kids}, "anotherkid";In my case, when you learn :)
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
If you want Perl 6 to make sure $foo and $bar are numbers already, then add a type to their declaration:
my Int ($foo, $bar);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';
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.
[1] See, for example, https://github.com/moritz/json/blob/master/lib/JSON/Tiny/Gra...
Well, the context of the parent, and it's parent, was not Perl 6.
$_ 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.
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/...?
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 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.