make the ask bock a reporter

Maximouse

PkmnQ wrote:
A better way to do this would be
set [foo v] to ask [What's your name?] and wait :: sensing

Not necessarily better – I think it's confusing, although C++ has something similar (the >> operator).

IceCreamTub

No support, too ambiguous and scratch is meant for younger people thus less complicated coding is involved

mybearworld

PkmnQ wrote:
[View post]
A better way to do this would be
set [foo v] to ask [What's your name?] and wait :: sensing

Okay, then also make

set [foo v] to (2) + (3) :: operators
set [foo v] to x position :: motion

See? That should be “workarounded” with

set [foo v] to ((2) + (3))
set [foo v] to (x position)

And, as well,

set [foo v] to (ask [What's your name?] and wait)

Last edited by mybearworld (June 26, 2021 20:11:06)

mybearworld

IceCreamTub wrote:
[View post]
No support, too ambiguous and scratch is meant for younger people thus less complicated coding is involved

Ambigious? Python and JS have this.

print(input("What's your name?"))

console.log(prompt("What's your name?"));

rdococ

Greg8128 wrote:
Scratch operates under the assumption that all reporter blocks have no side effects. (That is, it doesn't matter in what order two reporter blocks get called, or whether a reporter block gets called at all if its result doesn't matter).

An "ask and wait“ reporter would violate this principle. Suddenly, Scratch would have to standardize the order in which reporters are calculated, and whether the ”or“ and ”and" boolean blocks must always evaluate the right side. This would make it much harder to ensure backwards compatibility.

This! Scratch reporters are meant to be the things that perform calculations and return results, not produce visible changes on their own. Reporters that perform actions like command blocks do would just confuse everything.

While many programming languages have this, I don't think it's a good feature for Scratch.

PkmnQ

mybearworld wrote:
PkmnQ wrote:
[View post]
A better way to do this would be
set [foo v] to ask [What's your name?] and wait :: sensing
Okay, then also make
set [foo v] to (2) + (3) :: operators
set [foo v] to x position :: motion
See? That should be “workarounded” with
set [foo v] to ((2) + (3))
set [foo v] to (x position)
And, as well,
set [foo v] to (ask [What's your name?] and wait)

Fine I'll explain more why it's better. So this suggestion has the problem of being a reporter with side effects. And the ask and wait block has the problem of having a useless answer block. With the set to ask and wait block, both of those are solved.

Greg8128

mybearworld wrote:
PkmnQ wrote:
[View post]
A better way to do this would be
set [foo v] to ask [What's your name?] and wait :: sensing
Okay, then also make
set [foo v] to (2) + (3) :: operators
set [foo v] to x position :: motion
See? That should be “workarounded” with
set [foo v] to ((2) + (3))
set [foo v] to (x position)
And, as well,
set [foo v] to (ask [What's your name?] and wait)

I agree with pkmnq.

Scratch often changes how it processes reporter blocks. For example, in Scratch 2, the “and” block would skip evaluating the second argument if the first argument was false. Now, it always checks both arguments. This would create yet another way for the Scratch team to break backwards compatibility.

For example, see how this choice changes what the following block does:

set [baz v] to <<> and <(ask ["bar"] and wait ::sensing) = (quux)>>

Last edited by Greg8128 (June 27, 2021 01:45:57)

DarthVader4Life

I don't believe that there should be any change to the ask block at all. By now, everyone is used to it as it is, and there's no point in changing it anymore. Scratch is meant to introductory, and

ask [] and wait

seems more introductory than

(ask [] and wait :: reporter :: sensing)

mybearworld

PkmnQ wrote:
[View post]
mybearworld wrote:
PkmnQ wrote:
[View post]
A better way to do this would be
set [foo v] to ask [What's your name?] and wait :: sensing
Okay, then also make
set [foo v] to (2) + (3) :: operators
set [foo v] to x position :: motion
See? That should be “workarounded” with
set [foo v] to ((2) + (3))
set [foo v] to (x position)
And, as well,
set [foo v] to (ask [What's your name?] and wait)
Fine I'll explain more why it's better. So this suggestion has the problem of being a reporter with side effects. And the ask and wait block has the problem of having a useless answer block. With the set to ask and wait block, both of those are solved.

The entire point of why I made my (now merged) duplicate, was so you don't have to do

ask [What's your name?] and wait
set [name v] to (answer)
ask [How old are you?] and wait
set [age v] to (answer)
say (join [You are ] (join (answer) (join [and you are] (join (age) [years old.]))))

PkmnQ

mybearworld wrote:
PkmnQ wrote:
[View post]
mybearworld wrote:
PkmnQ wrote:
[View post]
A better way to do this would be
set [foo v] to ask [What's your name?] and wait :: sensing
Okay, then also make
set [foo v] to (2) + (3) :: operators
set [foo v] to x position :: motion
See? That should be “workarounded” with
set [foo v] to ((2) + (3))
set [foo v] to (x position)
And, as well,
set [foo v] to (ask [What's your name?] and wait)
Fine I'll explain more why it's better. So this suggestion has the problem of being a reporter with side effects. And the ask and wait block has the problem of having a useless answer block. With the set to ask and wait block, both of those are solved.
The entire point of why I made my (now merged) duplicate, was so you don't have to do
ask [What's your name?] and wait
set [name v] to (answer)
ask [How old are you?] and wait
set [age v] to (answer)
say (join [You are ] (join (answer) (join [and you are] (join (age) [years old.]))))

I know, but it has none of the problems of that.

gosoccerboy5

Offtopic, but this problem would be essentially removed if we had custom reporters..

Maximouse

gosoccerboy5 wrote:
Offtopic, but this problem would be essentially removed if we had custom reporters..

I don't think suggesting an alternative solution is off topic.

EatNYeet

A bit of a situation…

(ask (ask [] and wait::sensing)::sensing)

samq64

EatNYeet wrote:
A bit of a situation…
(ask (ask [] and wait::sensing)::sensing)

Not a problem. (although I don't know who would do that.) It would just ask a blank string and then ask what you entered the first time and then report the second answer.

Codingfairy07

mybearworld wrote:
IceCreamTub wrote:
[View post]
No support, too ambiguous and scratch is meant for younger people thus less complicated coding is involved
Ambigious? Python and JS have this.
print(input("What's your name?"))
console.log(prompt("What's your name?"));

Well, we want to keep Scratch simple, and this isn't that simple, and goes against the Design goals,
which say Scratch should be easy to start out with. The ask reporter isn't simple, this could be easily workarounded (is that even a word), and I like the ask block the way it is, so no support!

samq64

Codingfairy07 wrote:
mybearworld wrote:
IceCreamTub wrote:
[View post]
No support, too ambiguous and scratch is meant for younger people thus less complicated coding is involved
Ambigious? Python and JS have this.
print(input("What's your name?"))
console.log(prompt("What's your name?"));
Well, we want to keep Scratch simple, and this isn't that simple, and goes against the Design goals,
which say Scratch should be easy to start out with. The ask reporter isn't simple, this could be easily workarounded (is that even a word), and I like the ask block the way it is, so no support!

Well, I mean it's removing a block from the editor, which apparently improves the user experience.

The Developers wrote:
Despite the common drive to add more features to software products, we have found that reducing the number of features often improves the user experience. What initially seems like a constraint or limitation can foster new forms of creativity.

(source)

Last edited by samq64 (June 29, 2021 22:44:39)

the2000

samq64 wrote:
Well, I mean it's removing a block from the editor, which apparently improves the user experience.

The Developers wrote:
Despite the common drive to add more features to software products, we have found that reducing the number of features often improves the user experience. What initially seems like a constraint or limitation can foster new forms of creativity.
(source)

That doesn't (or at least, shouldn't) mean “we should have as few blocks as possible”, it just means that Scratch should have very few distinct features. The more features (not blocks!) that the software has, the longer it takes for a new user to learn.

mybearworld

Codingfairy07 wrote:
[View post]
mybearworld wrote:
IceCreamTub wrote:
[View post]
No support, too ambiguous and scratch is meant for younger people thus less complicated coding is involved
Ambigious? Python and JS have this.
print(input("What's your name?"))
console.log(prompt("What's your name?"));
Well, we want to keep Scratch simple, and this isn't that simple, and goes against the Design goals,
which say Scratch should be easy to start out with. The ask reporter isn't simple, this could be easily workarounded (is that even a word), and I like the ask block the way it is, so no support!

Yes, it is simple. It asks a question, and returns an answer. If that's not simple, then remove the current ask block.

k7e

EatNYeet wrote:
A bit of a situation…
(ask (ask [] and wait::sensing)::sensing)

It asks the one in the middle, and then asks the answer.

DJUmbreon2

the2000 wrote:
I don't like this idea because it creates the idea of a reporter block which can pause the script that it's running in. Reporters are supposed to give instant output, not pause like this block does.

so you’re telling me it defeats the purpose of reporters

Discuss Scratch