10 ms·

Sigils are underappreciated (2022)

150 points by luuuzeta 3y ago

AtlasBarfed 3y ago
Templating is practically universal. And string interpolation (basically the same thing) is on python, groovy, and I think is coming to java.
- __MatrixMan__ 3y ago
  $/ groovy string interpolation is ${criticism} /$
jerf 3y ago
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, 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.)
- Swizec 3y ago
  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. 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.
  - eru 3y ago
    Luckily pattern matching is also catching on. Rust might be partially responsible for that, maybe? Python has also massively improved its pattern matching recently.
    - brabel 3y ago
      Dart 3 got very nice pattern matching [1]. And the next version of Java might introduce it (but likely it will still be behind a "preview" flag) as well. [1] https://dart.dev/language/patterns https://dart.dev/language/patterns
- TeMPOraL 3y ago
  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, 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.
  - giraffe_lady 3y ago
    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.
    - RHSeeger 3y ago
      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?".
      - robotresearcher 3y ago
        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.
- derefr 3y ago
  > 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 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.
  - systems_glitch 3y ago
    Agree on Ruby ivar/cvar sigils. We ran into some nasty variable shadowing, especially with autowiring frameworks, in big Java projects over the years.
  - davidw 3y ago
    Yes, those are handy. I don't much care for all the other ones in Ruby. Maybe the regexp one.
  - epage 3y ago
    > 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.
- waynesonfire 3y ago
  Well articulated. Thanks.
- calderwoodra 3y ago
  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.
  - scubbo 3y ago
    Fair point re: package management - but Python does support single-line conditionals, and reasonably robust type-checking with mypy.
    - calderwoodra 3y ago
      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!
      - scubbo 3y ago
        Glad I could help :)
      - talideon 3y ago
        I believe that the reason you're having issues with Django is that Django lacks types on its external interfaces. This isn't an issue with MyPy. You're conflating language-level issues with code-level issues. Python's type hints are quite powerful, assuming you're using stuff that provides them. At this point, it has a better type system than Go (if only because it has sum types and option types), but it's opt-in.
- marai2 3y ago
  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.
  - riffraff 3y ago
    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.
    - shakow 3y ago
      Ruby is a very concise language. Matching & getting in most languages typically devolves into matching a regexp to a string, getting a MatchResult object, and then getting/iterating/checking/... on it.
    - marai2 3y ago
      ($hour, $min, $sec) = $someTimeString =~ /(\d\d):(\d\d):(\d\d)/; if ($hour >= 12) { if ($min == 42) { doSomething(); } } Whereas in Python, Ruby even though it's only a tiny extra step, but that symantic distance in one's head when parsing out and naming the parts of a regex on the same is a convenience that when you get used to it, you really miss it. m = /(\d\d):(\d\d):(\d\d)/.match( someTimeString ) hour = m[0] min = m[1] sec = m[2] if hour >= ...
      - riffraff 3y ago
        but ruby, python etc.. can just extract the list too, it's just an extra method call on the same object (perhaps there could be destructuring too in modern ruby/python) hour, min, sec = /(\d\d):(\d\d):(\d\d)/.match('10:11:12').captures or hour, min, sec = re.compile(r'(\d\d):(\d\d):(\d\d)').match('10:11:12').groups() ruby & python will explode if there is no match rather than fail silently but I'm not convinced the difference is huge.
- doctor_eval 3y ago
  I agree with this and in most languages I don’t miss sigils but one language I do wish supported them is plpgsql. 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.
- collyw 3y ago
  I switched from Perl to Python around 12 years ago. I do think the sigils make code a little faster to comprehend. A bare word in python can be anything, wheres a variable will always start with a '$' or '@'. 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.
- klibertp 3y ago
  > Despite my decades of dynamic typed languages, I hate going back to dynamic languages anymore. YMMV. 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.
- heresie-dabord 3y ago
  > modern IDEs and editors give us all the type information we could want, and these tools made sigils obsolete. 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.
  - scubbo 3y ago
    > I like to rate a programming language by how dependent the language is on some bloated IDE ("editor") I like to use the tools that make me and my team the most efficient.
  - stephc_int13 3y ago
    sed and Perl scripts are very often extremely hard to decipher. 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.
- deleted 3y ago
  [deleted]
mfranc42 3y ago
Yes. Namespaces good. Escape sequences good. Terse syntax good. As long as it's not rare and obscure good. :-)
karmakaze 3y ago
Perl5 got sigils wrong, where more complex usages hinted at incorrect human parsing of expressions. That was designed borrowing from natural language, so wd should probably throw out the early part of the post. Now the post says in Raku @ 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.
xupybd 3y ago
Sigils in Perl were awful. They didn't behave concretely. Sometimes it was sort of a type annotation sometimes they were a weird incantation. Things 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.
- throwaway173738 3y ago
  Perl is the most confusing language I’ve ever used professionally, largely because of how it uses sigils sometimes as operators. The other source of confusion are the million and a half implicit variables that are context-specific. It’s the only language where even after ten years I still regularly have to google to do simple things like iterate over a hash. And half the time it doesn’t work because the hash is actually a ref so now you need an arcane syntax or it doesn’t work. In Perl all of the implementation details of the language become footguns for you to shoot yourself with.
  - G3rn0ti 3y ago
    > And half the time it doesn’t work because the hash is actually a ref 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 That’s why it uses these sigils to distinguish between references being scalar values (“$”) and actual lists/dictionaries (“@“ and “%”). Since Perl is also dynamically typed if it weren’t for the sigils, it would be quite confusing when reading “array[i] =“ somewhere not knowing whether it modifies an array created remotely or locally. Sigils communicate that because it reads “$array[$i] =“ for a local array or “$$array[$i]” for a remote one. 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.
powera 3y ago
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.
- Zecc 3y ago
  > 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<MyClass>(); Console.WriteLine("default={0}, switch={1}", o.@default, o.@switch);
mkoubaa 3y ago
Avoiding sigils is a good future proofing strategy. When you find out you need a new syntax it's nice to have a set of symbols that are guaranteed not to break existing code
- thwarted 3y ago
  The way you worded this reminded me about some language extensions for the Commodore 64 and 128 that hooked into the BASIC language tokenizer. I remember one published in RUN magazine, I think for additional graphics functions, that added new BASIC instructions that were all prefixed with @. Not only did this prefix invoke the new code while interpreting, it also namespaced the addition avoiding conflicts with existing BASIC code.
js8 3y ago
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.
- grzm 3y ago
  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 https://clojure.org/reference/reader
  - js8 3y ago
    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.
- DonHopkins 3y ago
  I perceive FORTH in a different way. The only sigil in FORTH is SPACE. Everything else is a letter. 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 https://www.stroustrup.com/whitespace98.pdf
throwaway290 3y ago
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 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...
- LeonB 3y ago
  > 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.
whakim 3y ago
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-programmers. The email inbox example is similar. (I'd argue the hashtag/@-symbol example is a bit more complicated, because those symbols service important UX functions.) 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.
- crabmusket 3y ago
  > because those symbols service important UX functions 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.
- kqr 3y ago
  Ah, the classic trade-off between designing for the convenience of beginners or experts! I'm in camp expert, but I get that not all people are.
- hnlmorg 3y ago
  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.
Arathorn 3y ago
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-format 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.
smeagull 3y ago
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.
- luuuzeta 3y ago
  >Sigils are why I gave up learning PERL. Everything I learned had a half life of 10 minutes. 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?
  - smeagull 3y ago
    I would look things up, write my code and then if I had to look at it again it was like looking at code I had never seen before.
jakear 3y ago
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.
emmelaich 3y ago
Pedant mode: In BASIC, since the $ is at the end of var name, is it not a sigil?
__MatrixMan__ 3y ago
I'm not sure I understand what counts as a sigil and what doesn't. How many sigils does the following line have? > echo $foo # $foo refers to the contents of the variable foo
- luuuzeta 3y ago
  The author defines a _sigil_ as follows: * 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`.
  - __MatrixMan__ 3y ago
    I suppose "word" is the constraining factor there, I was thinking of > and # as sigils too, which--if you're willing to be a bit loose with what a "word" is--contradicts that they're unpopular.
crabmusket 3y ago
I wish that more programming languages would include detailed rationales and justifications of their features like this in their documentation. While this blog post doesn't have the rigor of something like the Ada Rationale[1], it gives a real sense of why something might have been designed the way it was. 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 http://ada-auth.org/standards/12rat/html/Rat12-TOC.html [2] https://austral-lang.org/spec/spec.html https://austral-lang.org/spec/spec.html [3] https://odin-lang.org/docs/faq/ https://odin-lang.org/docs/faq/
- luuuzeta 3y ago
  Thanks for the Austral spec link! Programming languages come and go but I find it deeply interesting when language designers lay out the rationale behind possibly outlandish decisions in their programming languages. Case in point, Larry Wall and Perl-y languages [0] [0] http://www.wall.org/~larry/natural.html http://www.wall.org/~larry/natural.html
kqr 3y ago
One of the things sigil allow you to do is overload other syntax. The example I usually bring up is the difference between @hash{a,b,c} which returns a list containing the values associated with keys a, b, and c; and on the other hand $hash{a,b,c} which returns the single item associated with the key constructed from concatenating a, b, and c (used to emulate a three-dimensional array.)
mihaic 3y ago
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.
ChoHag 3y ago
[dead]
stephc_int13 3y ago
I am in the "the less sigils the better" camp. Code clarity should be seen as higher priority than terseness or typing speed.
flumpcakes 3y ago
If the author is reading, 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.
nige123 3y ago
Sigils are just part of the picture. For Raku "twigils" (secondary sigils) are important too: https://raku-advent.blog/2022/12/02/day-2-less-variable-wattage-more-flow/ https://raku-advent.blog/2022/12/02/day-2-less-variable-watt...
p6steve 3y ago
I really like sigils for several reasons and I do miss them when in non sigil languages - imo raku made two big improvements over perl that is to avoid changing the sigil on accessing an item and to have an unsigilled option for people who don't like them https://rakujourney.wordpress.com/2022/12/24/on-sigils/ https://rakujourney.wordpress.com/2022/12/24/on-sigils/
- luuuzeta 3y ago
  >and to have an unsigilled option for people who don't like them Sigilled "variables" do lose many of the perks that sigils provide though, as codesections explains in the blog.

150 points by luuuzeta 3y ago

Templating is practically universal. And string interpolation (basically the same thing) is on python, groovy, and I think is coming to java.

__MatrixMan__ 3y ago
$/ groovy string interpolation is ${criticism} /$

jerf 3y ago

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, 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.)

Swizec 3y ago
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. 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.
- eru 3y ago
  Luckily pattern matching is also catching on. Rust might be partially responsible for that, maybe? Python has also massively improved its pattern matching recently.
  - brabel 3y ago
    Dart 3 got very nice pattern matching [1]. And the next version of Java might introduce it (but likely it will still be behind a "preview" flag) as well. [1] https://dart.dev/language/patterns https://dart.dev/language/patterns
TeMPOraL 3y ago
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, 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.
- giraffe_lady 3y ago
  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.
  - RHSeeger 3y ago
    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?".
    - robotresearcher 3y ago
      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.
derefr 3y ago
> 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 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.
- systems_glitch 3y ago
  Agree on Ruby ivar/cvar sigils. We ran into some nasty variable shadowing, especially with autowiring frameworks, in big Java projects over the years.
- davidw 3y ago
  Yes, those are handy. I don't much care for all the other ones in Ruby. Maybe the regexp one.
- epage 3y ago
  > 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.
waynesonfire 3y ago
Well articulated. Thanks.
calderwoodra 3y ago
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.
- scubbo 3y ago
  Fair point re: package management - but Python does support single-line conditionals, and reasonably robust type-checking with mypy.
  - calderwoodra 3y ago
    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!
    - scubbo 3y ago
      Glad I could help :)
    - talideon 3y ago
      I believe that the reason you're having issues with Django is that Django lacks types on its external interfaces. This isn't an issue with MyPy. You're conflating language-level issues with code-level issues. Python's type hints are quite powerful, assuming you're using stuff that provides them. At this point, it has a better type system than Go (if only because it has sum types and option types), but it's opt-in.
marai2 3y ago
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.
- riffraff 3y ago
  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.
  - shakow 3y ago
    Ruby is a very concise language. Matching & getting in most languages typically devolves into matching a regexp to a string, getting a MatchResult object, and then getting/iterating/checking/... on it.
  - marai2 3y ago
    ($hour, $min, $sec) = $someTimeString =~ /(\d\d):(\d\d):(\d\d)/; if ($hour >= 12) { if ($min == 42) { doSomething(); } } Whereas in Python, Ruby even though it's only a tiny extra step, but that symantic distance in one's head when parsing out and naming the parts of a regex on the same is a convenience that when you get used to it, you really miss it. m = /(\d\d):(\d\d):(\d\d)/.match( someTimeString ) hour = m[0] min = m[1] sec = m[2] if hour >= ...
    - riffraff 3y ago
      but ruby, python etc.. can just extract the list too, it's just an extra method call on the same object (perhaps there could be destructuring too in modern ruby/python) hour, min, sec = /(\d\d):(\d\d):(\d\d)/.match('10:11:12').captures or hour, min, sec = re.compile(r'(\d\d):(\d\d):(\d\d)').match('10:11:12').groups() ruby & python will explode if there is no match rather than fail silently but I'm not convinced the difference is huge.
doctor_eval 3y ago
I agree with this and in most languages I don’t miss sigils but one language I do wish supported them is plpgsql. 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.
collyw 3y ago
I switched from Perl to Python around 12 years ago. I do think the sigils make code a little faster to comprehend. A bare word in python can be anything, wheres a variable will always start with a '$' or '@'. 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.
klibertp 3y ago
> Despite my decades of dynamic typed languages, I hate going back to dynamic languages anymore. YMMV. 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.
heresie-dabord 3y ago
> modern IDEs and editors give us all the type information we could want, and these tools made sigils obsolete. 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.
- scubbo 3y ago
  > I like to rate a programming language by how dependent the language is on some bloated IDE ("editor") I like to use the tools that make me and my team the most efficient.
- stephc_int13 3y ago
  sed and Perl scripts are very often extremely hard to decipher. 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.
deleted 3y ago
[deleted]

mfranc42 3y ago

Yes. Namespaces good. Escape sequences good. Terse syntax good. As long as it's not rare and obscure good. :-)

karmakaze 3y ago

Perl5 got sigils wrong, where more complex usages hinted at incorrect human parsing of expressions. That was designed borrowing from natural language, so wd should probably throw out the early part of the post. Now the post says in Raku @ 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.

xupybd 3y ago

Sigils in Perl were awful. They didn't behave concretely. Sometimes it was sort of a type annotation sometimes they were a weird incantation. Things 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.

throwaway173738 3y ago
Perl is the most confusing language I’ve ever used professionally, largely because of how it uses sigils sometimes as operators. The other source of confusion are the million and a half implicit variables that are context-specific. It’s the only language where even after ten years I still regularly have to google to do simple things like iterate over a hash. And half the time it doesn’t work because the hash is actually a ref so now you need an arcane syntax or it doesn’t work. In Perl all of the implementation details of the language become footguns for you to shoot yourself with.
- G3rn0ti 3y ago
  > And half the time it doesn’t work because the hash is actually a ref 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 That’s why it uses these sigils to distinguish between references being scalar values (“$”) and actual lists/dictionaries (“@“ and “%”). Since Perl is also dynamically typed if it weren’t for the sigils, it would be quite confusing when reading “array[i] =“ somewhere not knowing whether it modifies an array created remotely or locally. Sigils communicate that because it reads “$array[$i] =“ for a local array or “$$array[$i]” for a remote one. 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.

powera 3y ago

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.

Zecc 3y ago
> 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<MyClass>(); Console.WriteLine("default={0}, switch={1}", o.@default, o.@switch);

mkoubaa 3y ago

Avoiding sigils is a good future proofing strategy. When you find out you need a new syntax it's nice to have a set of symbols that are guaranteed not to break existing code

thwarted 3y ago
The way you worded this reminded me about some language extensions for the Commodore 64 and 128 that hooked into the BASIC language tokenizer. I remember one published in RUN magazine, I think for additional graphics functions, that added new BASIC instructions that were all prefixed with @. Not only did this prefix invoke the new code while interpreting, it also namespaced the addition avoiding conflicts with existing BASIC code.

js8 3y ago

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.

grzm 3y ago
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 https://clojure.org/reference/reader
- js8 3y ago
  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.
DonHopkins 3y ago
I perceive FORTH in a different way. The only sigil in FORTH is SPACE. Everything else is a letter. 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 https://www.stroustrup.com/whitespace98.pdf

throwaway290 3y ago

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

LeonB 3y ago
> 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.

whakim 3y ago

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-programmers. The email inbox example is similar. (I'd argue the hashtag/@-symbol example is a bit more complicated, because those symbols service important UX functions.) 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.

crabmusket 3y ago
> because those symbols service important UX functions 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.
kqr 3y ago
Ah, the classic trade-off between designing for the convenience of beginners or experts! I'm in camp expert, but I get that not all people are.
hnlmorg 3y ago
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.

Arathorn 3y ago

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

smeagull 3y ago

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.

luuuzeta 3y ago
>Sigils are why I gave up learning PERL. Everything I learned had a half life of 10 minutes. 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?
- smeagull 3y ago
  I would look things up, write my code and then if I had to look at it again it was like looking at code I had never seen before.

jakear 3y ago

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.

emmelaich 3y ago

Pedant mode: In BASIC, since the $ is at the end of var name, is it not a sigil?

__MatrixMan__ 3y ago

I'm not sure I understand what counts as a sigil and what doesn't. How many sigils does the following line have? > echo $foo # $foo refers to the contents of the variable foo

luuuzeta 3y ago
The author defines a _sigil_ as follows: * 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`.
- __MatrixMan__ 3y ago
  I suppose "word" is the constraining factor there, I was thinking of > and # as sigils too, which--if you're willing to be a bit loose with what a "word" is--contradicts that they're unpopular.

crabmusket 3y ago

I wish that more programming languages would include detailed rationales and justifications of their features like this in their documentation. While this blog post doesn't have the rigor of something like the Ada Rationale[1], it gives a real sense of why something might have been designed the way it was. 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 http://ada-auth.org/standards/12rat/html/Rat12-TOC.html [2] https://austral-lang.org/spec/spec.html https://austral-lang.org/spec/spec.html [3] https://odin-lang.org/docs/faq/ https://odin-lang.org/docs/faq/

luuuzeta 3y ago
Thanks for the Austral spec link! Programming languages come and go but I find it deeply interesting when language designers lay out the rationale behind possibly outlandish decisions in their programming languages. Case in point, Larry Wall and Perl-y languages [0] [0] http://www.wall.org/~larry/natural.html http://www.wall.org/~larry/natural.html

kqr 3y ago

One of the things sigil allow you to do is overload other syntax. The example I usually bring up is the difference between @hash{a,b,c} which returns a list containing the values associated with keys a, b, and c; and on the other hand $hash{a,b,c} which returns the single item associated with the key constructed from concatenating a, b, and c (used to emulate a three-dimensional array.)

mihaic 3y ago

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.

ChoHag 3y ago

[dead]

stephc_int13 3y ago

I am in the "the less sigils the better" camp. Code clarity should be seen as higher priority than terseness or typing speed.

flumpcakes 3y ago

If the author is reading, 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.

nige123 3y ago

Sigils are just part of the picture. For Raku "twigils" (secondary sigils) are important too: https://raku-advent.blog/2022/12/02/day-2-less-variable-wattage-more-flow/ https://raku-advent.blog/2022/12/02/day-2-less-variable-watt...

p6steve 3y ago

I really like sigils for several reasons and I do miss them when in non sigil languages - imo raku made two big improvements over perl that is to avoid changing the sigil on accessing an item and to have an unsigilled option for people who don't like them https://rakujourney.wordpress.com/2022/12/24/on-sigils/ https://rakujourney.wordpress.com/2022/12/24/on-sigils/

luuuzeta 3y ago
>and to have an unsigilled option for people who don't like them Sigilled "variables" do lose many of the perks that sigils provide though, as codesections explains in the blog.