[throwaway173738]

Perl is the most confusing language I’ve ever used professionally, largely because of how it uses sigils sometimes as operators. The other source of confusion are the million and a half implicit variables that are context-specific. It’s the only language where even after ten years I still regularly have to google to do simple things like iterate over a hash. And half the time it doesn’t work because the hash is actually a ref so now you need an arcane syntax or it doesn’t work. In Perl all of the implementation details of the language become footguns for you to shoot yourself with.

[G3rn0ti]

> And half the time it doesn’t work because the hash is actually a ref

Perl still supports both „copy by value“ and „copy by reference“. For example:

  my @copy = @original;
  my %hash_copy = %orig_hash;
  my @processed = foo_func(@copy);
  my $ref = \@copy;
  bar_func($ref); # modifies @copy in place

That’s why it uses these sigils to distinguish between references being scalar values (“$”) and actual lists/dictionaries (“@“ and “%”). Since Perl is also dynamically typed if it weren’t for the sigils, it would be quite confusing when reading “array[i] =“ somewhere not knowing whether it modifies an array created remotely or locally. Sigils communicate that because it reads “$array[$i] =“ for a local array or “$$array[$i]” for a remote one.

In other languages like JavaScript or Python everything is basically a reference and, hence, you don’t quite need sigils there. However, on the flip side, you need to be more careful and constantly remind yourself of the fact you are dealing with references and not to accidentally modify the objects you get passed into your function.

[tremon]

not knowing whether it modifies an array created remotely or locally

Yes, good language design allows the programmer to ignore details such as how an object was created or where it is stored.

Having to remember something like that violates so many design principles. Why would a programmer using the array need to know how it was created? It just adds unnecessary complexity to the code, making the programmer's job harder than it needs to be. It's accidental complexity ossified in the programming language.

[G3rn0ti]

> Having to remember something like that violates so many design principles.

While I am inclined to agree, this is the case for many languages. Python and JS for example IRC. When you receive a dictionary or an object as a function argument you have no write protection if you poke around inside of it. Perl makes it at least a bit more obvious.

In C++ you have constant reference signatures if you happen to use them but the syntax is also not exactly pretty.

In C you only may pass pointers to an array which is even done implicitly. No write protection either.

[kqr]

I hate to question someone's credentials, but

    for my $key (keys %hash) { ... }

or if it's a reference

    for my $key (keys %{$ref_to_hash}) { ... }

That is fairly simple, and not a good example of something that is difficult in Perl. If you cannot keep that straight, I suspect the extent to which you really use Perl is limited.

[hirihoto]

Perl is hardly alone in the million and a half implicit variables. Python is a far worse offender on this point and probably equally so in the context specific meaning of a statement (is this a generator or a list). My guess is this gripe is a familiarity thing. Iterating a hash in perl isn't that complicated, neither is iterating a hashref but you do need to be aware of which it is - which you should be anyway so you know whether you're modifying it locally or for the caller.

That said, I'm also in the camp of "I don't care much for sigils."