Ferociousfeind wrote:

Everyone here is missing the point by a mile. It's giving me a headahce reading all of these non-sequitur retorts. Sure, you've debunked the small issue in the one example they provided, but you haven't even begun chipping at their main point. Charles12310's point is that it's aggravating to see people deny Scratch expand at all because there are workarounds for a lot of things. My head hurts too much to remember any of my other points, so yeah. Stop being rude.

That's a little harsh, isn't it?
I understand the main point, but MY main point (and most of the other people's main points) is that things that would be rarely used and have a simple workaround shouldn't be added (“in between” isn't necessary since you can test for a < b and b < c).
Things that are too specific or ruin the point of Scratch and programming in general can also be rejected: otherwise we would have an esey mineraft block.
However…
If there is something that would be commonly used and doesn't have a simple workaround *COUGH COUGH* dictionaries *COUGH COUGH*, it's not OK to say “No support-there's a workaround”, ESPECIALLY if you don't actually say what the workaround is.
Also, I really don't like people who say “there's a workaround” without saying what it is. I have to agree with the OP on that one.

Paddle2See wrote:

I disagree. Just because somebody wants an easier way to do something does not mean that they don't see the point of Scratch. I have used old versions of Scratch that had no Trig functions and had no Lists, I was very happy to see those new blocks since it made it much easier to make the computer do what I wanted it to do - and the scripts became much cleaner. There were workarounds to both of those features, which I used until the blocks were available - but I was happy to adopt the new blocks when they were made available.

But it also must be realized that adding new blocks does make Scratch more “bloated” and harder to learn. One of the things that makes Scratch so easy for beginners to start working with right away is it's simplicity - and part of that simplicity is the relatively small number of blocks. The pros and cons of adding a new block must be - and are - weighed very carefully.

I'm pretty sure the old topic was closed because the topic was already covered by a member of an ST. Then it was 3-year-necroed so it was closed. Anyway, Paddle's answer already covers this suggestion. Yes, it's a valid response to suggestions but no, it does not apply to every block suggestion with a workaround.

Just going to reiterate what I said on the previous topic; sometimes a workaround is a valid reason to reject a suggestion, and sometimes it isn't. There's a bit of a grey area.

cul8er wrote:

Just going to reiterate what I said on the previous topic; sometimes a workaround is a valid reason to reject a suggestion, and sometimes it isn't. There's a bit of a grey area.

THANK YOU.

cul8er wrote:

Just going to reiterate what I said on the previous topic; sometimes a workaround is a valid reason to reject a suggestion, and sometimes it isn't. There's a bit of a grey area.

Yeah, pretty much this.

cul8er wrote:

Just going to reiterate what I said on the previous topic; sometimes a workaround is a valid reason to reject a suggestion, and sometimes it isn't. There's a bit of a grey area.

+1

also please see a doctor guys, these constant headaches over something typed on the internet are very worrying

jji10 wrote:

Paddle2See wrote:

I disagree. Just because somebody wants an easier way to do something does not mean that they don't see the point of Scratch. I have used old versions of Scratch that had no Trig functions and had no Lists, I was very happy to see those new blocks since it made it much easier to make the computer do what I wanted it to do - and the scripts became much cleaner. There were workarounds to both of those features, which I used until the blocks were available - but I was happy to adopt the new blocks when they were made available.

But it also must be realized that adding new blocks does make Scratch more “bloated” and harder to learn. One of the things that makes Scratch so easy for beginners to start working with right away is it's simplicity - and part of that simplicity is the relatively small number of blocks. The pros and cons of adding a new block must be - and are - weighed very carefully.

I'm pretty sure the old topic was closed because the topic was already covered by a member of an ST. Then it was 3-year-necroed so it was closed. Anyway, Paddle's answer already covers this suggestion. Yes, it's a valid response to suggestions but no, it does not apply to every block suggestion with a workaround.

Good point.

Support

In real programming languages, there are many ways to do one thing, all within one line of code. For example, in Python, index and find do the same thing. In my opinion, there should be at least 4 alternates blocks to most blocks. The only catch is that the blocks do slightly different things. For example, in Python, if the code fails, index returns an error and find returns the value “-1”.

If the suggested block is literally something that is way too easy and is just something overly specific, like;

glide () secs to x: (0) y: (0) while drawing a [] :: motion

then it makes sense.
But if it's something like a “Go forward () layer” or “Go to back” block, that doesn't really make sense considering it took me a while to realize that it's possible to put negative numbers in there, and because “go back (999999) layers” doesn't really help. Anyway, the “go to front” block has an easy workaround too;

go back (-999) layers

and is it getting removed?

TL;DR I'm a bit checkered on this, so I go with both sides, but if it's something silly like “No support because the workaround is (long string of complicated blocks)”, I agree with this, but if it's “No support because the workaround is (easy and non-obscure thing)”, I'll disagree with this.

Anyway, the suggestions forum really isn't for ranting (and neither is any other forum), but feel free to talk to the ST about it or make a project/studio about it and talk about it in the Show And Tell forum. just don't let it get to the point of the discuss button

einangrun wrote:

also please see a doctor guys, these constant headaches over something typed on the internet are very worrying

“Getting a headache over something” is actually just a metaphor, for example, sometimes you might get a “headache” from seeing people typing like this;

HAAYY Y GUYZ HOW YOUR DOIN

but it's not like a splitting migraine or anything, just a slight headache that lasts for a few minutes..?

[/offtopic]

I'll make a change. This suggestion would be for workarounds not very understandable to all of us. Very simple and very understandable ones are fine.

Charles12310 wrote:

I'll make a change. This suggestion would be for workarounds not very understandable to all of us. Very simple and very understandable ones are fine.

Now I support.

Charles12310 wrote:

I'll make a change. This suggestion would be for workarounds not very understandable to all of us. Very simple and very understandable ones are fine.

Exactly what I was saying in my post!
Now it sounds less one-sided.
Support!

FancyFoxy wrote:

Charles12310 wrote:

I'll make a change. This suggestion would be for workarounds not very understandable to all of us. Very simple and very understandable ones are fine.

Now I support.

me too, after hearing that

Hmm. Seems that “workaround-able” wasn't really taken into consideration too much when a new block was added into Scratch 3.0:

glide (1) seconds to [mouse-pointer v] :: motion

Clearly, this block can easily be worked around, but it looks like it was implemented regardless.

I don't know what I think about the above example, but I still think “it's workaround-able” is a valid reason to no support a suggestion.

However, this clearly shows that it doesn't matter whether or not it's easily workaround-able, but rather the usefulness as a block and whether or not it takes away from the educational aspect of the site.

Charles12310 wrote:

I'll make a change. This suggestion would be for workarounds not very understandable to all of us. Very simple and very understandable ones are fine.

I support this version!

cul8er wrote:

Just going to reiterate what I said on the previous topic; sometimes a workaround is a valid reason to reject a suggestion, and sometimes it isn't. There's a bit of a grey area.

^^^

Exactly. I hate when people go, “No support. There's a workaround.” on every single topic. Sometimes the workaround is easy, but sometimes it's too complicated for people like New Scratchers to use.

As long as they share the workaround, it helps advance the conversation. Better to know than not to know.

There also is a general workaround for not liking another person's reasoning for not supporting a particular block: Post your reasoning for liking the block. Then we have more perspectives on the topic, instead of less.

WolfCat67 wrote:

Hmm. Seems that “workaround-able” wasn't really taken into consideration too much when a new block was added into Scratch 3.0:

glide (1) seconds to [mouse-pointer v] :: motion

Clearly, this block can easily be worked around, but it looks like it was implemented regardless.

I don't know what I think about the above example, but I still think “it's workaround-able” is a valid reason to no support a suggestion.

However, this clearly shows that it doesn't matter whether or not it's easily workaround-able, but rather the usefulness as a block and whether or not it takes away from the educational aspect of the site.

Yep, there is no exact means for determining whether a block should be added to Scratch. That's why not stifling other people sharing their opinions is a good thing.