([capitalize v] (hello) :: operators) // Hello
([decapitalize v] (Hello) :: operators) // hello
([capitalize all v] (hello) :: operators) // HELLO

set [name v] to ([capitalize v] (answer) :: operators)

ProdigyZeta7 wrote:

Great idea! However, in under 2 minutes I was able to implement workarounds for all three blocks in my collection. And for that reason it isn't necessary to include a built-in block.

theonlygusti wrote:

ProdigyZeta7 wrote:

Great idea! However, in under 2 minutes I was able to implement workarounds for all three blocks in my collection. And for that reason it isn't necessary to include a built-in block.

So, just because a block has a workaround means it shouldn't be in Scratch?

By that logic, we could get rid of half of all the current Scratch blocks. Should we?
No, of course not.

Just because a block has a workaround doesn't make it useless.

([Lowercase v] of ([BANANA]))

when [I post this v] key pressed

say (Siggy)

ProdigyZeta7 wrote:

Great idea! However, in under 2 minutes I was able to implement workarounds for all three blocks in my collection. And for that reason it isn't necessary to include a built-in block.

Cyoce wrote:

Ok guys. stop right there. Having a complicated work-around (or even a mediocre-complexity) work-around does not invalidate an idea! 90% of scratch blocks are work-aroundable with other blocks. Should we remove

<not (input)>

because you can work-around it with

<(input) = [false]>

Or remove

((a) + (b))

because we can replace it with

((a) - ((0) - (b)))

or remove

turn cw (rotation) degrees

because we could work-around with

point in direction ((direction) + (rotation)) //?

No we shouldn't! At least not until we get custom reporters **cough** Scratch Team **cough**

Conniepoo wrote:

Check out my simple solution for a case changing algorithm.

tt_thoma wrote:

The only case sensitive thing in Scratch is the switch costume block