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.

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.

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.

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.

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.

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);

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.

https://www.stroustrup.com/whitespace98.pdf

* 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`.

groovy string interpolation is ${criticism}

/$

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

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.

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.