I was wrong about the semantics of Raku’s sigils. What does that mean for their power? And what can the difference teach us about language design more broadly?
Sigils have a bit of a bad reputation. According to their detractors, sigils are “just a way of encoding type information” in variable names – basically a glorified version of apps Hungarian notation (which isn’t even the good kind of Hungarian notation). Maybe sigils served a purpose in the bad old days, but now we have fancy IDEs and editors can give us all the type information we might want, and these modern tools have made sigils obsolete.
Or so they say. But I disagree – as do many of the hackers whose perspectives and insights I value most.
So my goal in this post is to convince you that sigils are a powerful tool for writing clear, expressive code. In fact, I’ll go further: Sigils are a powerful tool for clear communication in general – that they’re useful for programming is just an application of the more general rule.
Proposed on 27 August 2000, frozen on 20 September 2000, which was a generalization of RFC 26: Named operators versus functions proposed on 4 August 2000, frozen on 28 August 2000, also by Johan Vromans. Johan’s proposal was to completely obliterate the difference between built-in functions, such as abs, and functions defined by the user. In Perl, abs can beContinue reading “RFC 168, by Johan Vromans: Built-in functions should be functions”