You could also argue that we could delete the forever block, as its function works with
[blocks]<repeat until><( 0 <=> 1 )>[/blocks]
.
I do support, though.
Offline
jackrulez wrote:
You could also argue that we could delete the forever block, as its function works with
[blocks]<repeat until><( 0 <=> 1 )>[/blocks]
.
I do support, though.
That's harder though, and involves switching between control and operators sections, while forever and if are both in control.
Offline
I also agree on removing forever if.
My main argument is though, that if you're teaching computer programming having 'forever' and 'forever if' just makes no sense, it's not how computers work.
forever if equals an if block in a forever block, and the latter is a lot clearer as to what it does. Also, with scratch's trial-and-error mentality in mind, an if block inside a forever block allows you to play around and add some blocks below the if, while a 'forever if' requires you to rearrange all your scripts in order to make an addition.
The ST has always tried to add as less blocks as possible to 'make it easy for new/young people to understand'. 'forever if' is just useless and confusing imho.
Offline
I support this completely. I doubt any new scratcher has understood this block from the start, and it is extremely easy to replace, even from the same tab. Once a friend of mine was mis-using it in a school project, and I fixed it for him the day before it was due. So close! If the online players will get confused by this, which i doubt they will, make an executable to filter them out or something like that.
The forever if block is an extremely confusing block, and must be removed!!!
Offline
The forever if block is useful though
Offline
greenflash wrote:
Jonathanpb wrote:
Good idea! I always use the forever block and if block, actually.
You know, why have the forever if when you can use the forever and if?Also, you can't use multiple forever if blocks in a script, but you can use as many ifs as you want in your forever block:
[blocks]
<forever if>
<end>
<forever>
<if>
<end>
<if>
<end>
<if>
<end>
<end>
[/blocks]
I never use the forever if block because of this inconveinence!
Exactly! I support
Offline
Enzo1997 wrote:
Worthless Blocks are ever so easy to find...
Motion:
Turn 15 Degrees ()
Turn 15 Degrees () I agree.
Go To [] I agree-- use "goto x (x of sprite) y (y of sprite)".
Change x by () I agree-- use "set x to (x) + [amount]".
Change y by () I agree. See above.
Set x to () I agree. Use "goto x [amount] y (y position)".
Set y to () I agree. See above.
If on edge bounce I agree as long as the [bounce] block exists.
Looks:
Next Costume Again, I agree. Use "switch to costume (costume #) + 1".
Change [] effect by () I disagree.
Change size by () I agree. Use "set size to (size) + [amount]".
Sound:
Change Volume by () I agree. Just use different notes.
Change Tempo by () I agree. See above.
Pen:
None I agree. All pen blocks are useful.
Control:
Repeat () I disagree. You would need variables to replicate the block.
Forever if <> I agree.
If <> I agree, as long as if else still exists.
Wait Until <> I agree. Use an empty-mouthed repeat until block.
Stop Script I agree.
Stop All I disagree.
Sensing:
Distance to [] I disagree.
[] of [] I disagree.
My opinions in italics.
Offline
rdococ wrote:
Enzo1997 wrote:
Worthless Blocks are ever so easy to find...
Motion:
Turn 15 Degrees ()
Turn 15 Degrees () I agree.
Go To [] I agree-- use "goto x (x of sprite) y (y of sprite)".
Change x by () I agree-- use "set x to (x) + [amount]".
Change y by () I agree. See above.
Set x to () I agree. Use "goto x [amount] y (y position)".
Set y to () I agree. See above.
If on edge bounce I agree as long as the [bounce] block exists.
Looks:
Next Costume Again, I agree. Use "switch to costume (costume #) + 1".
Change [] effect by () I disagree.
Change size by () I agree. Use "set size to (size) + [amount]".
Sound:
Change Volume by () I agree. Just use different notes.
Change Tempo by () I agree. See above.
Pen:
None I agree. All pen blocks are useful.
Control:
Repeat () I disagree. You would need variables to replicate the block.
Forever if <> I agree.
If <> I agree, as long as if else still exists.
Wait Until <> I agree. Use an empty-mouthed repeat until block.
Stop Script I agree.
Stop All I disagree.
Sensing:
Distance to [] I disagree.
[] of [] I disagree.My opinions in italics.
What about the beginners? They wouldn't know that stuff at first.
Offline
Forever if is , useless, confusing, blah blah blah...
Just take a look...
<forever>
<if><touching color>
<glide( )secs to x )y
<end>
<if><key[ right arrow ]pressed?>
<change{ X }by( 3
<end>
<end>
You can put as many ifs if you use if in forever
Not like wimpy forever if
Look at this
<forever>
<point towards(apple
<move( 10 )steps>
<if on edge, bounce>
<if><touching[ apple
<say[ I won! ]for( 2 )secs><if>
<stop all>
<end>
<end>
Offline
rdococ wrote:
Enzo1997 wrote:
If <> I agree, as long as if else still exists.
Wait Until <> I agree. Use an empty-mouthed repeat until block.
Stop Script I agree.
You agree? "stop script" is NOT REPLACEABLE, unless you have this, and even then is MUCH more easier to use; excluding the if block is just a joke. Wait until is also useful, but replaceable.
Also the motion block I think are good, and what's bounce block?
Offline
roijac wrote:
rdococ wrote:
Enzo1997 wrote:
If <> I agree, as long as if else still exists.
Wait Until <> I agree. Use an empty-mouthed repeat until block.
Stop Script I agree.You agree? "stop script" is NOT REPLACEABLE, unless you have this, and even then is MUCH more easier to use; excluding the if block is just a joke. Wait until is also useful, but replaceable.
Also the motion block I think are good, and what's bounce block?
Thank you for liking my suggestion.
Offline
Shadowed1 wrote:
lucari0 wrote:
I couldn't disagrree more. Almost all of my projects use the forever block once or twice. Without that block, I'd have to delete all of my stuff, and I have alot. I mean, seriously, whats so bad about it? It's helpful, to like, half the projects on the site! lets keep this in!
<forever>
<end>It's not the forever block, that would be suicidal. No, this is the useless forever if block that's the same as a forever and an if inside it. I don't know what kind of purpose the forever if block plays
<forever if> is 1% epic
Offline
Although the forever-if block isn't really needed, it will cause seriously compatibility problems. This block is being more used than the + operator! I know that sounds funny, but just look here, and you'll understand how common this block is.
Offline
roijac wrote:
Although the forever-if block isn't really needed, it will cause seriously compatibility problems. This block is being more used than the + operator! I know that sounds funny, but just look here, and you'll understand how common this block is.
We want it to be made obsolete but not , like the block.
Offline
I agree, in the next version of scratch, scratch 2.0 it should be deleted because you really don't need it because you can just use the if block instead of the forever if block because their the same thing and it will probably knock out some space used in the program so it's easier to download and will take less space in people's computers.
Offline
JSO wrote:
I also agree on removing forever if.
My main argument is though, that if you're teaching computer programming having 'forever' and 'forever if' just makes no sense, it's not how computers work.
forever if equals an if block in a forever block, ...
Few computer languages have the equivalent of "forever". The programming languages that I'm familiar with (outside of Scratch), use something like:
While (some test returns "true") Do:
[stuff]
[more stuff]
EndWhile
This is the "Forever If" block of Scratch, and it shows up in Pascal, LISP, VB, etc. You can certainly work around it, but I think there's a much better argument for getting rid of "forever" - which most 'serious' programmers simply wouldn't use. In "real" programming languages, 'Forever' is the equivalent of "lock up my computer". Scratch protects us from the "lockup", but more powerful (and less friendly) languages don't; I'd encourage new users to learn what it does, and to use it correctly, so they are ready to move on to more powerful languages.
Offline
EdnaC wrote:
JSO wrote:
I also agree on removing forever if.
My main argument is though, that if you're teaching computer programming having 'forever' and 'forever if' just makes no sense, it's not how computers work.
forever if equals an if block in a forever block, ...Few computer languages have the equivalent of "forever". The programming languages that I'm familiar with (outside of Scratch), use something like:
While (some test returns "true") Do:
[stuff]
[more stuff]
EndWhile
This is the "Forever If" block of Scratch, and it shows up in Pascal, LISP, VB, etc. You can certainly work around it, but I think there's a much better argument for getting rid of "forever" - which most 'serious' programmers simply wouldn't use. In "real" programming languages, 'Forever' is the equivalent of "lock up my computer". Scratch protects us from the "lockup", but more powerful (and less friendly) languages don't; I'd encourage new users to learn what it does, and to use it correctly, so they are ready to move on to more powerful languages.
no, that sounds more like a (when <> is true) hat block you can make.
Offline
In most languages (google "while loop") the structure is either called a "while" loop or a "do" loop, or a "repeat" loop. Some language require you to do something to get out (like Scratch's "forever" loop, others require a boolean to be true either at the beginning ("forever if") or end of the loop.
Scratch has both, and I think that's a good idea...
Offline
I strongly disagree. When I was a new Scratcher, I used that block in every one of my projects until I came across the idea of using the Forever and the If blocks seperately!
Offline
maxskywalker wrote:
I strongly disagree. When I was a new Scratcher, I used that block in every one of my projects until I came across the idea of using the Forever and the If blocks seperately!
I usually use forever if instead of forever; In the beginning stages, I put in "forever if (1=1)". If I later figure out that the script can be shut down in certain situations, I can easily replace the (1=1) with something else. i.e. (if BallInPlay = 1).
Offline
scimonster wrote:
Zangoose2 wrote:
Even though some of you might think that <forever if><end> is useless and <forever><wait until><end> and <forever><end><if><end> just do the same. But <forever if><end> will stop doing what it's doing even if it's in the middle of it whilst <forever><wait until><end> and <forever><if><end> will only check when it's finished... =O[/blocks]
Really? I thought it only checked when it reached the top.
That's what I mean!
Offline
Zangoose2 wrote:
scimonster wrote:
Zangoose2 wrote:
Even though some of you might think that <forever if><end> is useless and <forever><wait until><end> and <forever><end><if><end> just do the same. But <forever if><end> will stop doing what it's doing even if it's in the middle of it whilst <forever><wait until><end> and <forever><if><end> will only check when it's finished... =O[/blocks]
Really? I thought it only checked when it reached the top.
That's what I mean!
Oh, I misunderstood you.
Offline