By 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.)
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.
I also really quite interned-string-literal : sigils in Ruby/Elixir — though I'd be equally fine with the Prolog/Erlang approach of barewords being symbols and identifiers needing to be capitalized. As long as there's some concise syntax for interned strings, especially in the context of dictionary keys. Because otherwise people just won't use them, even when they're there in the language. (See: Java, Python, ECMA6.)
Speaking of Elixir, the "universal sigil" ~ is kind of amazing. Define a macro sigil_h/2, and you can suddenly write ~h/foo/bar (or ~h[foo]bar, or whatever other delimiter works to best avoid the need for escaping), and foo and bar will be passed to sigil_h/2 as un-evaluated AST nodes to do with as you please. The language gives you ~w by default (which works like Ruby %w); but more interestingly, Regex literals in Elixir are just sigil_r.
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.
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.
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.
Rust might be partially responsible for that, maybe? Python has also massively improved its pattern matching recently.
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
It's not a huge win, but I do think it's better than nothing.
As for missing things, I do miss Perl a lot. I missed the curly braces when I first started and whitespace didn't feel right. Than after maybe 6 months I had to go back and do some Perl. Moved some blocks of code around, then got the dreaded missing brace problem. I realized that was something that I never got in Python and am a fan of whitespace since then.
I like to rate a programming language by how dependent the language is on some bloated IDE ("editor"). If I need an Eclipse or a Pycharm just to edit a file, something has gone wrong syntactically and systemically.
Sigils are semantic information about the code. Sigils do not reduce readability, they increase expressivity and comprehensibility. It isn't the characters themselves that are the problem -- we see the same notations for different purposes entering Python and DSLs such as Pandas.
Bash, awk, sed, and Perl are solid tools.
I like to use the tools that make me and my team the most efficient.
I've used both extensively a long time ago when my workstation had a Sun Microsystems logo on it (yeah I am that old) and I remember having problems to read my own scripts a few months later.
I don't miss those.
Words are the better sigils.
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.
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 syntax transform (the newer tools for this are actually quite good), but that's another dependency and another cognitive overhead. In Kotlin, lack of structural types means that the rabid "clean architecture" fans create 3 classes for each piece of data, with the same 10 fields (names and types), and methods to convert between those classes - it requires 10x as much code for very little gain. Lack of refinement types makes the type systems mostly unable to encode anything relating to the number values, other than min/max values for a given type. There's reflection in Kotlin (not in OCaml though) that you can use, but then we're back to everything being an Object/Any and having runtime downcasts everywhere.
I think gradual type systems are a good compromise, for now at least. I'd prefer Typed Racket approach of clearly delineating typed and untyped code while generating dynamic contracts based on static types when a value crosses the boundary. Unfortunately, that's not going to work for existing languages, so the next best thing is something like TypeScript or mypy.
Of course, convenient, hygienic, Turing-complete not by accident, compile time execution and macros would, to some extent, alleviate the problems a simplistic type systems cause. A good example is Haxe, Nim, Rust, Scala 3, etc. Without such features, though, I'm not willing to part with runtime reflection and metaprogramming facilities provided by dynamic languages - the alternative is a lot more lines of code that need to be written (or generated), and I don't like that.
---
More to the topic: logic variables. The `amb` operator from Scheme, for example, or what Mozart/Oz has, or Logtalk, or Prolog of course. They're powerful, incredibly succinct way of constraints solving without writing a solver (just state the problem declaratively and done - as close to magic as it gets). No popular language offers an internal logic DSL, although there are some external DSLs out there.
Also, coroutines. No more manual trampolining, no need for nested callbacks, the state of execution can be saved and resumed later mostly transparently. Lua has them built-in, Kotlin implements CPS transform in the compiler. Nowadays almost all popular languages provide them, mostly exposed as async/await primitives. Scheme and Smalltalk can implement them natively inside the language and did so for ages; it's nice to see mainstream languages catch up.
REPLs. Not a language feature per se, but an implementation decision that has a lot of impact on productivity. It's relatively commonplace now - even Java has jshell - but most of the REPLs are pretty bad at executing "in context" of a project or module. Racket, Clojure, Common Lisp, Erlang, Elixir are gold standards, still unmatched, but you can get pretty far with Jupyter Notebooks.
Destructuring/pattern matching. It was carefully added in some simplified cases (mostly simply destructuring sequences) in many languages, then the support for wildcard and splicing was added, then support for hashes/dicts was added, and now finally Python has a proper `match` statement. I think more languages will implement it in the near future.
Things like implicit scalar conversion
@foods = qw(burgers fries shakes);
$length = @foods;
print $length, "\n";
Then there are situations where you have a scalar but it's a ref
%author = (
'name' => "Harsha",
'designation' => "Manager"
);
$hash_ref = \%author;
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.
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
In other languages like JavaScript or Python everything is basically a reference and, hence, you don’t quite need sigils there. However, on the flip side, you need to be more careful and constantly remind yourself of the fact you are dealing with references and not to accidentally modify the objects you get passed into your function.
for my $key (keys %hash) { ... }
for my $key (keys %{$ref_to_hash}) { ... }
That said, I'm also in the camp of "I don't care much for sigils."
@foods = qw(burgers fries shakes);
$length = @foods;
$length = qw(burgers fries shakes);
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. Then you wouldn’t need sigils. But it’s a secondary feature of static types.
However, you could also abolish “copy by value” altogether (as JS and Python do) and then wouldn’t need neither sigils nor types.
> Where as with the Hindley–Milner type system the types exist
Perl is a dynamically typed language. If it were using static types, it wouldn’t quite need sigils, yes, but then it also wouldn’t have been the Perl programming language…
Sigils do not really have anything to do with static types and shouldn’t be discussed in this context. Then they are also not as confusing.
BTW: This whole discussion of static vs. dynamic typing has become a bit tiresome over the years. It will never be settled. In the 90s everybody tended to hate static typing and for good reasons so: 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 …“
Of course, everything is a trade off and with that approach you are prone to get more run time errors and, hence, people started test-driven development. Then developers started to hate writing tests (also for good reasons) and re-discovered static typing. Now people seem to be happy hacking ad-hoc types together — until they have to refactor other people’s programs and find it rather tricky because of the contagiousness of type signatures. When they spent enough weeks to rewrite type signatures in half of the program base they will long for the good ol’ scripting languages of the 90s again. And the cycle begins again.
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.
Don't confuse duck typing with dynamic typing.
@ 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”
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.
I think this insight crystalizes the trade-off. I agree with the author that sigils are a powerful way of communicating useful information in a concise fashion. But does their inscrutability to non-expert users justify their existence? I'd argue it usually doesn't. Whenever I've had to pick up a language that uses a lot of sigils (or even just had to read source code in one of those languages if I don't use it daily), I always find the sigils require a bit of extra mental effort to process. It seems like other languages manage to express meaning in a way that is less burdensome to non-experts.
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.
- 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
So there’s always trade offs.
20 years ago I might've agreed with you. But I do not think that PHP, BASIC and shell scripting are popular beginner languages in 2023.
> 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?
Quotation marks and especially parentheses after function calls don't fit TFA's definition of a sigil because they aren't at the beginning of the word and (arguably only in the latter case) don't communicate meta-information about the word.
> 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.
I'll agree with you that the line between sigils and general syntax/punctuation is a bit of a blurry one - where do you stop? Using my definition above, I think wrapping strings in quotation marks is a clear win because it fits our widely-held shared understanding that quotation marks demarcate and group a sequence of words. Single and double quotes behaving differently is unintuitive for the same reason while not conferring a corresponding benefit on experts.
While I understand where you're coming from, I'd argue that programming-related concepts are all "gobbledygook to non-programmers", that's to be expected. Having something like (this is close to valid Raku but it's not)
Positional[Any] ages = [42, 38, 25];
my @ages = [42, 38, 25];
> 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 don’t have exactly one folder-label. This is a job for sigils.
Prefixing email labels is a workaround in this case because you don't need to notice emails that belong to two folders if your filtering system is good.
> As you’ve probably noticed, I’ve been saying “has an array-like interface” instead of “is an Array ”. That’s because – and this is a crucial distinction – Raku’s sigils do not encode type information. They only tell you what interface you can use.
> ...
> And Buf s aren’t Array s, nor are they any subtype of Array . But they can be used with an array-like interface, so they can be stored in an @ -siglied variable.
Sounds like a missed opportunity to type buffers as byte arrays...
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.
The value of a sigil is for the other humans reading the code. And, I agree it can be quite valuable there.
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<MyClass>();
Console.WriteLine("default={0}, switch={1}", o.@default, o.@switch);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
https://raku-advent.blog/2022/12/02/day-2-less-variable-watt...
I haven't programmed C in a decade, I still remember most of it.
Interesting! By "half life of 10 minutes", do you mean the language was changing too quickly under you or that it was difficult to remember the sigils?
Sigilled "variables" do lose many of the perks that sigils provide though, as codesections explains in the blog.
You can read more about the Clojure reader here: https://clojure.org/reference/reader
Then you have Bjarne Stroustrup's "Generalized Overloading for C++2000", with which you can overload whitespace, uniquely redefining the meaning of space, newline, tab, and even the absence of space.
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.
Code clarity should be seen as higher priority than terseness or typing speed.
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.
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.
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.
> echo $foo # $foo refers to the contents of the variable foo
* a non-alphabetic character
* that is at the start of a word
* that communicates meta-information about the word.
He gives the example of `echo $USER`, where `$` is a single that communicates that `USER` is a variable, presumably with some contents. Thus, I'd wager `$` is a sigil in `$foo`.
@hash{a,b,c}
$hash{a,b,c}
And string interpolation (basically the same thing) is on python, groovy, and I think is coming to java.
groovy string interpolation is ${criticism}
/$