Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sigils are underappreciated (2022)

raku-advent.blog

Post reply on HN
Print view View original

31–40 of 97 posts

Re: Sigils are underappreciated (2022)

#31

Post by scubbo »

calderwoodra wrote: post #15
jerf wrote: post #3

I like to rate programming language's features not by how much I use them when I'm in the given language, or how good they make me feel, but by how much I miss them when I'm in a different language, once I'm fluent in that language and writing in the native idiom. (This is important. If you're still trying to write X in Y, yes, you'll miss the features from X, but that's not a useful data point.) By this metric, rath…

I like this approach - We use python for our backend and the things I miss the most from other languages are the protected/public/private keywords (Java), single-line `if condition: return` statements (js, ruby, etc.), and npm/yarn/package.json (js). I miss types too but it feels unfair to complain about that with Python.

Fair point re: package management - but Python does support single-line conditionals, and reasonably robust type-checking with mypy.

Re: Sigils are underappreciated (2022)

#32

Post by G3rn0ti »

throwaway173738 wrote: post #18
xupybd wrote: post #7

Sigils in Perl were awful. They didn't behave concretely. Sometimes it was sort of a type annotation sometimes they were a weird incantation. Things like implicit scalar conversion @foods = qw(burgers fries shakes); $length = @foods; print $length, "\n"; Yeah it's easy to understand once you know what is happening but it's obscure. There are no easy clues to let you know what is happening. Then there are situations w…

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 actua…

> 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.

Re: Sigils are underappreciated (2022)

#36

Post by G3rn0ti »

xupybd wrote: post #7

Sigils in Perl were awful. They didn't behave concretely. Sometimes it was sort of a type annotation sometimes they were a weird incantation. Things like implicit scalar conversion @foods = qw(burgers fries shakes); $length = @foods; print $length, "\n"; Yeah it's easy to understand once you know what is happening but it's obscure. There are no easy clues to let you know what is happening. Then there are situations w…

> So it's not a type its more of a language implementation detail

Well, it’s used to distinguish between values that were passed into a function via „copy by value“ or „copy by reference“. Insofar sigils have nothing to do with types but rather with function passing semantics. Yes, with a good type system you can also communicate whether an array is passed by “copy by reference” in the type signature of a function. Then you wouldn’t need sigils. But it’s a secondary feature of static types.

However, you could also abolish “copy by value” altogether (as JS and Python do) and then wouldn’t need neither sigils nor types.

> Where as with the Hindley–Milner type system the types exist

Perl is a dynamically typed language. If it were using static types, it wouldn’t quite need sigils, yes, but then it also wouldn’t have been the Perl programming language…

Sigils do not really have anything to do with static types and shouldn’t be discussed in this context. Then they are also not as confusing.

BTW: This whole discussion of static vs. dynamic typing has become a bit tiresome over the years. It will never be settled. In the 90s everybody tended to hate static typing and for good reasons so: It makes generic programming quite a bit more complicated than necessary. This was when all these dynamically typed scripting languages were invented to enable programmers write abstract code more easily by lifting the burden of constantly inventing composite types. „If it walks like a duck …“

Of course, everything is a trade off and with that approach you are prone to get more run time errors and, hence, people started test-driven development. Then developers started to hate writing tests (also for good reasons) and re-discovered static typing. Now people seem to be happy hacking ad-hoc types together — until they have to refactor other people’s programs and find it rather tricky because of the contagiousness of type signatures. When they spent enough weeks to rewrite type signatures in half of the program base they will long for the good ol’ scripting languages of the 90s again. And the cycle begins again.

Re: Sigils are underappreciated (2022)

#37

Post by derefr »

epage wrote: post #27
derefr wrote: post #12

Earlier quoted context omitted.

> So while sigils have a lot of company in this, they are also a flat zero for me on this scale. Never ever missed them. I did a decade+ of Perl as my main language, so it's not for lack of exposure. I tend to miss one specific sigil (or pair of sigils): the @ and @@ sigils in Ruby, that mean "instance variable" and "class variable" respectively. Having identifier shadowing between stack-locals, and what Java would c…

> I tend to miss one specific sigil (or pair of sigils): the @ and @@ sigils in Ruby, that mean "instance variable" and "class variable" respectively. Having identifier shadowing between stack-locals, and what Java would call "members" and "statics", be literally impossible, is just so nice. Especially when you get it "for free" in terms of verbosity, rather than needing to type `self.class.` or something. When I wen…

The thing about Ruby is that it has uniform syntax — a.b for any a+b mean "send a message :b to a." So `self.foo` (and `self.foo = bar`, too!) are possible to write, but these are always interpreted as message sends (to the :foo and :foo= methods, respectively), not as direct field accesses. The "syntax-ness" of @ and @@ show are that you're specifically breaking out of† the paradigm of "everything is a message send", to instead "just" access a field. It's what makes this make sense:

    def foo # define a getter method
      @foo # in terms of a field access
    end
How would you write that, if the field access was spelled `self.foo`? The language wouldn't be able to tell that you're not just recursively calling the getter!

---

† Though, technically, you're not breaking out of the paradigm; @foo is short for self.instance_variable_get(:@foo). It's message-sends all the way down, until you hit natively-implemented methods.

Re: Sigils are underappreciated (2022)

#38

Post by [deleted] »

giraffe_lady wrote: post #28
TeMPOraL wrote: post #10

Earlier quoted context omitted.

Thanks for putting into words something I've started to feel over time, but never conceptualized clearly. I agree that closures pass the test - and I too remember when they weren't popular. I also remember what I did before learning about the very idea of first-class functions and closures: I simulated them with some ad-hoc means (like function pointers in C/C++, or passing strings to be eval()-ed in PHP, etc.). This…

A trivial but real one for me is being able to use non-alphanum chars freely in var and fn names. Being able to name a fn 'string->int' or especially something like 'valid?' seems very small but I really miss it in languages with more restrictions on names.

[deleted]

Re: Sigils are underappreciated (2022)

#39

Post by brabel »

eru wrote: post #9
Swizec wrote: post #5

Earlier quoted context omitted.

Thanks for putting into words something that was on the edge of my mind, but never quite graspable. Two more examples (for me?) of features that I find you really miss in a language even if you’re fluent in the local idioms: First-class functions and pattern matching. Passing functions as values is so nice and afaik most modern languages have that feature nowadays. But I remember when it used to blow people’s minds.…

Luckily pattern matching is also catching on. Rust might be partially responsible for that, maybe? Python has also massively improved its pattern matching recently.

Dart 3 got very nice pattern matching [1]. And the next version of Java might introduce it (but likely it will still be behind a "preview" flag) as well.

[1] https://dart.dev/language/patterns

Re: Sigils are underappreciated (2022)

#40

Post by jddj »

epage wrote: post #27
derefr wrote: post #12

Earlier quoted context omitted.

> So while sigils have a lot of company in this, they are also a flat zero for me on this scale. Never ever missed them. I did a decade+ of Perl as my main language, so it's not for lack of exposure. I tend to miss one specific sigil (or pair of sigils): the @ and @@ sigils in Ruby, that mean "instance variable" and "class variable" respectively. Having identifier shadowing between stack-locals, and what Java would c…

> I tend to miss one specific sigil (or pair of sigils): the @ and @@ sigils in Ruby, that mean "instance variable" and "class variable" respectively. Having identifier shadowing between stack-locals, and what Java would call "members" and "statics", be literally impossible, is just so nice. Especially when you get it "for free" in terms of verbosity, rather than needing to type `self.class.` or something. When I wen…

I explicit this.thing in C# as well. It started from inheriting some coding standards / projects whose designers came straight from C and didn't do the idiomatic _variable thing for instance variables.

Now it's quite an entrenched habit and at this stage I'd prefer if the implicit access wasn't possible.

Post reply on HN