Skip to content

Instantly share code, notes, and snippets.

@MattOates
Last active July 21, 2018 03:07
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save MattOates/3bb818947552ed3917eb3739fdd02c12 to your computer and use it in GitHub Desktop.
Save MattOates/3bb818947552ed3917eb3739fdd02c12 to your computer and use it in GitHub Desktop.
1) every time you don't use sigils you are hogging namespace for something thats not variables. Something close to keywords like
"from" and "to" is a bad plan. I've seen several people including myself use "from $i to $j by $inc" as their own range/list constructing
syntax. I have no idea if Rakudo is smart enough to negotiate sigiless variables and keywords at the same time, Id almost hope its not!
2) to some extent it doesn't matter if the OP finds it easier to read or if you do, almost the entirety of code you will come
across will not use that convention. So learning that way to start out with is only going to cause pain working with others. Just wanting
to write a debug statement for that whats the simple plan? say "from {from} to {to}" not so clean given the norm for the language... You're
changing *semantics* for the sake of visual aesthetic not readability. Your intent is less clear given the language, its less readable but
perhaps prettier.
3) friendlier for the OP to learn a language which isn't Java that has a load of concepts you need to learn, with this not being one
relevant to the question asked at all?
4) the sigils are always significant they signify the thing is a variable (possibly scalar in nature, at least in usage with functions).
What's the sigilless syntax for attributes inside methods? Serious question, is there one? I have no idea... and I've been playing in
Perl 6 for 8 years! Either way I shudder to think what happens to someone learning as if you dont need to worry about sigils when its
unavoidably the way stuff works in the language.
5) The appeal but also the *weakness* of Perl 6 is that people have the ability to do anything, but this doesn't mean its a good idea to do
anything. There's more than one way to do it, but not all of them are equally maintainable or friendly to other developers. You could
use sigilless emojii for all your variable names if you wanted. I personally would never wish to work with you on a project if that
was something you thought was a good idea. But TIMTOWDI etc. though personally I am much more up for expressivity of Perl with the
Python mantra of one obvious way to do it. I'd extend that to one obvious way to do it given flavour of semantics you're using like
OO, functional etc. I'd say Perl 6 goes out of its way to be that consistent and cohesive. The only sigilless things I can think of
are stuff like 'tau' or 'pi' i.e. constants, things youd want to stand out a bit and things you dont want anyone to imagine can be
variable. Thats why the feature is in the language in the core at least.
@raiph
Copy link

raiph commented Jul 21, 2018

Thanks for writing this up.

I agree with the gist (sic) of your comments but not yet the notion they are the right way to see things and mine are wrong. The following comments are for closure/balance and to feed my mind with some tentative conclusions I can sleep on.

  1. every time you don't use sigils you are hogging namespace for something thats not variables.

Sure. And that's significant.

But every time I do use a sigil I've added to the symbol load of code. If it gets too extreme it can become difficult to read for me, especially when returning to P6 code after a while away from symbol heavy code.

The suggestion that I and those like me just need to go use another language is highly inappropriate. If symbol density was not an issue, we'd all be using J all the time. It's all about balance and working cooperatively and with mutual respect and minimal "my-way-or-the-hiway" thinking to maintain code that's readable by those who have to read the code.

Something close to keywords like "from" and "to" is a bad plan. I've seen several people including myself use "from $i to $j by $inc" as their own range/list constructing syntax.

Good point. Is that in P6 with from, to and by subs?

  1. to some extent it doesn't matter if the OP finds it easier to read or if you do, almost the entirety of code you will come
    across will not use that convention.

I've adopted the habit of using constant to define constants without sigils and I've seen a good number of other folk do the same.

There's plenty of slashing of parameters in the Rakudo codebase and in the wild. It's not that rare.

I think most folk learning P6 are going to encounter sigil free identifiers very early on.

  1. friendlier for the OP to learn a language which isn't Java that has a load of concepts you need to learn, with this not being one
    relevant to the question asked at all?

Yes. Why should they learn about sigils? How is that relevant to their question? Should I have written $buffer or @buffer? Should I have used = or :=? Why should I introduce all that complexity?

The OP used Java identifiers in their question and comments, specifically buffer, offset and mask. It seemed reasonable to assume they were familiar with Java identifiers and that other readers who later arrived at the question after typing [perl6] java as their search query would be too.

Answering it as I did allowed me to gently introduce "sigils" by saying I was "slashing" them. They don't have to know what "sigil" means. They don't have to know what "slashing" means.

(Btw I was aware of all these issues you've discussed in your SO comment and here and the things I'm saying. We had a similar discussion a year or two ago and I've reflected on it since and tested some theories out with some kids. All of this was part of what led me to think it was worth trying what I tried for the SO answer you commented on.)

  1. the sigils are always significant they signify the thing is a variable (possibly scalar in nature, at least in usage with functions).

If I use a sigil on an identifier whose value does not vary, and arbitrarily mix that with other identifiers whose values do vary, I've just thrown away the significance of a sigil as indicating a noun that varies. I consider sigils signaling variability to be highly valuable.

What's the sigilless syntax for attributes inside methods? Serious question, is there one? I have no idea... and I've been playing in
Perl 6 for 8 years!

It's has \bar; (NYI).

Either way I shudder to think what happens to someone learning as if you dont need to worry about sigils when its
unavoidably the way stuff works in the language.

Worry is antithetical to learning.

Sigils are not only avoidable in the first 5 minutes but, imo, should be avoided,

My sense is that if everyone, even children, are only ever exposed to tutorials that involve sigils right out of the gate, P6 will get significantly less adoption that it might otherwise have gotten.

I'd like to see 7 year olds learning P6 around the same time they get exposed to the likes of Python.

Introduced correctly, sigils are a powerful positive of P6. But I do not believe symbol dense code is an instantaneous hit for most people. 15 minutes into the learning process? Sure, introduce sigils. Maybe after 5. But I think it's important to allow for folk like me -- perhaps the vast majority -- who find python's lack of sigils attractive at first glance even if we also find we prefer sigils once we get used to them at our own pace when not used too dogmatically and densely.

  1. The appeal but also the weakness of Perl 6 is that people have the ability to do anything, but this doesn't mean its a good idea to do
    anything.

Do you really think I was arguing that?!? I'm absolutely the last person to champion TIMTOWTDI for anything other than its positives!

My 5th point was essentially that I dislike line noise. I want my sigils to be significant. Otherwise they are a worse than boilerplate. P6 has taken a step away from P5 by making it a little saner to write identifiers for values that don't vary sigil-free. I like that.


The points you've made don't seem materially different than the ones you made a couple years ago or whenever it was we previously discussed this but that'sl fair enough. The exchange has allowed me to reflect further on the issues and I find that helpful. So, thanks for the exchange. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment