Hacker News Reader

Comment by zby | Hacker News Reader

Sigils are for simpler visual parsing - they stand out and mark the 'nouns'. It is not about the compiler - but about people reading the code. I know you can get similar advantages with IDEs colouring the code - here it is in the language itself. I find it useful. I think people just don't like the typography of dollar sign. It is ergonomic because it stands out but it is uglier than other glyphs and that impresses people badly. Later they only look for confirmation of that first bad impression.

But I agree about the use of '$' for array elements. '$array[$index]' - this is kind of unintuitive - because the array is @array - and here you need to change the sigil. That is why in Perl6 (and Raku now) they got rid of that.

View on HN

In my experience those sigils fell into the same trap that Hungarian notation discovered. A few sigils work well because they provide immediate comprehension, but there's a tipping point where they become noise and a barrier because there's too many, in too many combinations, to be readily understood. In every perl script you end up reading them out loud to parse them.

I remember the moment that Hungarian notation died for me (when previously I was all about it in C++): when I looked in the back of a Microsoft book on Visual Basic and found a six page table of four letter prefixes for all the different types you might encounter in VB6 with COM. The idea that I would either memorize those or continually look them up so that I knew what I was dealing with in code was the reductio ad absurdum of Hungarian notation.

> Sigils are for simpler visual parsing - they stand out and mark the 'nouns'. It is not about the compiler - but about people reading the code.

I would argue that python, ruby, javascript and similar languages have demonstrated that it's just as easy to read code without sigils as with them, probably even easier — let alone to write one. Uncle Bob and other evangelists of software craftsmanship suggest clear, descriptive names for variables that would convey their meaning to the reader. As far as I understand, perl programmers also don't dispute the value of meaningful names. At which point using additional twiddles for conveying intent to the reader becomes redundant.

The advantage with sigils, that little bit of standardized extra information means that I don't have to do any work to distinguish a verb from a noun. It makes it possible to use names that are just a bit shorter, on average, without sacrificing readability.

It's funny to me to see the same people who complain about sigils in perl whole heartedly adopt the Rx convention of naming streams with a tailing $.

It's literally just a sigil. Yeah, you put it at the end, but it serves the same exact purpose.

> It's funny to me to see the same people who complain about sigils in perl whole heartedly adopt the Rx convention of naming streams with a tailing $. It's literally just a sigil.

This one is a naming convention. Same as how the previous generation of javascript developers used to prepend variable names with a dollar sign if those variables referred to jquery-wrapped objects. Same as starting class names with a capital letter, or using all capitals to name constants. It doesn't have any special meaning for the parser. Your program won't break if you don't follow these naming conventions. It's entirely a style thing.

So an unenforced convention that does the same thing as a sigil, but worse. It can't be relied upon because it's not enforced. I've lost count of how many times I've seen streams without their trailing $ in codebases where people were theoretically using them.

If you can't rely on the symbol or its absence meaning anything, it's just more punctuation.

Reply on news.ycombinator.com