Sigils are underappreciated (2022)
raku-advent.blog
Sigils are underappreciated (2022)
1–10 of 97 posts
Re: Sigils are underappreciated (2022)
#2And string interpolation (basically the same thing) is on python, groovy, and I think is coming to java.
Re: Sigils are underappreciated (2022)
#3By this metric, rather a lot of features turn out to be less important than they may seem at first. Many things are a zero on this scale that I think might surprise people still on their second or third language. From this perspective you start judging not whether a language has this or that exact feature that is a solution to a problem that you are used to, but whether it has a solution at all, and how good it is on its own terms.
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.
(As an example of something that does pass this test: Closures. Hard to use anything lacking them, though as this seems to be a popular opinion nowadays, almost everything has them. But I'm old enough to remember them being a controversial feature. Also, at this point, static types. Despite my decades of dynamic typed languages, I hate going back to dynamic languages anymore. YMMV.)
Re: Sigils are underappreciated (2022)
#4Re: Sigils are underappreciated (2022)
#5I 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…
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.
Pattern matching is something I’ve missed ever since having it in Haskell. Such an elegant solution to a problem that you have just often enough that the typical native approach feels clunky.
Re: Sigils are underappreciated (2022)
#6 @ says “Use me with an array-like interface”
% says “Use me with a hash-like interface”
& says “Use me with a function-like interface”
$ says “I won’t tell you what interface you can use, but treat me as a single item”
I don't use Raku nor used much of Perl5 (only enough to learn it's good for writing, not for reading). Sigils in Raku may be fine and better than not using them. I'll accept that.However, I much prefer inferred static typing and referential transparency where everything produces a value and it's not material whether it's a precomputed value or something that will produce the value when 'pulled on'. The last part works well with pure functions and lazy evaluation. Until someone claiming benefits of sigils has used this alternative for large, long-lived code written and maintained by many, I'll leave sigils to Raku alone.
Re: Sigils are underappreciated (2022)
#7Things 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 where you have a scalar but it's a ref
%author = (
'name' => "Harsha",
'designation' => "Manager"
);
$hash_ref = \%author;
So it's not a type its more of a language implementation detail that doesn't add value to the programmer.Where as with the Hindley–Milner type system the types exist and add value without requiring all of the extra code. You can infer the type most of the time and you get a nice strong type check at compile time.
Sigils seem like a step in the opposite direction to strong inferred types. You have to add a little bit of boiler plate but it's not that strict so it's meaning can still be confusing.
Re: Sigils are underappreciated (2022)
#8The value of a sigil is for the other humans reading the code. And, I agree it can be quite valuable there.
Re: Sigils are underappreciated (2022)
#9I 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 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.…
Rust might be partially responsible for that, maybe? Python has also massively improved its pattern matching recently.
Re: Sigils are underappreciated (2022)
#10I 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 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, I think, is an useful heuristic: the things likely to pass your test are the ones which people who don't have and don't know about them still end up approximating anyway - meaning those things are a natural solutions to some common problems.
I can think of couple other things that pass your test:
- Functions in general. It's the basic organizational primitive in code; working without them is Not Fun.
- Lisp-style macros. There are many problems that would be best solved with some surgical code generation, and having that option built-in into the language makes all the difference. Most languages don't have this type of macros - but that doesn't mean they aren't needed. Having done enough Lisp macrology, I saw that in those other languages I've always been coping. Missing them without knowing what they are.
Hell, look no further than webdev - these days, major frameworks like React, and every other minor library, and even the language evolution itself, all depend on running an external macro processor / code generation tool as part of your build pipeline.