Sigils are underappreciated (2022) • Hacker News Board

Re: Sigils are underappreciated (2022)

#21

Post by davidw » Tue, May 30, 2023, 1:55 AM UTC

derefr wrote: post #12

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…

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

Yes, those are handy. I don't much care for all the other ones in Ruby. Maybe the regexp one.

Re: Sigils are underappreciated (2022)

#22

Post by Arathorn » Tue, May 30, 2023, 2:11 AM UTC

it’s always been a naughty pleasure that Matrix uses sigils both for ‘mainstream’ user IDs (@user:domain.com) and room aliases (#room:domain.com) as well as more developer focused things - $ for event IDs, ! for room IDs: https://spec.matrix.org/v1.7/appendices/#common-identifier-f...

I have a bad feeling this is due to me doing too much Perl as a child. But folks don’t seem to complain about it, especially since we also sprouted a proper URI scheme too.

Re: Sigils are underappreciated (2022)

#23

Post by smeagull » Tue, May 30, 2023, 2:11 AM UTC

Sigils are why I gave up learning PERL. Everything I learned had a half life of 10 minutes.

I haven't programmed C in a decade, I still remember most of it.

Re: Sigils are underappreciated (2022)

#24

Post by marai2 » Tue, May 30, 2023, 2:14 AM UTC

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…

Perl's regex handling. That's the one I miss in whatever other language I program in. To be able to match AND get the matched substrings out in one line, makes this really succinct.

Re: Sigils are underappreciated (2022)

#25

Post by js8 » Tue, May 30, 2023, 2:31 AM UTC

grzm wrote: post #16

js8 wrote: post #13

Regarding sigils, there is also ? and ! in Scheme and Clojure, and don't get me started on Forth, it's pretty much sigils all the way down.

In Clojure (and I’m pretty sure Scheme), ! and ? are not sigils in the sense that they’re special syntax like, say, @ (which is a reader macro), or @ and @@ in Ruby: they just tend to be used by convention. ! and ? are no different than a or b . You can read more about the Clojure reader here: https://clojure.org/reference/reader

They somewhat follow the OP's definition of sigil (in the yellow box), which doesn't say that sigils have to be interpreted in a special way, only that they convey some meaning to the programmer (although it's a bit unclear - communicate to whom, programmer or interpreter?). They are also not at the beginning of the word, but that seems to be rather arbitrary requirement.

Re: Sigils are underappreciated (2022)

#26

Post by LeonB » Tue, May 30, 2023, 2:41 AM UTC

throwaway290 wrote: post #19

Rambling and I disagree with a lot. > We had that problem at $day_job: our code was a mess, but everyone thought $framework would magically fix it. Replace with "a" or "that one" and it's the same or even better. The reality is that $dayjob (or %dayjob% etc) signals "hey I'm a programmer" and is less to type. > I need to be able to quickly distinguish between the two types of labels so that I can notice emails that d…

> The reality is that $dayjob (or %dayjob% etc) signals "hey I'm a programmer"

You’ve hit the nail on the head. It’s also about the reader who understands the context and thus feels a sense of belonging to an “in-group”.

It’s petty, but it’s how humans work. We form and reinforce our little cliques in anyway we can.

Re: Sigils are underappreciated (2022)

#27

Post by epage » Tue, May 30, 2023, 2:53 AM UTC

derefr wrote: post #12

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…

> 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 went from C++ to Python, the explicit "self" felt weird but over time, I felt it was much better. This became a lot more obvious in Rust. In C++ you get an implicit `this` variable and you get weird trailing keywords on functions to modify the `this` variable. Granted, these kinds of use cases won't be needed in every language. However, I also feel like sigils for this would be less understandable for someone unfamiliar with the language than explicit `self`. Something I judge a language on is how easy is the code to casually maintain by a group that is trying to get other stuff done.

Re: Sigils are underappreciated (2022)

#28

Post by giraffe_lady » Tue, May 30, 2023, 2:55 AM UTC

TeMPOraL wrote: post #10

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…

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.

Re: Sigils are underappreciated (2022)

#29

Post by jakear » Tue, May 30, 2023, 3:16 AM UTC

Well that's a whole lot of talk with 0 concrete code examples...

One interesting thing, the author mentions VS Code as abolishing the need for Hungarian notation, which is funny - the entire VS Code codebase in written in Hungarian.

Re: Sigils are underappreciated (2022)

#30

Post by RHSeeger » Tue, May 30, 2023, 3:46 AM UTC

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.

Although less encompassing than what you're talking about, I miss being able to name functions with a "?" at the end when they are a predicate; "isValid?".