Hacker News Reader

Comment by azangru | Hacker News Reader

> Perl is a great language

I don't write Perl often, which probably explains why every time I go back to it (we have a legacy Perl app), I get tripped up, over and over again, by the sigils, and the rest of the visual noise — and I can't help wondering, why?. Why can other scripting languages deal perfectly fine with the ambiguity that Perl resolves with a dollar sign as opposed to a percent sign, or an at-sign, or a backslash. Why do I, as a programmer need to remember that when I assign a hash as a value to another hash, I want to write it with curly braces; whereas in other contexts I want to write the hash using parentheses and assign it to a variable prefixed by the percent sign? Why do I then need to prefix the variable with "my" or "our" at the time of declaration? Why don't I have to do this in other scripting languages, not even in php, which has preserved the dollar sign? It's utterly bizarre.

View on HN

Don't forget there's also "state $var" and "local $var", which declare other types of variables. They're there because they.. are useful.

Same as why there's "var", "let" or "const" in JS. Different scoping / types of variable slots for the interpreter.

A "my" variable declares a variable valid in the current scope; an "our" variable will be available at the package level; a "state" variable is initialised only once, but has the same scope as a "my" variable; a "local" variable "locally overrides" for the current block (and any code called by the current block) the value of said variable.

They all have their uses, and that's why they exist.

`let` and `const` expand and replace `var`; and make variable declarations more intuitive by removing var's hoisting and adding block-level scoping (which the programmer doesn't need to care about if he doesn't wish to). What this means is that one can just use var if they are happy with it, or use let and const without the var. Not so with Perl. There is no "legacy mode", with all the awkward punctuation of decades ago, as opposed to a much saner "convenient modern mode" in Perl.

(Although I agree that a javascript programmer might get confused by declaring an object or an array as a const and then being allowed to mutate it.)

I'm not defending the sigils because they are terrible, but the reason you can't just get rid of them is that they are actually used.

For instance:

my @arr = ("Larry", "Moe", "Curly");

my $len = @arr;

will store 3 in $len. Application codebases and libraries make use of this kind of thing everywhere.

You can find some of the reasoning why in interesting essays like this: http://www.wall.org/~larry/natural.html

Larry Wall was trying to incorporate some natural language features in Perl, unsuccessfully in this case but I would say it went very well in others.

> ..every time I go back to it I get tripped up, over and over again, by the sigils, and the rest of the visual noise

From what I remember of writing Perl - it is a lovely language to write, but not to read. I remember going back to my own code and thinking what the hell am I doing here.

The sigil is there because Perl is made for text templating, like bash and PHP. Similar to f-strings in Python 3. Having several sigils is because Perl has language context as first order feature. It is a form of operator overloading.

I have the opposite reaction than the one you describe. Why haven't other languages picked up on contexts?

It's an elegant to solution to the fact that casts can be ambiguous in late-bound dynamically typed languages. PHP specifically can suffer from this where the automatic casting gives you a different type than you expected and no one notices because it isn't an error with dynamic types. It eliminates a class of errors.

The other things I miss most from Perl are taint mode, and Moose. Metadata for objects is such a good idea, where you can see all the traits and other properties in one place.

What I don't miss about Perl is that complex data structures are overly verbose. Multidimensional arrays and hashes are much too hard to read. Ruby did that much better.

> Why [does Perl use a lot of weird punctuation]

Because that’s how it started, and it maintains absolutely fantastic backwards compatibility. All languages have foibles…

> Why do I need to [declare variables prior to use]

Because this isn’t Python

>> Why do I need to [declare variables prior to use]

You don't need to if you don't use strict mode, which I think it is ok for small scripts.

>fantastic backwards compatibility

Yeah, Perl 6 was so <s>fantastically compatible</s> it took so many decades to come out they had to rename it something else so as not to confuse people.

>Because this isn’t Python

Perl 6 isn't Perl, either.

It's not called Perl 6 anymore for exactly this reason.

Most of us never considered Raku, even before the rename, to be Perl.

A perl in the sense that, say, Common Lisp, Scheme and Clojure all count as a lisp.

But no further.

> Why do I need to [declare variables prior to use]

Given the zen of python specifically says "explicit is better than implicit" I've always been stunned that python doesn't require that.

I've spent enough years writing perl that, believe me, I can hate its foibles more extensively and more accurately than most of the anti-perl people, and generally when I read criticisms of perl my first thought is "this wasn't wrong but it doesn't go nearly far enough."

But not requiring something like 'my' is python abdicating its own stated principles and while I don't feel I know python well enough to criticise it appropriately in general, this has always struck me as, in fact, a deeply un-pythonic attribute of the language.

Sigils are used for shell scripts and awk, and Perl is descended from both.

They are a useful visual indicator that something is a variable, so they don't bother me.

Newer versions of Perl add post-dereference syntax which reduces the line noise.

just re-read this comment you wrote, where you list out all of the rules that you forget, and you'll be on easy street

Reply on news.ycombinator.com