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

41–50 of 97 posts

Re: Sigils are underappreciated (2022)

#41

Post by doctor_eval »

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 agree with this and in most languages I don’t miss sigils but one language I do wish supported them is plpgsql.

The reason is that column names and function arguments overlap a lot, which can cause ambiguities when performing updates or selects. To become productive at plpgsql it’s a problem that you have to solve.

There are several approaches but the one I settled on is just to prefix all formal parameters with underscores.

The wish I have with plpgsql is that I could use $ instead since underscore is already heavily used as a word separator.

Re: Sigils are underappreciated (2022)

#42

Post by xupybd »

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…

I was attempting to contrast the usefulness of sigils vs static typing. While they're different things the do serve similar purposes. They restrict a thing so one can reason about it. At a meta level they do similar things.

The reason I don't like Perl's sigils is that my head is not good at inferring meaning from something like a $ or % or \%. I prefer they way it's done in other languages where you have to call a copy or deep copy function. Not everyone would agree with that preference.

I think dynamic languages have their place. I'm personally more comfortable with the training wheels on in a statically typed language. But there are times where using a statically typed language is going to arrive at an overengineered solution. There are developers that can do amazing things in dynamic languages because they're good at catching their own errors and can leverage the flexibility of dynamic typing to their benefit.

Re: Sigils are underappreciated (2022)

#43

Post by xigoi »

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…

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

Don't confuse duck typing with dynamic typing.

Re: Sigils are underappreciated (2022)

#44

Post by crabmusket »

I wish that more programming languages would include detailed rationales and justifications of their features like this in their documentation. While this blog post doesn't have the rigor of something like the Ada Rationale[1], it gives a real sense of why something might have been designed the way it was.

Maybe I just enjoy reading this sort of thing. But we are so often told to choose the "best tool", or find ourselves evaluating programming languages for all sorts of reasons. Being able to understand a language in its context, the choices it made in comparison to the alternatives, can only help with that.

When I read the rationale for a new early-stage language Austral[2], I found myself actually able to evaluate what I thought the language might be good for, how it might evolve while under the control of the same creator, whether it fit with my personal strengths, weaknesses, methods and aesthetics, etc.

By contrast, I was perusing the documentation for Odin, another new language, at around the same time. While I don't want to disparage the incredible amount of work it took to a) build a programming language and ecosystem and b) document it, I found myself wishing for a similar "rationale" document so I could actually compare Odin with Austral at a more abstract level than reading syntax.

Odin's "overview" begins with an example of the lexical syntax of comments, rather than what the principle "Striving for orthogonality"[3] in its FAQ actually means and how it is borne out in the language as designed, compared to other approaches that could have been taken.

Austral, by contrast, has a great section called "the cutting room floor" where the creator discusses different approaches to resource safety, the difficult tradeoffs to be made, and why Austral decided on possibly the severest of all the approaches. This isn't just philosophy; it tells me something useful about the tradeoffs involved in using the language.

Anyway, the OP helped me to understand very clearly that Raku's priorities and values are extremely different to my own, and that it would likely be a bad choice for me to invest time in.

[1] http://ada-auth.org/standards/12rat/html/Rat12-TOC.html

[2] https://austral-lang.org/spec/spec.html

[3] https://odin-lang.org/docs/faq/

Re: Sigils are underappreciated (2022)

#45

Post by crabmusket »

whakim wrote: post #20

I think there's a piece of insight missing from the author's analysis of non-programmatic sigils. To wit, the sigils are only valuable when both parties deeply understand the information that the sigil is trying to convey . The "$framework at $dayjob" example illustrates this point. Programmers familiar with the use of sigils to indicate variables intrinsically grok this phrase, but it looks like gobbledygook to non-…

> because those symbols service important UX functions

As I read the post, I was thinking that #tags and @mentions are primarily about input, not reading. It's easier to just whack some #random #tags in your #sentences than to switch to a separate tag list input. Similarly, highlighting some text in order to apply the "mention" brush like we might with bold or italics would be strictly worse.

Re: Sigils are underappreciated (2022)

#46

Post by kqr »

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…

  @foods = qw(burgers fries shakes);
  $length = @foods;
Not to mention that this refactoring introduces a bug:

  $length = qw(burgers fries shakes);
Because lists and arrays convert to scalars differently. A list is more of a syntactic construct and an array is a data structure. Confused the heck out of me my first few weeks of Perl.

Re: Sigils are underappreciated (2022)

#47

Post by kqr »

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…

I hate to question someone's credentials, but

    for my $key (keys %hash) { ... }
or if it's a reference

    for my $key (keys %{$ref_to_hash}) { ... }
That is fairly simple, and not a good example of something that is difficult in Perl. If you cannot keep that straight, I suspect the extent to which you really use Perl is limited.

Re: Sigils are underappreciated (2022)

#48

Post by kqr »

One of the things sigil allow you to do is overload other syntax. The example I usually bring up is the difference between

    @hash{a,b,c}
which returns a list containing the values associated with keys a, b, and c; and on the other hand

    $hash{a,b,c}
which returns the single item associated with the key constructed from concatenating a, b, and c (used to emulate a three-dimensional array.)

Re: Sigils are underappreciated (2022)

#49

Post by kqr »

whakim wrote: post #20

I think there's a piece of insight missing from the author's analysis of non-programmatic sigils. To wit, the sigils are only valuable when both parties deeply understand the information that the sigil is trying to convey . The "$framework at $dayjob" example illustrates this point. Programmers familiar with the use of sigils to indicate variables intrinsically grok this phrase, but it looks like gobbledygook to non-…

Ah, the classic trade-off between designing for the convenience of beginners or experts! I'm in camp expert, but I get that not all people are.

Re: Sigils are underappreciated (2022)

#50

Post by iudqnolq »

derefr wrote: post #37
epage wrote: post #27

Earlier quoted context omitted.

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

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

You can require parentheses for method calls put methods and fields in separate namespaces.

https://play.rust-lang.org/?version=stable&mode=debug&editio...

Elixir supports paren-free calls but the default linter and formatter won't let you use them except for a few whitelisted DSLs. I've never missed not having them.

Post reply on HN