Live data from Hacker News

Sigils are underappreciated (2022)

raku-advent.blog

91–97 of 97 posts

Re: Sigils are underappreciated (2022)

#91

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.

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

Re: Sigils are underappreciated (2022)

#92

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

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

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.

Re: Sigils are underappreciated (2022)

#93

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.

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

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.

Re: Sigils are underappreciated (2022)

#94
post #85

Earlier quoted context omitted.

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.

($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] mi…

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.

Re: Sigils are underappreciated (2022)

#95
post #31

Earlier quoted context omitted.

Fair point re: package management - but Python does support single-line conditionals, and reasonably robust type-checking with mypy.

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!

Glad I could help :)

Re: Sigils are underappreciated (2022)

#96
post #3

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, rath…

> 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 increa…

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

Re: Sigils are underappreciated (2022)

#97
post #11

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

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.
Post reply on HN