chrdagos wrote:

trfgbs wrote:

chrdagos wrote:

trfgbs wrote:

chrdagos wrote:

WindOctahedron wrote:

neeb132 wrote:

Doing

go to x: (pick random (-240) to (240)) y: (pick random (-180) to (180))

Is just about as annoying has having to do this

<<[] < []> or <[] = []>>

So by everyone's logic we should either add

<[] ≤ []>

or remove

go to [random position v]

Actually,

<not <[] > []>

works, too.

is that blockspam I see?

No. We are just showing workarounds.

I meant the

<not <[] > []>>

part.

Yea, that's showing a workaround too.

<not <[] > []>>

is a workaround for

<[] < []>

which isn't part of the topic

neeb132 wrote:

Doing

go to x: (pick random (-240) to (240)) y: (pick random (-180) to (180))

Is just about as annoying has having to do this

<<[] < []> or <[] = []>>

So by everyone's logic we should either add

<[] ≤ []>

or remove

go to [random position v]

<<[] < []> or <[] = []>>

WindOctahedron wrote:

Actually,

<not <[] > []>

works, too.

trfgbs wrote:

chrdagos wrote:

trfgbs wrote:

chrdagos wrote:

trfgbs wrote:

chrdagos wrote:

WindOctahedron wrote:

neeb132 wrote:

Doing

go to x: (pick random (-240) to (240)) y: (pick random (-180) to (180))

Is just about as annoying has having to do this

<<[] < []> or <[] = []>>

So by everyone's logic we should either add

<[] ≤ []>

or remove

go to [random position v]

Actually,

<not <[] > []>

works, too.

is that blockspam I see?

No. We are just showing workarounds.

I meant the

<not <[] > []>>

part.

Yea, that's showing a workaround too.

<not <[] > []>>

is a workaround for

<[] < []>

which isn't part of the topic

Ahem,

neeb132 wrote:

Doing

go to x: (pick random (-240) to (240)) y: (pick random (-180) to (180))

Is just about as annoying has having to do this

<<[] < []> or <[] = []>>

So by everyone's logic we should either add

<[] ≤ []>

or remove

go to [random position v]

And then another workaround for

<<[] < []> or <[] = []>>

Is

WindOctahedron wrote:

Actually,

<not <[] > []>

works, too.

DarthVader4Life wrote:

ok, then by that logic we should remove a lot of blocks.

like

forever

end

and

turn ccw () degrees

and

next backdrop

and

when [ v] key pressed

move () steps
say [] for () secs
think [] for (2) secs
show
hide
clear graphic effects

change size by ()

Za-Chary wrote:

neeb132 wrote:

trfgbs wrote:

I don't want to remove the “Go to random position” block, first, because it is my favorite block, second, because you don't know the whole span of the screen so you CAN'T do "

go to x: (pick random (-240) to (240)) y: (pick random (-180) to (180))

No, that block is a perfect workaround as far as I know

I'll have to test it out, but I'm pretty sure that is not a perfect workaround, depending on how large your sprite is.

if (targetName === '_random_') {
    const stageWidth = this.runtime.constructor.STAGE_WIDTH;
    const stageHeight = this.runtime.constructor.STAGE_HEIGHT;
    targetX = Math.round(stageWidth * (Math.random() - 0.5));
    targetY = Math.round(stageHeight * (Math.random() - 0.5));
}

JRR078s wrote:

DarthVader4Life wrote:

ok, then by that logic we should remove a lot of blocks.

like

forever

end

and

turn ccw () degrees

and

next backdrop

and

when [ v] key pressed

Also, by that logic:

move () steps
say [] for () secs
think [] for (2) secs
show
hide
clear graphic effects

and

change size by ()

Just to name a few.

mica43683 wrote:

Uhh… None of those have workarounds…

repeat ((something)/(0))
end

turn cw ((-1)*(something)) degrees

switch backdrop to ((backdrop number)+(1))

forever
if <key [ v] pressed?> then
end
end

go to x: ((x position) + (([sin v] of (direction))*(10))) y: ((y position) + (([cos v] of (direction))*(10)))

say [lalala] // (same with think)
wait () secs
say []

set [ghost v] effect to () // 100 to show, 0 to hide

(just set every graphic effect to 0)

set size to ((size)+(something))

WindOctahedron wrote:

mica43683 wrote:

Uhh… None of those have workarounds…

They all do:

repeat ((something)/(0))
end

turn cw ((-1)*(something)) degrees

switch backdrop to ((backdrop number)+(1))

forever
if <key [ v] pressed?> then
end
end

go to x: ((x position) + (([sin v] of (direction))*(10))) y: ((y position) + (([cos v] of (direction))*(10)))

say [lalala] // (same with think)
wait () secs
say []

set [ghost v] effect to () // 100 to show, 0 to hide

(just set every graphic effect to 0)

set size to ((size)+(something))

go to [ random position v]

is this topic about why the

go to [ random position v]

should be removed or is this a topic that people give workarounds to various blocks?
just wondering…

BearSlothCoding wrote:

Everything here is a valid point. This block should not be removed.

is this topic about why the

go to [ random position v]

should be removed or is this a topic that people give workarounds to various blocks?
just wondering…

It's about why that block should be removed.

chrdagos wrote:

BearSlothCoding wrote:

Everything here is a valid point. This block should not be removed.

is this topic about why the

go to [ random position v]

should be removed or is this a topic that people give workarounds to various blocks?
just wondering…

It's about why that block should be removed.

o.k, because people are now talking about block workarounds…

DarthVader4Life wrote:

chrdagos wrote:

BearSlothCoding wrote:

Everything here is a valid point. This block should not be removed.

is this topic about why the

go to [ random position v]

should be removed or is this a topic that people give workarounds to various blocks?
just wondering…

It's about why that block should be removed.

o.k, because people are now talking about block workarounds…

no, we're talking about the logic of why it should be removed. because by the logic of “It has a workaround” then we should get rid of a lot of blocks.

forever if <> {

} :: control

chrdagos wrote:

ooooOOOOOOOOOooooooooooHHHHHHHHH!!!!!!
but then why was the

forever if <> {

} :: control

removed?

if <> then
forever

end
end

LegoManiac04 wrote:

chrdagos wrote:

ooooOOOOOOOOOooooooooooHHHHHHHHH!!!!!!
but then why was the

forever if <> {

} :: control

removed?

Because that has the simplest workaround:

if <> then
forever

end
end

hide

chrdagos wrote:

DarthVader4Life wrote:

no, we're talking about the logic of why it should be removed. because by the logic of “It has a workaround” then we should get rid of a lot of blocks.

ooooOOOOOOOOOooooooooooHHHHHHHHH!!!!!!
but then why was the

forever if <> {

} :: control

removed?

go to [random position v]

go to x: (pick random (-240) to (240)) y: (pick random (-180) to (180))

_nix wrote:

chrdagos wrote:

DarthVader4Life wrote:

no, we're talking about the logic of why it should be removed. because by the logic of “It has a workaround” then we should get rid of a lot of blocks.

ooooOOOOOOOOOooooooooooHHHHHHHHH!!!!!!
but then why was the

forever if <> {

} :: control

removed?

heres one reason to remove forever-if but not go to random position: forever if takes up a whole space in the block palette; random position is only an option in a context menu - so, it isnt as distracting and can be easily ignored. buuuuut that isnt an outstandingly strong point, since there are plenty of other blocks which could be altogether removed for fairly simple workarounds

heres a stronger reason imo: the “forever” and “if” blocks are both C-shaped control blocks. theyre pretty similar in function, appearance, and location in the block palette! so its a little silly to have two blocks that combine them. “forever if” means new scratchers dont have to learn that its possible to put an “if” block inside a “forever” – on the one hand, this means it is easier to make projects right out of the box, but on the other, they also arent getting exposed to the idea of nested “ifs” and loops, which is a very important programming concept.

that is an important idea behind implementing new blocks & deciding which ones to remove because they have easy workarounds! you always have to consider how it will affect the way the user learns to use scratch, because this programming language is primarily designed to be useful for teaching students who are relatively new to coding.

compare “forever if” to “go to (random)”. they both have workarounds that are pretty easy – so why was “forever if” was removed, and “go to (random)” later added? we need to think about how they affect the way the user learns coding! “forever if” makes the user miss out on a useful programming concept, as i described above – thats part of why it was removed. but does “go to (random)” keep a new scratcher from learning any new concepts? well, heres its workaround – these two scripts are the same:

go to [random position v]

go to x: (pick random (-240) to (240)) y: (pick random (-180) to (180))

there are three new concepts in the workaround. i wont go into too much detail, but they are: 1) putting reporter blocks in general into stack blocks, 2) using the “pick random” block, and 3) understanding the coordinate grid and the size of the stage. all of these need to be understood to use the workaround, so you could say it necessitates learning – but i wouldnt say it encourages that. discovering as many as three new concepts all at once can be overwhelming!

also, all three of these concepts are also taught through other, more specifically focused situations. 1) can be learnt many different ways, 2) is learnt by experimenting with the operator blocks naturally (i.e. without a specific goal in mind), and 3) is better introduced with the “change x” and “set x” blocks, or “mouse x”, etc.

now, lets look at the positives of having the “go to (random position)” block! once again, the important thing were considering is what a student can learn by using that block. i can think of two things: 1) it lets the user easily put together projects which involve that without having to learn those other concepts we talked about (which encourages them to feel that they are able to make interesting projects without having to learn as many unfamiliar concepts), and 2) it can actually encourage learning how the coordinate grid works, because it moves the sprite to any position on the screen – that position is reflected in the “x/y position” blocks as well as the fairly prominent coordinate readout in the sprite info pane. so, its pretty easy for a student to notice that, and start learning the size of the stage and how positive and negative coordinates work.

an extra important detail on that is that its encouraging, not necessitating, a student learn something new! it naturally presents new concepts, rather than requiring that they be understood in order to reach the desired effect in the first place.

so, those are my thoughts on why “go to random position” is a good block to keep in scratch, and “forever if” isnt. thinking about how blocks affect the way users learn is always an important thing in scratch, and you can apply this kind of thinking to pretty much every block and come to a better understanding of why it was added or removed! sorry for the long post…im just quite enthusiastic about this type of thing

chrdagos wrote:

_nix wrote:

chrdagos wrote:

DarthVader4Life wrote:

no, we're talking about the logic of why it should be removed. because by the logic of “It has a workaround” then we should get rid of a lot of blocks.

ooooOOOOOOOOOooooooooooHHHHHHHHH!!!!!!
but then why was the

forever if <> {

} :: control

removed?

(snip)

so, those are my thoughts on why “go to random position” is a good block to keep in scratch, and “forever if” isnt. thinking about how blocks affect the way users learn is always an important thing in scratch, and you can apply this kind of thinking to pretty much every block and come to a better understanding of why it was added or removed! sorry for the long post…im just quite enthusiastic about this type of thing

that is O.K. long and detailed explanations are the gold standard of explanations

set [variable v] to [0]
delete all of [list2 v]::list
repeat until <(length of [list1 v]) = (length of [list2 v])>
change [variable v] by (1)
add (item (variable) of [list1 v]) to [list2 v]
end
set [variable v] to (0)
delete all of [list1 v]::list
repeat until <(length of [list1 v]) = (length of [list2 v])>
change [variable v] by (1)
add (item (variable) of [list1 v]) to [list2 v]
if <(item ((length of [list1 v]) + (1)) of [list1 v]) = (...::grey)> then
add [thing] to [list1 v]
end
end

insert [thing] at (...::grey) of [list1 v]

go to [ random position v]

move () steps
turn ccw () degrees
set x to ()
change x by ()
change y by ()
set y to ()
say [] for (2) secs
think [] for (2) secs
next costume
switch backdrop to [ v] and wait
next backdrop
change [ v] effect by (25)
clear graphic effects
change size by ()
when [ v] key pressed
forever

end

JRR078s wrote:

To summarize this entire topic: The

go to [ random position v]

is requested to be removed because it has a workaround, but by using that logic, a plethora of blocks should be removed, or never added. Therefore, there is no point of removing blocks. Besides, most any workaround will probably take up more space in a scratch project's 50 MB limit than a single block.
Some examples of workaround blocks are:

move () steps
turn ccw () degrees
set x to ()
change x by ()
change y by ()
set y to ()
say [] for (2) secs
think [] for (2) secs
next costume
switch backdrop to [ v] and wait
next backdrop
change [ v] effect by (25)
clear graphic effects
change size by ()
when [ v] key pressed
forever

end

I can see the logic of workarounds, but that's not the main purpose of Scratch, considering the age group for Scratch.

chrdagos wrote:

JRR078s wrote:

-snip-

o.k., but…
does that mean that this topic should be closed?