hello scratch team i know of a workaround to the multiplacation operator its:

define multiply (number) by (amount)
repeat (amount)
set [multiply v] to (number)
end
say (multiply)

when green flag clicked
multiply () by ()

thats all see ya

Agreed. We also should remove Scratch, because it has a workaround: creating your own coding website.
Jokes aside, how would you even workaround

((0.3) * (0.7))

Hm?
The multiplication is a fundamental operation when it comes to maths, removing something just because it has a workaround isn't a good idea when there are lots of projects that use these blocks.

Edit: it has happened in the past that a removed block was replaced in every project with a workaround, but these were exceptional cases like the forever if block or the (abs ()) block. This, however, makes no real sense. Removing a block as important as this would really have more cons (a lot) than pros (probably 0).

Botcho_Otkho wrote:

Agreed. We also should remove Scratch, because it has a workaround: creating your own coding website.
Jokes aside, how would you even workaround

((0.3) * (0.7))

Hm?
The multiplication is a fundamental operation when it comes to maths, removing something just because it has a workaround isn't a good idea when there are lots of projects that use these blocks.

i meant make it not be availible to just plop down

coder_isaiyah11 wrote:

Botcho_Otkho wrote:

Agreed. We also should remove Scratch, because it has a workaround: creating your own coding website.
Jokes aside, how would you even workaround

((0.3) * (0.7))

Hm?
The multiplication is a fundamental operation when it comes to maths, removing something just because it has a workaround isn't a good idea when there are lots of projects that use these blocks.

i meant make it not be availible to just plop down

Would you clarify? What you wrote doesn't really make sense.

Again… tons of blocks have workarounds using custom blocks. Removing everything that has a workaround would just make Scratch needlessly confusing.
Edit: (Besides, how would I do decimals and negative numbers? I'm not sure Scratch knows how to repeat “negative three” times)

So, should we remove these blocks.

change x by ()
change y by ()

because they have a workaround.

Dragonlord767 wrote:

So, should we remove these blocks.

change x by ()
change y by ()

because they have a workaround.

Yeah!

set x to ((x position) + (something))
set y to ((y position) + (something))

Don't forget the workaround for “next costume!”

switch costume to ((costume #) + (1))

Also the workaround for “go to (x) (y).” It's better as

set x to (number)
set y to (number)

Point being, just because there's a workaround doesn't mean we should remove it. It'll just confuse everyone.

All right then.

Along the way, let's also remove these blocks:

move () steps // can be workarounded with trig and "go to (x) (y)"

turn cw () degrees // can be workarounded with "point in direction ()"

turn ccw () degrees // see above

point towards [ v] // can be workarounded with trig and the x/y positions of the other sprite

go to [ v] // can be workarounded with x/y positions of the other sprite

glide () secs to x: (0) y: (0) // can be workarounded with "repeat"

change x by () // can be workarounded with "go to (x) (y)"

set x to () // see above

change y by () // see above

set y to () // see above

if on edge, bounce // could probably be workarounded with "if" and a couple operators

say [] for (2) secs // can be workarounded with the other say block and "wait"

think [] for (2) secs // see above

hide // make an empty costume and use switch costume

show // switch to a nonempty costume

next costume // switch costume to (costume # + 1)

next backdrop // see above

change size by () // can be workarounded with "set size to ()"

I think you get the idea.

All of these blocks can be workarounded, some easier than others, but that doesn't mean that they shouldn't be in the editor. A lot of these blocks make things much more convenient or much more readable, and forcing people to rely on workarounds for them could make scripting needlessly confusing.

Also, I think it's worth pointing out that your workaround doesn't work. You're setting the variable to “number” a certain number of times, which means its final value will be “number”, not “number” * “amount”.

No support because it is a fundamental double operation. Or if you mean deleting floating point altogether (replacing with fixed point or something), again no support because it would break projects that rely on values larger than maximum or smaller than minimum in fixed point, or rely on Infinity, -Infinity or NaN. I would only support adding a new numerical type, but not removing the existing double type.

Actually, you can divide a number by the reciprocal value of the other multiplicator. But then you get zero division stuff, so no. I think that you can close this topic, noone will support it.

HTML-Fan wrote:

Actually, you can divide a number by the reciprocal value of the other multiplicator. But then you get zero division stuff, so no. I think that you can close this topic, noone will support it.

Dividing by Infinity is the same as multiplication by zero, dividing by -Infinity (1.0/-0.0) is the same as multiplication by -0, etc. More problematic are rounding errors because this formula may not give the rounded to nearest result floating point multiplication must have.

Okay, still, it's makes no sense. Scratch is for beginners. If I were a newbie and wouldn't have a multiplication block in a language, I would leave and search for another one.

if <everyone rejects all my suggestions> then
quit scratch
end

JK

coder_isaiyah11 wrote:

if <everyone rejects all my suggestions> then
quit scratch
end

JK

That's just how it is. 75% of my suggestions are not supported and the other 25% are forgotten. That's just how it is …
And really, this suggestion is way more foolish then my most foolish suggestion, the strange pointers.

Ok, some stuff:

1. Why would you want to remove an operation that is so basic and used in so much projects?
   
2. Your workaround only puts the result in a speech bubble. You can do this:
   

   say [Hello!] for ((5) * (2)) secs

   But not this (maybe in Snap!?):
   

   say [Hello!] for (multiply (5) with (2)::custom stack) secs

3. Your workaround doesn’t even work. Maybe you meant this block?:
   

   change [multiply v] by (number::custom)

It's just completely foolish, it makes no sense at all and you couldn't even replace the old * blocks with a workaround. To name just a few reasons why this suggestion is downright silly.

The Scratch Team has never deleted any block because of an easy workaround.

So, should we delete:

think [HI] for (2) secs

You could just do:

think [HI]
wait (2) secs
think []

Easy workaround. What about clones? Just make tons of sprites.

What about:

next costume

Try:

switch costume to ((costume #) + (1))

What about:

glide (1) secs to x: (0) y: (0)

Try:

(Sprite1)

go to x: (0) y: (0)
set [ghost v] effect to (99)

(Sprite2)

point towards [Sprite1 v]
repeat until <touching [sprite2 v]>
move (Calculate how much time it takes to get from your coordinates to Sprite1, and input the value here!) steps
end

You see, these are extremely easy workarounds. However, without those workarounds, it takes more effort than it could just take with a simple block. It's directed at beginners. So, I don't think that the multiplication operator should be deleted.

Super_Scratch_Bros20 wrote:

if on edge, bounce

is workaroundable by

if <touching [edge v] ?> then
turn ccw (180) degrees
end

That's not true. That would make the sprite go to the exact opposite direction instead of mirroring one axis, and there was a “beep” block in early versions, but deleted, most likely because you can just use the music extension or an MP3. But deleting such a basic math operation? Nooooooope!

How would you do this then?

when gf clicked
set [result v] to ((8)*((4)+(result))

It's not a question anymore. The suggestion is 1. totally foolish 2. downright silly 3. completely rejected by the community and it would 4. break old projects. Reported to be closed.