Sprite names are case sensitive

[ToonTalk]

Very unexpected given the way the rest of Snap! works.

[jmoenig]

Identifiers for variables, attributes and names are all case sensitive in Snap! and always have been. Personally I think not being case sensitive is a serious misfeature that we've "inherited" from Scratch/LOGO, and that it's doing more harm to our high school / college student audience. Instead a "lowercase _" reporter would be much clearer and more in the line of actual real-life uses. But I'm assuming LOGO people might vehemently disagree ;-)

[ToonTalk]

I largely agree with you, though I have seen beginners confused because they didn't notice a case difference.

But I expected Snap! to be consistent about case sensitivity. I just spent an hour tracking down a bug due to ask, when passed a non-matching case name, just did nothing. Perhaps the following should signal an error?

[brianharvey]

To nobody's surprise, I very strongly disagree.

Upper case is a font decoration, like italics or underlining. In real life, if I write that I disagree with jens about this, I don't get a "no such person" error from the people with whom I'm conversing. And I certainly don't know two people, one named Jens and one named jens. And if I did, would jens turn into the other one when he's at the beginning of a sentence?

And, Jens, "a lowercase reporter" wouldn't help at all with the issue under discussion here, which isn't the behavior of the = predicate, but rather the parsing of identifiers.

The relevant thing about me, in this discussion, is not that I'm a Logo person but that I'm a Lisp person. As you know, since the beginning of time, going on 70 years now, "real" programmers have been making fun of Lisp for being so impractical, and they're still saying so, even though their favorite language, pretty much no matter what it is, has garbage collection, lambda, tail call elimination (supposing you use gcc), and inching toward macros. One of the things Lisp got right, in the early days, was case-insensitive identifiers. (When I was arguing about this in comp.lang.scheme after the hostile takeover in R6RS, everyone told me about ß as the reason you can't do case-insensitive comparison, but it turns out there's an official Unicode Consortium approved algorithm to convert any identifier to lowercase with a unique result suitable for comparisons. The key point is that you convert to uppercase and then to lower case (why is "uppercase" a word, but not "lowercase"? not counting computer programmers). Then there are details about how to do those conversions in different languages, of course.)

I have no idea why anyone thinks people learning to program are harmed by avoiding all the bugs that come from distinguishing foo and Foo and FOO. Not to mention fooBar and FooBar and foobar and foo_bar. No, I lied, I do know why. It's because f**g C decided to have case-sensitive identifiers because those guys at Bell Labs never used a real computer before they wrote Unix, and everyone since then has been repeating the same mistake as if "Thou shalt have case-sensitive identifiers" had been handed down by Moses. (Some other time I can explain how everyone not at Bell Labs knew about reader-writer synchronization, which you can look up in your Operating Systems textbook.) But what I truly don't understand is how someone who doesn't think teenagers are harmed by programming by dragging colorful blocks around a screen can boggle at semantically-correct identifiers.

[brianharvey]

P.S. But there is a relevant design mistake we inherited from Scratch, namely, "just doing nothing" in response to an error. (The Unix guys got that wrong, too, by the way, only they do nothing on success.) The ST think children's delicate egos will be shattered if they ever see an error message. But the result is that it's impossible to debug because you have no idea where to start. We've gotten better about this over time, but there are still things that report an empty string, or zero, or false, or an empty list (don't get me started...) instead of turning red and stopping.

[cycomachead]

Without wading into the discussion, for which I don't have strong feelings (I wish the world was case insensitive, but I kind of think the wrong side won and it's too hard to fight...)

But I do think Ken's frustrations could be strongly alleviated by better errors. (We should come up with some generic "Did you mean" function to append to error messages, but that's a separate deal......)

Michael Ball | michaelball.co Lecturer | UC Berkeley Computer Science Software Engineer | Gradescope https://www.gradescope.com/?utm_source=michael_ball m: (909) 993-3988 | CV https://www.michaelball.co/resume

On Mon, Oct 4, 2021 at 11:58 AM Brian Harvey @.***> wrote:

P.S. But there is a relevant design mistake we inherited from Scratch, namely, "just doing nothing" in response to an error. (The Unix guys got that wrong, too, by the way, only they do nothing on success.) The ST think children's delicate egos will be shattered if they ever see an error message. But the result is that it's impossible to debug because you have no idea where to start. We've gotten better about this over time, but there are still things that report an empty string, or zero, or false, or an empty list (don't get me started...) instead of turning red and stopping.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jmoenig/Snap/issues/2895#issuecomment-933764761, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALPU46VR6C5WA72VXZPIHLUFH2MJANCNFSM5FJSPOUQ .

[brianharvey]

+1 for "Did you mean."

I kind of think the wrong side won and it's too hard to fight...

No need to think of it as a fight. We index lists starting from one. Some other people index lists starting from zero. We're right (the 37th item should be item number 37); they save one machine instruction in index-to-pointer computations. More power to them, but we're gonna keep doing it right. We compute positions on the stage with (0,0) at the center and positive y upward. Some other people have (0,0) in the top left corner and positive y downward. Same deal; we're gonna keep doing it right. The same is true about case-insensitive symbols. Much of the rest of the world does it wrong, but we can do it right without starting a fight (my fight against R7RS notwithstanding).

[ToonTalk]

By coincidence, just this morning I was reading a paper that involved generating plausible but incorrect answers to questions such as "name one reason the original colonists came to America" and I puzzled over "to explore the us". It took me a few seconds to realise that it only generated lowercase (Chrome doesn't complain that it should be "lower case") text and it was "to explore the US". Not an example of "font decoration". Or consider the difference between AIDS and aids.

Despite this I am sympathetic with Brian's points. Especially given how often I've seen people stuck because of a case mismatch in their programs.

Interesting that Microsoft decided filenames should be case insensitive. And so are domain names (which is confusing if hosted on Unix since the rest of the URL is case sensitive). Gmail addresses are case insensitive and they ignore periods.