Ban "There is a workaround" from the discussion forum

ksdavidc

7salad3salad wrote:
ksdavidc wrote:
7salad3salad wrote:
No support. Theres a workaround. People need to know the workarounds. Even ST members use workarounds.
Despite the title, the question is not workarounds in general, but using workarounds to justify lack of support without explaining the actual basis for this. I realize I should have made the title more precise. I was being tongue in cheek. Not proposing a ban, either.
So, ban “there is a workaround” when it is reasoning for not supporting?

Not quite. If it is the ONLY STATED reason for not supporting, I would deprecate it. If you say, there is a workaround and it is better because (it makes the suggestion ENTIRELY redundant, it is shorter, faster, cuter, etc., whatever your reason is), that is certainly fine. If not, then, other than the value of offering the workaround, I feel it doesn't help us (the community) understand why the suggestion is not to be supported. There are somewhat redundant blocks, and we use them all the time, they even cause confusion in my students, but it's the price we pay for added convenience and flexibility. That said, there is an economy in the number of blocks, screen space, etc., that need to be preserved, so let's evaluate intelligently and with reasons.

I strongly regret having used the word ban. I thought I was being cute. Apologies.

9cjames1

There is a workaround to this suggestion.joke
Just ask politely to give a more detailed explanation for the workaround.

ksdavidc

Ah yes, @Queer Royalty. I wanted to thank you for the link by @Sigton you mentioned, which I think I forgot to mention in my first reply. It's the second sticky in the discussion forums, I should have seen it! My suggestion basically points to item 6 on that list, though the other suggestions are all relevant. I don't want to duplicate effort, but I also think it is a little easier to discuss something one point at a time, so maybe this post is useful.

The only thing is after reading that link I almost started to think maybe a ban really is necessary!

Queer_Royalty wrote:
Notice that, in my initial response, I failed to communicate my support of this suggestion of lack thereof.

Noted, nor was it expected. The whole support/no support thing is really useless, as @Sigton says. Anyway, I am not really looking for support of that kind, as if this were some kind of contest. It was the the thoughtfulness of your reply that I noticed the most.

Queer_Royalty wrote:
This is simply because I did not feel the need. What good does it do for complete strangers on the Internet to provide their opinion with no reasoning to back it up?

It seems that you are almost saying there is no point having any discussions. But the solution is easy, provide reasons. Be thoughtful. Listen with an open mind. Be open to having your mind changed, and have faith that others are listening to you as well.

Queer_Royalty wrote:
One is unlikely to convince someone of something without knowing why they oppose it, for doing so is like stabbing at a ghost in the dark. The ghost will always win because, confident in its own faulty reasoning, someone else is unlikely to oppose that reasoning because that someone else does not know what it is opposing.

I really like your image of a ghost in the dark. My question boils down to How do we capture this ghost? Stabbing doesn't work, agreed, anymore than vinegar on bees. And you can't please everyone. But perhaps you can make a good case, and clean out certain easy cases (create ghost free areas)?

Queer_Royalty wrote:
If one should not be allowed to say “No support; there is a workaround,” without providing a reasoning, then shouldn't one also not be allowed to say “Support; the workaround is not sufficient?” It is essentially the same lack of constructiveness.

Now we get to the thick of it. I suppose you are right, but I think a distinction can be made. Saying the workaround is not sufficient points to the differences, whereas citing the mere existence of the workaround suggests they are identical. = is not the same as <.

Queer_Royalty wrote:
However, if one were to say “Support, here is the workaround and here is why it is not sufficient,” about a workaround that has not yet been discussed and explored, that would have to be considered constructive. The matching parallel would, obviously, be “No Support, here is the workaround and here is why it is not sufficient.”

Yes, that is right! The question is how do we promote that? Perhaps a ban is like the vinegar, but what is the honey?

han614698

No, this is not suggesting to ban “workarounds” from the discussion forums, just to ban

no support bc workaround

(Without a reason)

ksdavidc

reallysoftuser wrote:
Why ban pointing out workarounds from the entire discussion forums? Why not only Suggestions? I think people could also use workarounds in other forums like Help With Scripts.

That is a valid point. (again, not banning….)

ksdavidc

PATSATDAT wrote:
no support because

let's add
set [variable v] to () + () :: operators
even though a simple workaround is
set [variable v] to (() + ())

I am sorry I don't completely understand this. Could you elaborate?

ksdavidc

ScolderCreations wrote:
reallysoftuser wrote:
Why ban pointing out workarounds from the entire discussion forums? Why not only Suggestions? I think people could also use workarounds in other forums like Help With Scripts.
In HWS, workarounds are exactly what you would want, they give you exactly what you want most of the time, and after all, it's Help with Scripts, not “can I use this block”.

Agreed.

ksdavidc

1Oaktree2 wrote:
Hmmm… I think it depends how easy the workaround is. For example,
forever if ( ) 

end
Is easily workaroundable, like so:
if <> then
forever

end
end
But I know some suggestions where there is a workaround, but it's very strenuous, and pointless.

from Forever_If_()_(block in the wiki

Due to the block's simplicity to recreate, that it has less functionality than the replication (you cannot stack multiple If () blocks inside the Forever If () block), and that new Scratchers sometimes confuse it with the Repeat Until () block, there had been many campaigns to remove the block. Eventually in 2.0, the block was removed. The block had an advantage, though: it runs some milliseconds faster than its replication, so it could be used to combat extreme lag.

Despite the simple workaround, multiple users have suggested the block be brought back, because it seems more natural to use for those newer to programming. However, this has been officially rejected by the Scratch Team.

Using the workaround gives an advantage too — you can place multiple If () statements (and If () Then, Else statements, and even other blocks) in the Forever loop.

note that there are still people who support Forever if, as it has an advantage, but the advantages are arguably small. It is a judgement call that says the advantages (naturalness, minor speed to avoid lag) are outweighed by the disadvantages (potential confusion, no inner stacking or blocks). They are close enough that the scarcity of block real estate only allows one. It is only by weighing all these that a decision can be made, and it is a compromise.

If someone had given NSBW, without touching on the reasons, I think that would not be constructive, even if I agree with the decision in the long run.

PATSATDAT

ksdavidc wrote:
PATSATDAT wrote:
no support because

let's add
set [variable v] to () + () :: operators
even though a simple workaround is
set [variable v] to (() + ())
I am sorry I don't completely understand this. Could you elaborate?

I'm saying that that's what someone would say if this got accepted

Yellowsheep43

Workarounds in the discussion forum are allowed and encouraged.
But “No support there is a workaround” is directly discouraged in a sticky:

Sigton wrote:
Stop saying this:
No support, there's a workaround.

The point of Scratch is to be a challenge, not just hand every block over to the user on a sliver platter. Users should work to get these scripts, not just have it done for them.
It's that last sentence especially that gets me angry. People just discard an idea because it “makes things too easy”.

The common response is “why do we have move () steps then”, but it goes much farther than that - why do we have “go to” if we can use “set x” and “set y”? Why use any of the pen stuff, you can replicate it with “stamp”? Why have clones, just make other sprites?

The answer is because not everything has to be challenging. So what if “real programming languages don't do that”? Scratch is supposed to be an introduction to programming, meaning that it's easier. And yes, there are cases where you have to say “no support”. But don't just say it because “it's not challenging enough”.

A block that calculates the sunset based on the user's given location? That's a little too far. A block that converts a “days since 2000” to real-time? That would be OK.

So please, take the time to read through suggestions before dissing them as “not challenging enough”.

SuperMarioHome

Yellowsheep43 wrote:
But we need to know there is a workaround.

Here is a chart generated from text

Simple suggestion Moderate Suggestion Complex Suggestion

Easy workaround OK Workaround Workaround
Moderate workaround Workaround OK OK
Complex workaround Workaround OK OK

Workaround = Workaround is the better solution
OK = The suggestion is the better solution

(this is a terrible graph)

Here's a better one:

+-----------------------+-------------------+---------------------+--------------------+
|                       | Simple suggestion | Moderate suggestion | Complex suggestion |
¦-----------------------+-------------------+---------------------+--------------------¦
| Easy workaround       | OK                | Workaround          | Workaround         |
¦-----------------------+-------------------+---------------------+--------------------¦
| Moderate workaround   | Workaround        | OK                  | OK                 |
¦-----------------------+-------------------+---------------------+--------------------¦
| Complex workaround    | Workaround        | OK                  | OK                 |
+-----------------------+-------------------+---------------------+--------------------+

sharkode

No support, there is a workaround

dave-alt-4

semi-support , something like

Yellowsheep43 wrote:
Simple suggestion Moderate Suggestion Complex Suggestion

Easy workaround OK Workaround Workaround
Moderate workaround Workaround OKworkaround OK
Complex workaround Workaround OK OK

Workaround = Workaround is the better solution
OK = The suggestion is the better solution

would be better Imo since some suggestions have very simple workaround , such as the not equal and if elseif block , which only need 2 block workarounds

mumu245

Support, but “In the meantime, you could do this:” would not be banned.

dertermenter

NOTE: I have not read through every post on this topic, so sorry if I repeat some points.
I don't think a complete ban on this is unnecessary. While yes, sometimes not supporting due to a workaround is can be a bad post if the workaround is complex. I believe everyone should have the mentality of “does the average new coder have the initiative to think of this workaround”? This goes with long workarounds and workaround that use advanced blocks, like lists.

By banning workarounds from the forums, then that must mean that scratch should discourage workarounds by adding blocks that are workaround-able. Great! you may think, but it comes with complexity, as that block still has to follow scratch design goals. Too many blocks will make the editor overcrowded, and the Scratch team has a mentality of “fewer features can improve user experience”. 100 blocks in the editor will also paint the picture of scratch looking complex, discouraging new users from using it. The block should also be easy to use - scratch is a beginner programming language, and the scratch team have rejected suggestions that are too complex. Flexibility on the block also matters. Can the block be used in 10 unique ways? Overall, by banning workarounds, are you saying the scratch team should implement every single workaround possible?

I also don't think these posts are that unconstructive, providing they give a workaround. If they do, well, the original poster a workaround (if they didn't know) which is helpful. I agree that “no support, workaround” posts are unconstructive but the scratch team don't seem to remove spam opinion posts, although you can apparently report them, so if the ST does remove the post, then that is already enforced, it just isn't written down in the forum rulebook (no post has explicitly said that "no support, because there is a workaround, isn't allowed with an ST source).

Yellowsheep43

SuperMarioHome, edited by YellowSheep43 wrote:

Here's a better one:

+-----------------------+-------------------+---------------------+--------------------+
|                       | Simple suggestion | Moderate suggestion | Complex suggestion |
¦-----------------------+-------------------+---------------------+--------------------¦
| Easy workaround       | OK                | Workaround          | Workaround         |
¦-----------------------+-------------------+---------------------+--------------------¦
| Moderate workaround   | OK                | Depends             | Workaround         |
¦-----------------------+-------------------+---------------------+--------------------¦
| Complex workaround    | OK                | OK                  | OK                 |
+-----------------------+-------------------+---------------------+--------------------+

OK = The suggestion is the better solution
Workaround = The workaround is the better solution
Depends = Depends on the context of the suggestion

dave-alt-4

not to meantion these type of people

OP : pls make bla bla bla

random person : no support , just use

*insert 100 line long javascript*

ksdavidc

9cjames1 wrote:
There is a workaround to this suggestion.joke
Just ask politely to give a more detailed explanation for the workaround.

Ah, how I wish there wereno joke, though your suggestion comes close. By all mean. I think polite reminders go a long way, but I am hopoing for something more preventative, especially for people such as @dave-alt-4 (not to) mentions below (#58).

medians

ksdavidc wrote:
modesties wrote:
ksdavidc wrote:
modesties wrote:
So what if you did this?
Support because there is a workaround. However, it's hard, especially for newer Scratchers and this would be used often.

I am not sure I understand what you are saying. For me that would be a valid response, as it gives reasons. Anyway, I am more concerned with “non-support because workaround” type comments.

modesties wrote:
No support because it's mainly used constructively by people who are well into the forums.

Do you mean you do not support (my suggestion) because saying “no support due to workaround” is being properly used? I can cite many examples where it is not IMHO used constructively, such as when reasons have been offered for why the suggestion is better than the workaround, or addresses issues not covered by the workaround, and the response does not address.

Support or not support is not the issue here. I am seeking to create a discussion that would lead to a proposal to address the situation. I don't literally mean ban anything, so no one is being asked to support that. But I hope you could support discussing how to better address this.

Support because there is a workaround. However, it's hard, especially for newer Scratchers and this would be used often.
read it
Also, what if it still hasn't been added yet and it doesn't involve anything to do with extensions or any of that kind?

I encourage and support providing all manner of workarounds, tips, hints, suggestions, advice, comments, jokes, riddles, wordplay, conundrums, and song lyrics, for that matter. But if you withhold support, please give a reason other than the mere existence of a workaround. Not all workarounds are equal, and it furthers the discussion more to know WHY it is better, or if you merely feel it is equivalent in all respects, or what your concerns are with the original suggestion. Is there actually any harm in having both, for example, if they are equivalent? Your original example is entirely acceptable to me.

What? Also, do you want me to type more than 100 lines just saying that you support.

ksdavidc

@selfexplanatory @modesties @chaircard @fireflyhero @dividendyield @colloids
I apologize. I think I really really misunderstood your position, especially “Support because there is a workaround”. I reread the whole 1st comment (you mean, “but this is easier, so I support this”) and I think I see what you mean more clearly. I was responding to the wrong question.

The answer is YES, for me, that would be a very good reply. There are still reasons someone could object to this (e.g. real estate, compatibility, etc. ) but it states the position and gives a reason that can be discussed, so IMHO it is good.

“No support without reason” is still a problem. (did i mention this is not a ban?)

Again, sorry I misread it.

Last edited by ksdavidc (Nov. 2, 2021 20:41:32)

Discuss Scratch