5 ms·

Having started with more modern scripting languages, such as ruby, javascript, or python, every time I touched perl I felt it was actively fighting me. Those si

Having started with more modern scripting languages, such as ruby, javascript, or python, every time I touched perl I felt it was actively fighting me. Those sigils! God, those sigils! It's bad enough that we have to prefix variable names with a dollar sign in php, as if a language parser can't be smart enough to figure out whether you mean a variable or not; but having to use three different sigils for scalar variable, array variable and hash variable, and needing to know when to refer to the same variable with the array sigil or the scalar sigil — this is just vile. Things like $_ or @_ didn't help either. Probably people who took up perl after something even more adversarial can learn to love it. I doubt I ever can. What I did love about perl though — something I don't find in modern languages — is its carefree playfulness, which must have stemmed from the hacker culture associated with it. I still chuckle every time I use Carp for debugging. Carp::croak, Carp::confess, or Carp::cluck are genius!

dmingod666 6y ago
I worked on and off on perl for about a year... Could never remember $_ and @_ which one was which..
- kbd 6y ago
  $calar, @rray is a mnemonic for the sigils.
singingfish 6y ago
The sigils are a feature that underpin perl's roots from practical linguistics (unlike other languages which have roots in theoretical linguistics). $ - > the value of @ - > the values of % -> the collection of key value pairs $_ is pronounced "it". @_ is pronounced "them". Don't use either of them except if it would make sense in english - e.g. you wouldn't refer to "it" in anything more than a sentence, so don't use $_ in anything longer than a couple of lines of code
- azangru 6y ago
  > The sigils are a feature that underpin perl's roots from practical linguistics I am not sure this metaphor makes sense to me. Imagine that I have a pack of dogs. When I use a language to say: "Remember that pack of dogs that I mentioned previously? Go ahead and give it to me" — I do not expect to also need to specify whether I want the pack with all the dogs in it, or whether I just want some value associated with that pack, which, if I remember perl's behaviour here, would be its length. I could understand if a language wanted me to specify whether I want the thing itself as opposed to a reference to the thing (I suppose it would make total sense as a Saussurian opposition of a signifier vs the signified); but the ternary opposition that perl enforces is neither here nor there linguistically — it's just bizarre.
  - daotoad 6y ago
    The the distinction in Perl is context. If I want to flatten that pack of dogs into a collection of individual dogs, I'd use the `@` sigil. If I want to operate on the pack as a whole, I'd use the `$`. Context and list flattening are probably the most foreign parts of Perl to someone who doesn't know it. Everyone fixates on the sigils, but the weirdness in the way sigils operate stems from context. When you call a function, the arguments are flattened into a single list. So `foo(1,2)` is the same as `my @args = (1,2,3); foo(@args, 3)`. Every expression can be evaluated in one or more contexts. So taking the value of an array in scalar context gives you the length, which is handy but also means that, since 0 is falsy, you can just do logical tests on arrays to check if they are empty. Because the behaviors are relatively intuitive, it's possible to quite a bit of work in Perl before you even understand what context is or how it operates. `if (@foo) { do_stuff(@foo) }` does what you'd think it does, even if you don't know about context. But it also means that the distinction between `my $match = $foo=~/(foo)/g;` and `my ($match) = $foo=~/(foo)/g;` is not at all obvious if you don't understand context. (The first example gives you the count of matches, the second example gives you the first match because the parens put you in a list context which means you are effectively assigning into a slice.)
  - singingfish 6y ago
    It's not a metaphor - it's the actual design. The fact that you use two sentences don't make sense together in order to try to illustrate your point seems to me to demonstrate that.
throwaddzuzxd 6y ago
>What I did love about perl though — something I don't find in modern languages — is its carefree playfulness, which must have stemmed from the hacker culture associated with it. I still chuckle every time I use Carp for debugging. Carp::croak, Carp::confess, or Carp::cluck are genius! As someone who works with a legacy system written in Perl (we're slowly moving to Go), I absolutely hate this. It's completely obscure for no reason, and that's just not fun. I'm glad no language does this anymore. Same goes for Perl critic levels: --brutal | --cruel | --harsh | --stern | --gentle, they're all compleyely useless at conveying any meaning! why is brutal > cruel??
- nikau 6y ago
  erg that's one thing I hate about modern tools, they love to use stupid terminology like helm with charts and salt with pillars and all this other childish shit.
  - goatinaboat 6y ago
    they love to use stupid terminology like helm with charts and salt with pillars and all this other childish shit Chef is the worst for this
    - bashinator 6y ago
      Yeah, Helm and K8s are not great in that regard, but the overwrought metaphors do end pretty quickly in favor of naming things for what the actually are.
- pvaldes 6y ago
  I suppose that because you can be cruel with somebody without touching it physically. Being brutal involves cruelty + physical violence, thus is more than cruel.
- blacktriangle 6y ago
  That same feeling of carefree playfulness is also the reason I keep meaning to give Raku a visit. They're pretty explicit about it even with pages like https://raku.org/fun/ https://raku.org/fun/ and https://raku.org/whatever/ https://raku.org/whatever/. It looks like they've done some interesting stuff around making text-based command line tools really easy to work with, which makes sense since that was a huge part of perl5's wheelhouse, so I think that may be a good place to start digging into Raku.
zby 6y ago
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.
- fatbird 6y ago
  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.
- azangru 6y ago
  > 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.

dmingod666 6y ago

I worked on and off on perl for about a year... Could never remember $_ and @_ which one was which..

kbd 6y ago
$calar, @rray is a mnemonic for the sigils.

singingfish 6y ago

The sigils are a feature that underpin perl's roots from practical linguistics (unlike other languages which have roots in theoretical linguistics). $ - > the value of @ - > the values of % -> the collection of key value pairs $_ is pronounced "it". @_ is pronounced "them". Don't use either of them except if it would make sense in english - e.g. you wouldn't refer to "it" in anything more than a sentence, so don't use $_ in anything longer than a couple of lines of code

azangru 6y ago
> The sigils are a feature that underpin perl's roots from practical linguistics I am not sure this metaphor makes sense to me. Imagine that I have a pack of dogs. When I use a language to say: "Remember that pack of dogs that I mentioned previously? Go ahead and give it to me" — I do not expect to also need to specify whether I want the pack with all the dogs in it, or whether I just want some value associated with that pack, which, if I remember perl's behaviour here, would be its length. I could understand if a language wanted me to specify whether I want the thing itself as opposed to a reference to the thing (I suppose it would make total sense as a Saussurian opposition of a signifier vs the signified); but the ternary opposition that perl enforces is neither here nor there linguistically — it's just bizarre.
- daotoad 6y ago
  The the distinction in Perl is context. If I want to flatten that pack of dogs into a collection of individual dogs, I'd use the `@` sigil. If I want to operate on the pack as a whole, I'd use the `$`. Context and list flattening are probably the most foreign parts of Perl to someone who doesn't know it. Everyone fixates on the sigils, but the weirdness in the way sigils operate stems from context. When you call a function, the arguments are flattened into a single list. So `foo(1,2)` is the same as `my @args = (1,2,3); foo(@args, 3)`. Every expression can be evaluated in one or more contexts. So taking the value of an array in scalar context gives you the length, which is handy but also means that, since 0 is falsy, you can just do logical tests on arrays to check if they are empty. Because the behaviors are relatively intuitive, it's possible to quite a bit of work in Perl before you even understand what context is or how it operates. `if (@foo) { do_stuff(@foo) }` does what you'd think it does, even if you don't know about context. But it also means that the distinction between `my $match = $foo=~/(foo)/g;` and `my ($match) = $foo=~/(foo)/g;` is not at all obvious if you don't understand context. (The first example gives you the count of matches, the second example gives you the first match because the parens put you in a list context which means you are effectively assigning into a slice.)
- singingfish 6y ago
  It's not a metaphor - it's the actual design. The fact that you use two sentences don't make sense together in order to try to illustrate your point seems to me to demonstrate that.

throwaddzuzxd 6y ago

>What I did love about perl though — something I don't find in modern languages — is its carefree playfulness, which must have stemmed from the hacker culture associated with it. I still chuckle every time I use Carp for debugging. Carp::croak, Carp::confess, or Carp::cluck are genius! As someone who works with a legacy system written in Perl (we're slowly moving to Go), I absolutely hate this. It's completely obscure for no reason, and that's just not fun. I'm glad no language does this anymore. Same goes for Perl critic levels: --brutal | --cruel | --harsh | --stern | --gentle, they're all compleyely useless at conveying any meaning! why is brutal > cruel??

nikau 6y ago
erg that's one thing I hate about modern tools, they love to use stupid terminology like helm with charts and salt with pillars and all this other childish shit.
- goatinaboat 6y ago
  they love to use stupid terminology like helm with charts and salt with pillars and all this other childish shit Chef is the worst for this
  - bashinator 6y ago
    Yeah, Helm and K8s are not great in that regard, but the overwrought metaphors do end pretty quickly in favor of naming things for what the actually are.
pvaldes 6y ago
I suppose that because you can be cruel with somebody without touching it physically. Being brutal involves cruelty + physical violence, thus is more than cruel.
blacktriangle 6y ago
That same feeling of carefree playfulness is also the reason I keep meaning to give Raku a visit. They're pretty explicit about it even with pages like https://raku.org/fun/ https://raku.org/fun/ and https://raku.org/whatever/ https://raku.org/whatever/. It looks like they've done some interesting stuff around making text-based command line tools really easy to work with, which makes sense since that was a huge part of perl5's wheelhouse, so I think that may be a good place to start digging into Raku.

zby 6y ago

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.

fatbird 6y ago
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.
azangru 6y ago
> 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.