Live data from Hacker News

Sigils are underappreciated (2022)

raku-advent.blog

51–60 of 97 posts

Re: Sigils are underappreciated (2022)

#51
Personally, I have the exact opposite thoughs on sigils: they break my fluency in reading code.

Not all sigils are as bad, but to me it's as if there's a word from a foreign language italicized in an english sentance -- that means I'll have a reading pause there.

The dollar sign is among the worst, and curly braces are the lightest, with ”@" bring in the middle in terms of pausing reading.

Re: Sigils are underappreciated (2022)

#52

Earlier quoted context omitted.

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

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.

Re: Sigils are underappreciated (2022)

#53
post #24
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.

isn't that the same in any expression-oriented language ?

E.g. in ruby this could be

    puts $1 if /(\d+)/ =~ 'test 123' # perl-like
    
    if m = /(\d+)/.match('test 123') then puts m[1] end # perl-less
Perl's regexes do more things perhaps, but this is a relatively common thing, I believe.

Re: Sigils are underappreciated (2022)

#54
post #31

Earlier quoted context omitted.

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.

MyPy isn't quite as nice as typescript, and it also has some trouble with Django. I know it CAN work, but does any language have a worse type system? Maybe Ruby.

For single line conditionals - looks like you're right from that I can tell. I mistakenly assumed the pep8 errors were actually interpreter errors. Thank you!

Re: Sigils are underappreciated (2022)

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

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

In languages that require parens for method calls, not using them usually gets you a method handle. Which is still in conflict with a field reference — usually because methods are just function-pointer-typed static fields.

Re: Sigils are underappreciated (2022)

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

I might agree with you if I ask for the fact some of the most popular beginner languages use sigils:

- BASIC

- Shell scripting

- PHP

It’s also worth noting that all languages have special tokens to identify properties of the code. Eg why does a string need to be wrapped in quotation marks but integers do not? Why do single and double quotation marks behave differently in some languages? Why do function names behave differently if you pass () vs not including parentheses in some languages?

At the end of the day, if you want to learn to program then you are always going to have some degree of syntax that you just have to learn. Sigils aren’t inherently hard but some languages make I them more abstract than others.

Another thing that’s worth baring in mind is that sigils solve a problem in languages that make heavy use of barewords, such as shells. Eg how do you know if foobar is a variable, function, keyword, parameter, etc if you syntax is

   echo foobar
This is why other languages then use quotation marks, parentheses, etc. But while that’s arguably more readable, it’s a pain in the arse for REPL work in a shell (I know because I’ve tried it).

So there’s always trade offs.

Re: Sigils are underappreciated (2022)

#57
post #55

Earlier quoted context omitted.

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

In languages that require parens for method calls, not using them usually gets you a method handle. Which is still in conflict with a field reference — usually because methods are just function-pointer-typed static fields.

That's why I said "you can" rather than "you must". And linked to an example that of a language with the property I described.

Re: Sigils are underappreciated (2022)

#58

Earlier quoted context omitted.

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

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 and carefully check what exactly is going on here.

In fact, I was going to write "Option 2) resembles resource management patterns, for example memory management in C", but then I checked and noticed that free() in C does not return a value, so this pattern would not exist with malloc()/free() - in other words, despite doing a bit of C and a lot of C++ in the past two decades, I still tripped over this.

Now compare with:

  if(widget.isFree()) { ... }
  if(widget.free?()) { ... }
Both resolve this ambiguity.

On that note, I'd love some kind of sigil for "asserting" functions - which are similar to checks, but instead of returning true/false, they ensure the argument is in the state described by the function name, or else they throw an exception. It's a pattern I've been using in exception-ful code to cut down on noise. For example:

  // Check if connected; if not, maybe run reconnection
  // logic or attempt some other form of recovery.
  // The only way control proceeds past this line is if
  // the session is connected; if it isn't and can't be,
  // exception is thrown.
  EnsureConnected(session);
   
  if(IsSomething(session, arg1)) {
    // ... some code requiring connected session
  }
  // ... more code requiring connected session
It's not a big deal, but in some cases, that "Ensure" or "Assert" look weird, and I don't like inventing more synonyms for the same pattern.

Re: Sigils are underappreciated (2022)

#59

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…

Good points.

I’d avoid overloading a standard library function name like free().

Your request for syntax for assertions reminds me of the ‘guard’ keyword in Swift, which is good for making sure of preconditions.

Re: Sigils are underappreciated (2022)

#60
post #8

We are past the point where sigils are useful for a modern compiler or machine interpreter. A limited ability to avoid collisions with "reserved words" ... would be more of a mis-feature than a feature. The value of a sigil is for the other humans reading the code. And, I agree it can be quite valuable there.

> A limited ability to avoid collisions with "reserved words" ... would be more of a mis-feature than a feature.

While I don't necessarily disagree with you, there's something I'd like to mention.

C# allows using @ before a variable name which happens to be the same as a keyword to escape the name.

I don't remember the specifics, but it has saved me once when I wanted to create a class shaped exactly like a JSON object I was loading from an external source and one of the fields was a reserved word. For example, this works fine:

    class MyClass
    {
        public int value;
        public string @default;
        public string @switch;
    }
    
    string json = "{\"value\": 8, \"default\": \"something\", \"switch\": \"on\"}";

    MyClass o = JObject.Parse(json).ToObject();
    Console.WriteLine("default={0}, switch={1}", o.@default, o.@switch);
Post reply on HN