CRITICAL BUG: Where is... "repeat while/until"?

[DJuego]

Recently, it was added defaults to "if" and "while". The classic "if" has been preserved. However, the classic repeat while/until has disappeared! 😳 😊

DJuego

[QuirkyCort]

You mean this?

The "true" is a shadow block. It acts like a default, and is automatically replaced if you put anything on it. It saves the user a bunch of clicks if they just want a "while true" loop.

For the "if", I can't use a shadow block for the comparison (...cannot have a shadow block with non-shadow children), so I provided two versions.

[DJuego]

First; thank you so much for all the updates you are doing lately. They are really great! @QuirkyCort.

Second; I see. I was trying to remove the shadow block. I did not think to "overwrite" it. Indeed; the version we use the most is the endless loop with While True.

However, honestly, I'm not convinced that there is no "naked" version of While. For didactic reasons, I think it is important to separate the structure from the condition. A structure has a "header" and a "body". IMHO, a different concept (and separate) is the "condition". The student may come to the false conclusion that, by default, The while has the default condition "True".

I am not opposed to While True default, but I would leave the While structure naked, in its pristine form.

I use this amazing tool to introduce kids (and not so kids) to the basics of imperative programming. Solving challenges like WRO or FLL is for more advanced users. :-)

Thanks!

DJuego

P.S: It would be nice to have an advanced mode where these default structures are visible, in order to keep the palettes as clean and minimal as possible. It is more meaningful to select from an assortment of different structures, than from different configurations for the same structure.

[QuirkyCort]

Blockly allows a naked while, but silently changes it into a "while false" when generating code. Every other programming language I know considers a naked while to be syntactically incorrect. Allowing a naked while may create the false impression that a it is the same as a "while false", and I would think it better to set an explicit default that students can see and override.

I'm also considering adding a separate while with a condition block pre-inserted (...like what was done with the if). Depending on the level of the students, that is more common than a "while true", and can make drag-and-drop programming less of a pain.

So, right now these are the options...

while (naked)

• Separates control structures from conditions
• Syntactically incorrect on it's own
• Blockly silently adds a false, which may create the false impression that a naked while is syntactically correct

while <true>

• Saves some clicks
• Makes the syntax explicit with no hidden conditions

while <false>

• Make the hidden default that Blockly implements explicit
• Useless without modifications

while <0> = <0>

• Saves some clicks
• Condition block cannot be shadow, so it can be removed by the user to reveal a naked while

I personally favour having the second and last only, but am open to other opinions.

Having an advanced mode is something I have considered, but it's difficult to draw the line between what's considered a "basic" block and what's an "advanced" block. It won't make much sense if there is only a very marginal difference between the two modes.

[DJuego]

Thank you for your insight, @QuirkyCort Now I understand it much better.

Well. I hadn't used Blockly until I was introduced to Gears about eight months ago. And only now do I realize that Blockly had banished the notion of syntactically incorrect code. 😔 Indeed, the vast majority of the blocks you drag into the workspace are self-contained and syntactically correct.

I'm not sure that's the most "didactic" decision. Probably because of my old school education. Of course, for me, the expected behavior would be a syntax error. Which is just what happens with common programming languages based in text. Because, after all, text-based languages "allow" you to write syntactically incorrect code (even in advanced environments such as Visual Studio).

Probably my mistake has been to assume that with Blockly I was faithfully reproducing text-based programming. Including the existence of illegal intermediate states (syntactically incorrect).

Now I recognize my naivety. Although in my defense, I want to claim that other errors are recognized as such:
For instance; "TypeError: 'NoneType' does not support indexing on [...] "I imagine in those cases it was difficult to inject code stealthily. 😊

I suppose this design decision is congruent with the evolution of more sophisticated development environments. It is almost certain that, in the future, intelligent autocompletion (deep learning techniques or so) will always be forced, rendering syntax errors obsolete. Sooner or later they will disappear from textbooks as they are exotic errors

Undoubtedly it is the step prior to the auto-programming that will leave all programmers unemployed. It is fair. 😏

Now with this "new" reality (for me) in mind I would like to make a comment.

About while (naked), you say.

"Blockly silently adds a false, which may create the false impression that a naked while is syntactically correct"

The truth is that I had not noticed this implicit false. However, I immediately noticed the non-dissociation between While and True in the explicit while . For some reason I found it more irritating. I guess it has to do I learned long ago that in a naked while it is syntactically incorrect. And that idea so internalized in me has prevented me from realizing that others might come to wrong conclusions. Especially when the syntax error is camouflaged by fabricating an untruthful translation.

However, I would like the same criteria to be applied to the IF. After all "Blockly allows a naked if, but silently changes it into an "if false". I understand that "while true" usually makes sense and "if false" does not. But at least it would make explicit the code generation that occurs underneath. ("Makes the syntax explicit with no hidden conditions")

On the other hand, I admit that saving a few clicks does not add much value for me. I prefer not to save anything. :-D I think it is instructive for young learners. I'm not trying to get them to code fast, but to code well.

DJuego

[QuirkyCort]

I've also noticed that "if" comes with a hidden "false". As you say, "while true" is often useful, while an "if false" is entire useless, so adding the shadow "false" to the "if" block would make the hidden condition explicit, but serves no other purposes.

Let's see if anyone else have an opinion about this before committing to it either way.

[DJuego]

Well. It is also a matter of congruence and symmetry. 😉 An equally acceptable alternative is to keep the while (naked), because if (naked) coexists with a version of the if with default condition.

The same arguments of while (naked) can be applied:

if (naked):

• Separates control structures from conditions
• Syntactically incorrect on it's own
• Blockly silently adds a false, which may create the false impression that a naked while is syntactically correct

if < false >

• Saves some clicks
• Makes the syntax explicit with no hidden conditions
• It is weird . 😅

So if the only real reason to leave out the while (naked) is that it does not save clicks I would advocate keeping it, as it is done with the if (naked) because IMHO I think the advantage of separating structure and condition justifies it (at didactic level). After all its disadvantages ("Syntactically incorrect on it's own", "Blockly silently adds a false, which may create the false impression that a naked while is syntactically correct )" do not seem to have been solid enough for you to replace the if (naked) with if < false > (for now).

Of course I admit that another argument for completely replacing the while (naked) with the while is to keep the palette of blocks as small as possible.

That said I apologize for my overreaction to this topic. 😔 I think I can get used to your proposal in the current state. I am very grateful to you for Gears, and the latest changes you have made are wonderful. I just disagree with this one but now I think I'm ready to accept it. If no one else shares my opinion on this then your judgement must prevail.

DJuego

P.S: