CHANGE _ BY _ allows drop of a variable blob onto the first input slot.

[brianharvey]

The drop should be disallowed, as for SET _ TO _.

[jmoenig]

that is, in fact, a new feature introduced in v11 under the name "hyper mutation": https://github.com/jmoenig/Snap/blob/master/HISTORY.md?plain=1#L648
(and it's actually super cool!)

[brianharvey]

Hmm, the HISTORY file isn't telling me what it's supposed to do. But long ago we decided, correctly I still think, not to allow dropping a variable on the menu because what it did isn't what users expected it to do. The feature, whatever it is, may indeed be super cool, but I don't believe it should overload the CHANGE block! As is often the case lately, I think your mania about not adding new blocks leads to undiscoverability, starting with the LENGTH block, but here's another one.

:(

[jmoenig]

Oh, there's no "overloading" here, it's doing exactly what you'd expect it to do:

This has been central to all our AI / perceptrons / neural networks stuff, and I've explained about it at length in all my talks since last year.

[brianharvey]

[bangs head against wall]

This does not do what the user expects! Instead it gives an incomprehensible (as shown by actual user feedback over several decades) error message.

I repeat, the problem is an unnecessary overloading of the CHANGE block, whose domain is variables, not data structures. (That's why it's orange and not red.)

It would be weird, but harmless, if you made it so any expression except a variable blob was allowed in that slot. But the current notation isn't harmless; it's extremely user-unfriendly. (Not every Snap! user is watching you do an AI demo. Some of them are trying to do the same things they were trying to do, with greater success, two years ago.)

[jmoenig]

this ship has sailed. We officially first introduced hypermutation 2 years ago with v10 without any protest or issue report whatsoever. Even before that we've discussed the ramifications (mutation vs. functional paradigm) extensively on many occasions, including at 2 Faber/Olot outings in which I implored my CS professor friends to clarify and explain these mathematical (linear algebra) issues I had in understanding perceptrons and neural networks - and which y'all just shrugged away stating you're no "AI experts" - . Since we've officially introduced this feature there have exactly been zero reports of any issue or problem with it. That error message is not "incomprehensible" at all, but perfectly clear. This is the first time anybody complains about it. But ... this has since been introduced not just in a bunch of demos given by me but also in a lot of teaching materials we've written and published about neural networks, including an all new online course. It's a central component of explaining how neural networks converge.

[hansdejongehv]

Actually, I encountered the same issue last Sunday in TurtleStitch and I did on Monday file an issue on TurtleStitch for it. Then I got the feedback what the issue was. The child was confused, the helper could not figure it out and then I saw that I had to use the drop down box. I reported the issue and only then I learned from Andrea how it worked. So I am afraid that for users it is not clear. Also because it only works for "change", not for "set".

[jmoenig]

Hi, Hans! yep, I can see how this can be an issue when somebody first encounters it. But you already found out that if you use the dropdown the block does what the child (and the helper) expected, and that it's the same method that is also used (and required) in the SET block. As I've pointed out above, CHANGE is also used to increment scores of values at once. This is a - fairly - new feature for enabling linear algebra.

[hansdejongehv]

Hmm, well it took quite a while and 3 people to find it out. And after I found out I considered it a bug until I now understand the intent. Anyway, I would prefer it to be different, but I will live with it.

[brianharvey]

I implored my CS professor friends to clarify and explain these mathematical (linear algebra) issues I had in understanding perceptrons...

Sorry, I refuse to feel guilty about this. You were asking about mathematics, not about the implications for users of overloading the CHANGE block. I have no complaint at all about your work on AI, which is wonderful! My complaint is entirely about syntax; you should have made a red (Lists) block, even if you also called it CHANGE, with a List-type slot as its first input.

We officially first introduced hypermutation 2 years ago with v10 without any protest or issue report whatsoever.

Okay, this I do feel guilty about. I've fallen shockingly behind on keeping track of new Snap! features. I would never have let you overload CHANGE this way if I'd known you were doing it.

Even before that we've discussed the ramifications (mutation vs. functional paradigm) extensively on many occasions...

[Bangs head against wall again]

You are talking as if I were complaining about the non-FP semantics of your AI programming. I'm not! Once again, I'm delighted with your work on AI. I'm making a very narrow complaint about syntax. If there's a big principle motivating me, it's the one about not casually overturning the UI decisions we made with great pain and great care back in BYOB days.

That error message is not "incomprehensible" at all, but perfectly clear. This is the first time anybody complains about it.

Oh, Jens. I'm supposed to be the one with the bad memory. Don't you remember that in the early days of BYOB we allowed dropping variables onto that slot, and everyone expected it to mean something other than what it did mean, and we resolved the issue by disallowing dropping reporters on that input slot?

Of course the message is perfectly clear to you! And it's even perfectly clear to me, since I grew up programming in assembly language and so I know all about indirect addressing. But we have decades of experience showing that it's not clear to users. And in a way, it's a good thing that users expect it to work the way they do; it means they trust the general idea that you can drop input expressions anywhere and that that's the primary way to express inputs. And it's not as if we don't have any other special forms in the language, in which we make users' naive expectations work by, behind the scenes, violating the way they think things work.

[jmoenig]

Oh, I'm not blaming you or anyone, I'm just pointing out the several occasions over a long time stretch at which I've repeatedly brought this up.

Again, I was and we were aware that there would be error messages after this change, but decided we're okay with them, because they do make sense when you consider the order of operations. Of course there is always the possibility to introduce yet another primitive that does something very special in a very narrowly defined domain. But there are downsides to that as well, especially in a visual, palette- / menu- centric UI. This is - we agree - one of Snap's major design challenges.

So, yeah, I'm sorry Hans has had some difficulties with this in Turtlestitch in his class. But I'm also fine with it, because they were able to discover the solution themselves. There is no question that enabling blocks to extend their semantics to a wider range of applications makes their meaning less clear and can lead to confusion. However, - and this is where we disagree, I guess - this also has the potential to evoke enormous delight and even incredulous enthusiasm in both learners and educators once they realize that a particular idea has a much, much wider, almost universal applicability.

Let's keep thinking about this. Perhaps a solution could be to indeed make CHANGE a special form. I've considered this but didn't like it at the time. Sometimes stumbling across something that at first seems like a (stupid) bug can end up opening your eyes and expanding your mind.

I'm sure Hans will appreciate once he realizes the sheer beauty of what CHANGE can do!

[Mark4SISB]

Suggestion: Update the CHANGE BY help text so people like Hans will understand how it works and why it works that way if they decide to look at the help text.