Sigils are underappreciated (2022)

150 点作者 luuuzeta将近 2 年前

22 条评论

jerf将近 2 年前

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

评论 #36120120 未加载

评论 #36120047 未加载

评论 #36119898 未加载

评论 #36120451 未加载

评论 #36122960 未加载

评论 #36120200 未加载

评论 #36123532 未加载

评论 #36121229 未加载

评论 #36123238 未加载

评论 #36124867 未加载

评论 #36120183 未加载

xupybd将近 2 年前

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<pre><code> @foods = qw(burgers fries shakes); $length = @foods; print $length, "\n"; </code></pre> 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<pre><code> %author = ( 'name' => "Harsha", 'designation' => "Manager" ); $hash_ref = \%author; </code></pre> 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.

评论 #36120249 未加载

评论 #36121456 未加载

评论 #36121093 未加载

karmakaze将近 2 年前

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<pre><code> @ 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” </code></pre> 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.

whakim将近 2 年前

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.

评论 #36121293 未加载

评论 #36121742 未加载

评论 #36121507 未加载

评论 #36132807 未加载

throwaway290将近 2 年前

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

评论 #36120587 未加载

powera将近 2 年前

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.

评论 #36122018 未加载

crabmusket将近 2 年前

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] <a href="http://ada-auth.org/standards/12rat/html/Rat12-TOC.html" rel="nofollow">http://ada-auth.org/standards/12rat/html/Rat12-TOC.html</a>[2] <a href="https://austral-lang.org/spec/spec.html" rel="nofollow">https://austral-lang.org/spec/spec.html</a>[3] <a href="https://odin-lang.org/docs/faq/" rel="nofollow">https://odin-lang.org/docs/faq/</a>

评论 #36133023 未加载

nige123将近 2 年前

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

smeagull将近 2 年前

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.

评论 #36133106 未加载

mfranc42将近 2 年前

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

p6steve将近 2 年前

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 <a href="https://rakujourney.wordpress.com/2022/12/24/on-sigils/" rel="nofollow">https://rakujourney.wordpress.com/2022/12/24/on-sigils/</a>

评论 #36133038 未加载

mkoubaa将近 2 年前

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

评论 #36177215 未加载

js8将近 2 年前

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.

评论 #36120207 未加载

评论 #36127861 未加载

mihaic将近 2 年前

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.

stephc_int13将近 2 年前

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

flumpcakes将近 2 年前

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.

jakear将近 2 年前

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.

Arathorn将近 2 年前

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: <a href="https://spec.matrix.org/v1.7/appendices/#common-identifier-format" rel="nofollow">https://spec.matrix.org/v1.7/appendices/#common-identifier-f...</a>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.

__MatrixMan__将近 2 年前

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

评论 #36133080 未加载

kqr将近 2 年前

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

AtlasBarfed将近 2 年前

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

评论 #36121087 未加载

emmelaich将近 2 年前

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