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

71–80 of 97 posts

Re: Sigils are underappreciated (2022)

#71

Post by Joker_vD »

epage wrote: post #70
derefr wrote: post #37

Earlier quoted context omitted.

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…

As someone who infrequently had to touch Ruby code, this was maddening. Years later, I only now am finding out what was going wrong and a better sense of what search terms to use. As I said I'm a big propoenent in languages being approachable for those infrequent one-off cases. I've been burned by the challenge of updating the "handful" of Perl and Ruby scripts (and Perl was my first language). This is why I advocate…

I also have to touch Ruby code from time to time, so when I found out I don't quite understand what "@" and "@@" mean (other parts, even blocks, were kinda more or less apparent), I... went and read the docs. Took me an hour or two but now I know what "@" and "@@" mean and actually think they're a pretty ingenious solution.

Re: Sigils are underappreciated (2022)

#72

Post by Joker_vD »

TeMPOraL wrote: post #58
robotresearcher wrote: post #52

Earlier quoted context omitted.

That’s what the ‘is’ is for. If you have a ‘?’ character, you don’t need it. But tastes vary. I don’t even like the ‘is’. 1. if isValid() 2. if valid?() 3. if isValid?() 4. if valid() Number 4 is nicest to my eyes. But I guess if the ‘?’ or ‘is’ (or both) is a promise to the user that the function is a true predicate, then I can see its utility.

'?' / 'is' get more useful with more complex predicate names than just 'valid', and they also help with certain corner cases in English. For example, what does the following code do: if(widget.free()) { ... } Does it 1) check if the widget is "free" (whatever that means in the widget domain), or 2) frees the widget and checks the outcome of that operation? If I saw something like this while reading code, I'd pause an…

> Does it 1) check if the widget is "free" (whatever that means in the widget domain), or 2) frees the widget and checks the outcome of that operation?

Just program in Esperanto! So 1) would be "umo.libera()" and 2) be "umo.liberigu()".

I can't believe I still remember the grammar after what, 10 years of complete disuse?

Re: Sigils are underappreciated (2022)

#73

Post by talideon »

G3rn0ti wrote: post #36
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. T…

The problem here isn't that Perl is a dynamically typed languages but because it uses pass-by-value semantics to an almost absurd degree. This is why it needs explicit references in the first place where as most other languages these either use references for non-primitive types (Ruby, Python, anything on the JVM, &c.) implicitly or treat values and references uniformly (Go, for instance).

Re: Sigils are underappreciated (2022)

#74

Post by flumpcakes »

If the author is reading,

The link in the yellow box to the follow up article links to the article itself instead of /2022/12/23/sigils-2/.

Also a missing word "hash" in the link towards the bottom of the article to hash_literals in the Raku documentation.

Re: Sigils are underappreciated (2022)

#76

Post by tremon »

G3rn0ti wrote: post #32
throwaway173738 wrote: post #18

Earlier quoted context omitted.

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 (“@“…

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.

Re: Sigils are underappreciated (2022)

#77

Post by [deleted] »

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…

[deleted]

Re: Sigils are underappreciated (2022)

#78

Post by jerf »

klibertp wrote: post #65
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…

> Despite my decades of dynamic typed languages, I hate going back to dynamic languages anymore. YMMV. Mine does vary - while static typing is helpful, it still (even with more advanced type systems) leads to boilerplate code that I dislike writing. In a compiler written in OCaml that I worked on for a bit, there were hundreds of lines of code dedicated to just stringifying variants. It could have been generated by a…

Some sort of coroutine solution is definitely on my list too. I'm actually not too passionate about which one it is, except for a distaste for async/await on the grounds the compiler ought to be able to do it for me. But generators, threads or actors cheap enough to use freely, coroutines, something that allows me to break out of the strictly hierarchical structured programming system and retain some degree of state within a function when I need to. It's possible to hack something together in a language lacking this, by moving all function state into a struct/object but all the manual scaffolding is painful and error prone.

Re: Sigils are underappreciated (2022)

#79

Post by p6steve »

I really like sigils for several reasons and I do miss them when in non sigil languages - imo raku made two big improvements over perl that is to avoid changing the sigil on accessing an item and to have an unsigilled option for people who don't like them https://rakujourney.wordpress.com/2022/12/24/on-sigils/

Re: Sigils are underappreciated (2022)

#80

Post by G3rn0ti »

tremon wrote: post #76
G3rn0ti wrote: post #32

Earlier quoted context omitted.

> 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 (“@“…

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

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

Post reply on HN