Trying again because the last version got closed. Unfortunately, it seems I cannot show examples of ignored features.
So, here we go again, and hopefully it will get the point across this time:

There are a ton of commonly suggested features that get shunned, and a couple are outright rejected.
A lot of posts from years ago tend to lose more and more traction until all people do is bump them in hopes that they will get reviewed again (they won't). Every dupe gets closed and we redirect everyone to a main topic… which has absolutely zero activity. It's really disappointing to see these feature ideas stale because there is no point in talking about them anymore. Some of these suggestions have not been implemented for thirteen years.



So, in THAT case…

I'm suggesting a goal after NGP is put in place. This isn't necessarily for 4.0, but it's definitely a good path towards it.

After NGP, please aim to fill in commonly suggested programming features seen in other languages!

My points are…

1. Certain suggestions are commonly made or obviously useful for projects with larger scopes
I'm not going to make an argument here that it's “easy to add” or that it would “take five minutes”. Although in some cases that could be true, it's not really the point. The difficulty isn't the problem, the fact that it will even be done in the first place is.

2. Isn't this just “Scratch team listens” v2?
No, I'm suggesting a goal. Although increasing transparency between the community and the Foundation WOULD help, the goal ITSELF needs to be put into place (or at least confirmed). I agree with Paymer, but this is about the general code and project area of Scratch. Those improvements can be made later, but the actual code blocks should be made more accessible.

3. But the majority of Scratch users are young and this is a beginner coding platform!
Exactly. They'll learn the motion blocks. Then the looks, sensing… then they'll move onto math, custom blocks. Then matrices, tables, physics… Scratch is meant to help you grow. You either move on, or you don't. So why not make the launchpad include the concepts you'd see later, too, if it follows your progression and growth as a coder? “Too complex” is why they will get to these more complicated features later. Everyone started somewhere, and you did too.

4. Workaround: blahblah. Workaround: blahblahblah
Now that is where it ACTUALLY starts to get too complex for younger Scratchers. You can't replace every feature with a workaround. Some workarounds are so complex they require changing the blocks yourself in order to fully implement them, or require blocks upon blocks upon blocks inside of a single function just to squeeze something into a return variable. It's clunky. There are simple workarounds, and those don't need to be tackled, but the complex ones need to be whittled down to single blocks. Yes, it's backpackable, and yes, it's easy to drag and drop into the editor, but these sorts of things really need to be in the editor by default in the future.




Surely working under constraints is a fun exercise, but it tends to become a hassle at a point. If Scratch is designed to be simple for kids, we should be going towards making those things accessible for them, too, alongside the older portion of the community who regularly needs or uses these features. Scratch doesn't have just one level of difficulty, so why don't we ensure we enrich the current path of growth in programming skills? It shouldn't get to a point where we have to work around basic mathematical operations and list structures. I really do feel like a confirmation is needed here. This isn't about “make Scratch better”. I am NOT trying to make that point. It's “fill in Scratch's gaps”. If there's a way to make a compromise (like Scratchers testing out new blocks or doing the heavy lifting of coding them into the editor), we can do that. We know Scratch Foundation is busy, but we need to make a first step here.

Paddle, if you close this, think of a better reason this time.

Support.
This is very true.

Support. I absolutely agree

@codubee once said dark mode may follow shortly after the ngp, but it's unknown when and plans can change.

WigglyJoey wrote:

@codubee once said dark mode may follow shortly after the ngp, but it's unknown when and plans can change.

That's really only a visual change, so it's not as bad. That can be solved easily.
It's still nice to officially have it, though!

WigglyJoey wrote:

@codubee once said dark mode may follow shortly after the ngp, but it's unknown when and plans can change.

reasonably doubt that
probably not gonna be for a while.

Where’s the original?

DeathReviews wrote:

Where’s the original?

This is the original, which got closed for using block examples to support my argument.

based deltarune pfp, take automatically verified

I think this topic perfectly demonstrates why the sticky “Why most suggestions fail” is the worst thing to ever be added to the forums

support!

i've been on scratch for a while and i've always wanted blocks like an exponent block or custom block reporters and booleans. i assumed the reason scratch didn't add them because they're busy fixing the website but now that i see scratch mods adding blocks like these and with the NGP coming up, i can't really see any reasons for the ST to add these new blocks during/after the release. it's not like these are complicated for new scratchers, like for example with the exponents block, new scratchers just don't have to use that block while more advanced scratchers can.

supercroissants wrote:

(#10)
based deltarune pfp, take automatically verified

agreed

Pixalperfect wrote:

… it's not like these are complicated for new scratchers, like for example with the exponents block, new scratchers just don't have to use that block while more advanced scratchers can.

Exactly!
And this isn't like some “Plss plss plss add all of our suggestions” post. There are a lot of holes in Scratch's programming right now that could be fixed by… well, adding the stuff missing that a lot of Scratchers have pointed out. I feel like it would help translate skill gained here into other languages without as bad a learning curve when dealing with operators like ^, % and some other concepts (such as functions, and I know My Blocks is a way to make functions but that remains incomplete).


Just to clarify, the percent symbol IS the remainder block in plain form, but I'm using that as an example for math functions outside of addition, subtraction, multiplication and division.

Forum filter is KILLING ME

Za-Chary, I choose you!

I'll have to agree with you on this suggestion, though. There are some suggestions which are very useful (like an option to change the navbar's color and the exponents block), but haven't been added yet even after over a decade. Adding these features after the NGP would certainly benefit the userbase. However, I disagree with some of the points made here:

Exactly. They'll learn the motion blocks. Then the looks, sensing… then they'll move onto math, custom blocks. Then matrices, tables, physics… Scratch is meant to help you grow. You either move on, or you don't. So why not make the launchpad include the concepts you'd see later, too, if it follows your progression and growth as a coder? “Too complex” is why they will get to these more complicated features later. Everyone started somewhere, and you did too.

Hmm…Scratch is meant to be a stepping stone for coding, not a stay-forever website. If a Scratcher wants to move on, can't they just move on to a more advanced programming language?

If Scratch is designed to be simple for kids, we should be going towards making those things accessible for them, too, alongside the older portion of the community who regularly needs or uses these features.

This sort of remind me of the “If Scratch is for all ages, why don't they allow more mature content?” argument.

This isn't about “make Scratch better”. I am NOT trying to make that point.

It seems like you are, though.

We know Scratch Foundation is busy, but we need to make a first step here.

It's not just about the Scratch Team being busy, they actually have to consider a suggestion before they implement it. Sure, implementing one suggestion is easy enough (or so it seems, dependingon the suggestion), but having to implement multiple suggestions and think about them is quite a bit of work, don't you think?

DanielaScunk wrote:

Hmm…Scratch is meant to be a stepping stone for coding, not a stay-forever website. If a Scratcher wants to move on, can't they just move on to a more advanced programming language?

Of course they can! But that's why I'm saying make the stepping stone more broad in case Scratchers want to explore more advanced concepts before they move on.

DanielaScunk wrote:

This sort of remind me of the “If Scratch is for all ages, why don't they allow more mature content?” argument.

I feel like that's different. This is “exploring vs. harnessing”, if that's a good way to put it?

DanielaScunk wrote:

It seems like you are (suggesting to improve Scratch), though.

Maybe it does, but I am trying to get it across that there are still holes in Scratch that need to be patched after ST tackles NGP.

DanielaScunk wrote:

It's not just about the Scratch Team being busy, they actually have to consider a suggestion before they implement it. Sure, implementing one suggestion is easy enough (or so it seems, dependingon the suggestion), but having to implement multiple suggestions and think about them is quite a bit of work, don't you think?

I actually covered that in the bottom part! ST is a small team, aren't they? It could be wishful thinking, but we can test things too. Scratch Labs! Or there could be a contribution program set up to see which implementation fits ST's vision for Scratch.

HAL95131 wrote:

Snip

You've made some valid points here, so I agree with you more now.

Bump.

Mainly I want them to add custom reporters. I'm all for workarounds but many of the blocks people want are reporter blocks and it's outrageously awful horrible bad bad bad exhausting to offer workarounds when those workarounds have to be stack blocks, or else copy-pasted every time the workaround is used.

<not <(loudness) < (20)>>

Tolerable workaround to copy-paste. (memorize to your head, etc)

Any workaround for math stuff? Maybe, but best of luck

_nix wrote:

Any workaround for math stuff?

(([e ^ v] of (([ln v] of ([abs v] of (base))) * (exponent))::operators) * (<<(base) \> [0]> or <((exponent) mod (2)) = [0]>> - <<(base) \< [0]> and <((exponent) mod (2)) = [1]>>))

for

((base) ^ (exponent)::operators)

(slightly inaccurate due to rounding errors; the long thing at the right calculates the sign of the result, so it isn't needed if the base is always positive)

nembence wrote:

(#18)

(([e ^ v] of (([ln v] of ([abs v] of (base))) * (exponent))::operators) * (<<(base) \> [0]> or <((exponent) mod (2)) = [0]>> - <<(base) \< [0]> and <((exponent) mod (2)) = [1]>>))

for

((base) ^ (exponent)::operators)

(slightly inaccurate due to rounding errors; the long thing at the right calculates the sign of the result, so it isn't needed if the base is always positive)

ah yes, the workaround at the top is much simpler for newer scratchers to understand (joke)