Scratch is supposed to be the easiest programming language there is. But there are many points where it is actually the hardest. This topic details on what these things are and why they are so hard to work with. The main question is, why are these things so, and does scratch plan on changing them?

These things make scratch hard to deal with:

1. Lack of returning values. The current custom block arrangement only allows you to execute code and not return values. This may not seem like such a big deal since you could store it in a variable, but on projects with a lot of variables, this is a big deal. Imagine if you had 20 custom blocks all returning a value and you had to have a variable for each one. It makes your project extremely unorganized by complicating the variable list. Unorganized projects are harder to deal with. Returning values allow you to do this as many times as you want without using any variables. Also, local variables (only available in a certain script) would help on this issue because values that functions use other than their output would be omitted too.
   
2. The comment system. I am sorry, but the current scratch comment system is terrible. First of all, hooking a comment to a script (the comment moves with the script) is much harder than it needs to be. Half the time, I don't do it right. Second, the way the comments are organized is pretty bad too. The comment attempts to get out of the way of all scripts, but it usually ends up going to the other side of the page. Third, comments are huge and cover up way too many blocks. This problem becomes worse when performing a block cleanup because the block cleanup ignores all comments. Even compacting the comment has its flaws. Mainly the one that too little characters can be put into the compact comment. The “…” comes way too early. Even if you do get these things down, it is too easy to mess up the comments. And when you put a sprite/script in your backpack, none of the comments are copied. These things (and more) make scratch comments a nightmare to deal with (these are also why I don't bother adding comments to my code).
   
3. The sound editor. This one I don't have much to say about. Essentially, the way that you apply effects to sounds in scratch is very strange. First, you have to figure out how to select a section (it isn't obvious). Then, you have to figure out what each effect does. I think effects are the only thing in scratch without built-in help. This makes the sound really hard to deal with.
   
4. Insufficient Parameter Options. Currently, only 3 types of parameters are allowed without hacked blocks. But there are so many more scratch is capable of. The 2 main examples of this are the variable parameter and the list parameter. Because of the lack of a variable parameter, you need to create a separate variable for the result of each function. If you want that result to be passed to another variable, you have to add another line of code. With the variable parameter, the result can be stored directly into the desired variable. The list parameter is basically the same thing, but more extreme. Currently, there is no way to pass a list to a function. That means that if you want to do anything to a certain list, you will have to either copy that list onto another global list and then copy the result onto the first list, or create a separate custom block for each list you want to use. Both of those solutions can get annoying really fast. With the list parameter, none of that is needed. Just select the list you want in the drop-down menu. Sure, hacked blocks can be used for that purpose, but they have their own problems. For one thing, they confuse new scratchers. For another, if you break a hacked block, you cannot fix it unless you hack it again. This causes for some really annoying and hard to deal with situations.
   
5. Absolutely NO debugging tools. This one really makes no sense. As most of you probably know, scratch has no debugging tools whatsoever. No error reports, no crashes, no console, no nothing. In fact, it seems like they go out of their way to avoid these debugging tools. For example, having a block with an undefined variable in it could be a problem, especially if you just deleted that variable. Instead of reporting a simple error, scratch decides to create that variable for you. You then realize that the variable you just deleted is back. You delete it again, but it's no use. You are forced to track down every single block that uses that variable and delete it WITHOUT deleting any part of the other stack (which is very hard to do, by the way). This can be such a huge pain to do. And that's just one example. Another one would be the almost unavoidable undefined block created when moving scripts that contain custom blocks to other projects. That can really get you. But perhaps the most ridiculous thing relating to this item is the lack of being able to view what has happened/is happening. Currently, the only support for that is a very generic highlight around a script that is currently running. The bigger the script, the less helpful the highlight gets. The lack of these debugging tools (and many more) makes debugging a total nightmare in scratch. Some of these tools can be added manually, but that is a lot of work to fix a few bugs.
   
6. No strings allowed in the cloud. The fact that strings are not allowed in cloud variables complicates almost every interaction with the cloud. Complex translator and transcriber blocks are required to store something that represents a string into the cloud. It becomes even more complex with lists. These already complex blocks are made even more complex due to item 7.
   
7. Almost nothing is case sensitive. This not only creates obstacles with naming things but makes item 6 even WORSE (at least in my algorithm). You see, in order for maximum resiliency and the least amount of code, you need o implement case sensitivity in at least transcribing blocks. This is so hard to do, that the scratch wiki only has 3 methods to do it. Two of which are so ridiculously slow, they could completely ruin any script. The other one involves having 53 variables, which directly works against item 1 by complicating the variable list even more. So It's either unorganized or really slow. Both are a pain. Even if this function wasn't a pain, it would still be hard to deal with due to requiring extra conditions and code to implement. Why can't scratch just make their strings case sensitive?
   
8. The “NOT SAVED” popup. As if the above isn't enough, there is still one more thing that makes scratch hard to deal with. That would be the popup informing you that your project is “NOT SAVED!” This popup shows up in the middle of the screen and doesn't go away until the project is saved. It blocks so many blocks no matter where you move it. So it is basically just a giant, un-removable comment (see item 2).
   

All of these things make scratch very hard to deal with. And I'm sure there's more that I just didn't notice. Can somebody please tell me why these features are included in the “easiest programming language ever” and if they are planned to be fixed?

<string [thing to test for v] includes [thing to search for]?::operators>
if <condition 1::operators> then {
...
} else if <condition 2::operators> then {
...
} else {
...
}::control
return [thing to return]::custom-arg cap
<[] \<= []::operators>
<[] \>= []::operators>
create instance of [thing to make copy of v] with values [1] [10] [-20]::control
(get value [value to get v] of [sprite to get from v]::sensing)
execute based on text [code to execute]::control
break::control cap
continue::control cap
store cookie [name of cookie] [value]::variables
(get cookie [name of cookie]::variables)
(replace [item to look for] with [item to replace with] in [string to do this for]::operators)
(amount of times [item to look for] shows up in [string to do this for]::operators)

Kk, I'll explain what you're confused with here that I'm able to answer;

2. (I don't know if you know of this yet) Usually, there's a shortcut in placing a comment on a block. Just right click the block and select “add comment”. If you still have a reason to create a comment without attaching it to the block first hand and still having trouble hooking it onto the block (which from what I remember, isn't that hard), then you can always copy and paste the comment you've already typed onto the comment attatched to the block.

As for the unorganized comments, imho, it seems pretty organized as is currently. I can't think of any way it can be more organized than it's current state without getting in the way of other scripts. You can always suggest some comment organization features in the “Suggestions” forum. I'm sure you'll find it quite useful.

If the comment is too large, that's why there's the compact button. I don't see why the comment cutting too early is such a problem. You can always expand it to read whatever is needed.

And from my memory, comments should always be copied when put into the backpack. I need to test it out again if I'm not correct.

3. It seems very straightforward. If you have any trouble, just experiment. Programming is all about experimenting. And since there isn't too many features in Scratch, it's rare you'd “break” anything if you tinker with it.

4. (from what I understand) This is just coding basics. Everything isn't served on a silver platter. If (for some reason) you wanted the result of a variable to be copied onto another variable, it doesn't take much to program a small script to do so.

5. You shouldn't have to fully rely on debugging. Yes it can be useful sometimes, but you shouldn't need to lean on debugs.

Staying on topic, debug tools are only used when the program doesn't understand something (for example when you type gibberish into a text based language). Since Scratch is a block based program (as supposed to a text based program) Scratch already understands everything you place, since the blocks are pre-made it is practically impossible to confuse Scratch.

6. Cloud variables are fairly new to Scratch, so the ST are still experimenting with it to see what to do with them and etc.

7. Case sensitivity is something that is being put into consideration, understandably.

8. This only occurs when the project attempts to save (the Scratch online editor tends to save automatically periodically), but there isn't any internet connection to save into the Scratch servers. Which is why there is the “download project” option.

Although, yes, it can get quite annoying at times. I'm hoping they add an ignore option or perhaps something similar

Throwing all this in, I'd like to mention that Scratch is a “beginner language” (rather than viewed as the “easiest programming language ever”). Meaning that the user most likely doesn't know much about coding. Therefore the user probably doesn't expect debugging tools (which Scratch is too basic for anyways) strings, or hacked blocks. The difficulty that you're experiencing is probably due to a lack of features rather than too much “advanced” features. Which is agreeably confusing if you suddenly crash into Scratch being accustomed in mostly text based languages.

Scratch is supposed to be an introductory language, not necessarily just an easier language. Most of these are either things that a user totally new to programming wouldn't use anyway or a concept present in other programming languages that you just expect to be in Scratch. The latter isn't necessary, because its assumed most people coming to Scratch don't already have an expectation for what features a general IDE or programming language should have.
Here's a step by step for why these things aren't necessary:
1. Returning values is something that will be present in Scratch 3
2. Comment system - nobody really uses it. While I agree it doesn't really work all that well, its not something I really care about or something I would see as the “worst thing ever”
3. Sound seems pretty intuitive to me. Definitely more intuitive than any other audio editing software.
4. Variable and list parameters would be neat, but once again, are not really useful to the general population of Scratch. It's kind of a more advanced concept - the added confusion for new Scratchers isn't worth the small gain for veterans Scratchers who would know how to work around anyway.
5. No strings in cloud is a moderation issue.
6. Nothing is case sensitive; see #4. Makes things easier for people new to the entire concept of coding.
7. The NOT SAVED popup? Really? Download your project or fix your internet issues. That's not really Scratch's problem.

Really, most of it can be summed up as what I said originally. Many of these things aren't included because it should be a simple language, that's easy to pick up, not a dumbed down but still turing complete language..

Scratch is supposed to introduce coding for beginners, not a block-based programming language for those wanting to build a serious video game.

Try Stencyl or GameSalad.

PrincessPanda_test_ wrote:

Scratch is supposed to introduce coding for beginners, not a block-based programming language for those wanting to build a serious video game.

Try Stencyl or GameSalad.

I disagree you can do it. I'm making one at the moment. It is extremely hard to do so

You can build serious games with Scratch, it might just be more complex to do so.

As to your question, I think the main thing is that it's block based which means no syntax required, and the editor is much easier to use than for many other programming languages.

awsome_guy_360 wrote:

Kk, I'll explain what you're confused with here that I'm able to answer;

2. (I don't know if you know of this yet) Usually, there's a shortcut in placing a comment on a block. Just right click the block and select “add comment”. If you still have a reason to create a comment without attaching it to the block first hand and still having trouble hooking it onto the block (which from what I remember, isn't that hard), then you can always copy and paste the comment you've already typed onto the comment attatched to the block.

I know that you can attach a comment to a block that way, but it is way too easy to detach, and it covers a lot of scripts.

awsome_guy_360 wrote:

As for the unorganized comments, imho, it seems pretty organized as is currently. I can't think of any way it can be more organized than it's current state without getting in the way of other scripts. You can always suggest some comment organization features in the “Suggestions” forum. I'm sure you'll find it quite useful.

A way to make it more organized would be to make it so that the “clean up” option moves your scripts out of the way of comments, instead of ignoring the comment altogether.

awsome_guy_360 wrote:

If the comment is too large, that's why there's the compact button. I don't see why the comment cutting too early is such a problem. You can always expand it to read whatever is needed.

It is still pretty big, even in compact mode.

awsome_guy_360 wrote:

And from my memory, comments should always be copied when put into the backpack. I need to test it out again if I'm not correct.

Comments are not copied into the backpack.

awsome_guy_360 wrote:

3. It seems very straightforward. If you have any trouble, just experiment. Programming is all about experimenting. And since there isn't too many features in Scratch, it's rare you'd “break” anything if you tinker with it.

Programming is about experimenting with your code. It is NOT about trying to figure out how the editor works.

awsome_guy_360 wrote:

4. (from what I understand) This is just coding basics. Everything isn't served on a silver platter. If (for some reason) you wanted the result of a variable to be copied onto another variable, it doesn't take much to program a small script to do so.

That clutters the variable list. This problem becomes even more annoying when you want to do it for lists because, as I said, you would either have to copy your entire list or make a separate block for each list you are working with.

awsome_guy_360 wrote:

5. You shouldn't have to fully rely on debugging. Yes it can be useful sometimes, but you shouldn't need to lean on debugs.

When it takes you 3 hours just to find the piece of broken code, and another 1 hour to figure out how to fix it, you really wish that you had some debugging tools. This happens way too many times with me.

awsome_guy_360 wrote:

Staying on topic, debug tools are only used when the program doesn't understand something (for example when you type gibberish into a text based language). Since Scratch is a block based program (as supposed to a text based program) Scratch already understands everything you place, since the blocks are pre-made it is practically impossible to confuse Scratch.

That is simply untrue. It is true that error reporting is only used in the programming environment, but there are so many other types of debugging tools that do much more. The most imminent example of this is the console. A console is basically a list of text. Each item represents a message. Consoles can also be used to run certain scripts or grab a certain value outside of the programming environment. You can make your program send a message into the console whenever you want. You can also include certain data about which process sent the message and when the message was sent. This is called time stamping. With just the messages themselves, you can look at exactly what happened in what order (may not match what program says). With time stamping, you can tell information like how long it took and which sprite sent it. This can be especially useful when the computer is multitasking, which scratch actively takes advantage of. For example, say you have a sprite that broadcasts a message to another sprite. The second sprite does some computations and sends a result. The first sprite would then read the result and say it. With this configuration, you would need a broadcast and wait block, but that might not be obvious in all situations. Now, say you added console capabilities to your project. The way it currently is, the console would look like this:

{0} <Sprite1> initializing the output to 0
{0} <Sprite1> sending a message…
{0.01} <Sprite2> received a message.
{0.01} <Sprite1> Saying output…
{0.01} <Sprite2> calculating output…
{0.02} <Sprite1> Said “0”
{0.03} <Sprite2> Output is 5.
{0.03} <Sprite1> End project.

when it should look like this:

{0} <Sprite1> initializing the output to 0
{0} <Sprite1> sending a message…
{0.01} <Sprite2> received a message.
{0.01} <Sprite2> calculating output…
{0.03} <Sprite2> Output is 5.
{0.04} <Sprite1> Saying output…
{0.04} <Sprite1> Said “5”
{0.05} <Sprite1> End project.

The latter is with the broadcast and wait block.

Now, this is a very simple example, but if you somehow couldn't solve it, this output could help tell you what is wrong and look for a block that can fix it. What was wrong is that Sprite1 didn't wait for Sprite2 to finish calculating the output before saying it. Since the output wasn't calculated, Sprite1 said “0”. Consoles can help with much more complicated stuff also. For example, you could constantly check to see if a certain condition is true. If that condition is true, you can indicate an error and stop the project. You can then review the console and see where in the program this error was created, go to that point, and fix it. I am not going to do a real life example because this reply is getting long. Tell me if you would like one.

That is just 1 example of a debugging tool that is used for much more than just syntax errors.

awsome_guy_360 wrote:

8. This only occurs when the project attempts to save (the Scratch online editor tends to save automatically periodically), but there isn't any internet connection to save into the Scratch servers. Which is why there is the “download project” option.

I guess I forgot about that.

awsome_guy_360 wrote:

Although, yes, it can get quite annoying at times. I'm hoping they add an ignore option or perhaps something similar
Throwing all this in, I'd like to mention that Scratch is a “beginner language” (rather than viewed as the “easiest programming language ever”). Meaning that the user most likely doesn't know much about coding. Therefore the user probably doesn't expect debugging tools (which Scratch is too basic for anyways) strings, or hacked blocks. The difficulty that you're experiencing is probably due to a lack of features rather than too much “advanced” features. Which is agreeably confusing if you suddenly crash into Scratch being accustomed in mostly text based languages.

The user doesn't have to “expect” it. If it is there, the user can just ignore it until they are ready to learn more about it. Then, they can put it to use.

KingOfAwesome58219 wrote:

2. Comment system - nobody really uses it. While I agree it doesn't really work all that well, its not something I really care about or something I would see as the “worst thing ever”

It would be very useful if it worked properly. More people would use it too.

KingOfAwesome58219 wrote:

6. Nothing is case sensitive; see #4. Makes things easier for people new to the entire concept of coding.

Case sensitivity is not something specific to the concept of coding. It is common sense to know that “hElLO” is not the same as “hello”. If you don't know that, then you probably won't do well in any type of online activity.

PrincessPanda_test_ wrote:

Scratch is supposed to introduce coding for beginners, not a block-based programming language for those wanting to build a serious video game.

All that means is that it is even more ridiculous how hard to work with because it was made for beginners.

That pretty much sums up all my replies to what people have been saying.

<string [thing to test for v] includes [thing to search for]?::operators>
if <condition 1::operators> then {
...
} else if <condition 2::operators> then {
...
} else {
...
}::control
return [thing to return]::custom-arg cap
<[] \<= []::operators>
<[] \>= []::operators>
create instance of [thing to make copy of v] with values [1] [10] [-20]::control
(get value [value to get v] of [sprite to get from v]::sensing)
execute based on text [code to execute]::control
break::control cap
continue::control cap
store cookie [name of cookie] [value]::variables
(get cookie [name of cookie]::variables)
(replace [item to look for] with [item to replace with] in [string to do this for]::operators)
(amount of times [item to look for] shows up in [string to do this for]::operators)

0037318 wrote:

All that means is that it is even more ridiculous how hard to work with because it was made for beginners.

Beginner as in “Knowing almost nothing about programming”.

If you've done plenty of research on advanced features, strings etc. etc., then you'd probably be better off starting with Python rather than Scratch.

0037318 wrote:

It would be very useful if it worked properly. More people would use it too.

I've never used the comment system since I've first discovered it. Never found a use for it.

Coming from my personal perspective of course.

0037318 wrote:

The user doesn't have to “expect” it. If it is there, the user can just ignore it until they are ready to learn more about it. Then, they can put it to use.

What I'm trying to say is that the user probably doesn't know about tools or special features.

And they probably wouldn't until they read on it or move on into a more advanced refined language. If they do find an “error” with the current system, it's probably too basic for them to complain about or is being fixed in the next update.

0037318 wrote:

That is simply untrue. It is true that error reporting is only used in the programming environment, but there are so many other types of debugging tools that do much more…

I was talking more about a specific debugging tool I use. My mistake.

I'm just going to throw in that Scratch might be too basic to be debugged. Don't look too much into that, just a 'lil guess.

0037318 wrote:

When it takes you 3 hours just to find the piece of broken code, and another 1 hour to figure out how to fix it, you really wish that you had some debugging tools. This happens way too many times with me.

I think I'm finally beginning to understand

Some search tools would be nice, soooo….

Boop.

0037318 wrote:

It is still pretty big, even in compact mode.

Is it really? Did you try using the slider? Mine is pretty small when I compact it.


Scratch was built as a stepping stone in the path of, *ehm*, coding. You aren't meant to stay in Scratch. If you've found it either confusing, basic, or just straight out plain, then move onto a different language. I'm sure things will be more straightforward there.

I am going to mke some suggestions that would fix these things in the suggestion forum.

<string [thing to test for v] includes [thing to search for]?::operators>
if <condition 1::operators> then {
...
} else if <condition 2::operators> then {
...
} else {
...
}::control
return [thing to return]::custom-arg cap
<[] \<= []::operators>
<[] \>= []::operators>
create instance of [thing to make copy of v] with values [1] [10] [-20]::control
(get value [value to get v] of [sprite to get from v]::sensing)
execute based on text [code to execute]::control
break::control cap
continue::control cap
store cookie [name of cookie] [value]::variables
(get cookie [name of cookie]::variables)
(replace [item to look for] with [item to replace with] in [string to do this for]::operators)
(amount of times [item to look for] shows up in [string to do this for]::operators)

The first suggestion I have made addresses Item 1 and is here:

https://scratch.mit.edu/discuss/topic/285943/

Feel free to post your opinion on it.

<string [thing to test for v] includes [thing to search for]?::operators>
if <condition 1::operators> then {
...
} else if <condition 2::operators> then {
...
} else {
...
}::control
return [thing to return]::custom-arg cap
<[] \<= []::operators>
<[] \>= []::operators>
create instance of [thing to make copy of v] with values [1] [10] [-20]::control
(get value [value to get v] of [sprite to get from v]::sensing)
execute based on text [code to execute]::control
break::control cap
continue::control cap
store cookie [name of cookie] [value]::variables
(get cookie [name of cookie]::variables)
(replace [item to look for] with [item to replace with] in [string to do this for]::operators)
(amount of times [item to look for] shows up in [string to do this for]::operators)

0037318 wrote:

awsome_guy_360 wrote:

Kk, I'll explain what you're confused with here that I'm able to answer;

2. (I don't know if you know of this yet) Usually, there's a shortcut in placing a comment on a block. Just right click the block and select “add comment”. If you still have a reason to create a comment without attaching it to the block first hand and still having trouble hooking it onto the block (which from what I remember, isn't that hard), then you can always copy and paste the comment you've already typed onto the comment attatched to the block.

I know that you can attach a comment to a block that way, but it is way too easy to detach, and it covers a lot of scripts.
…

Isn't there an arrow that allows you to collapse and expand the comment? That doesn't seem to take up much space.

DownsGameClub wrote:

Isn't there an arrow that allows you to collapse and expand the comment? That doesn't seem to take up much space.

That doesn't make comments any less wonkier. By personal experience, I would gladly use comments if it wasn't so broken and flies off into the sun when I try to attach it to a block.

Hex4Nova wrote:

DownsGameClub wrote:

Isn't there an arrow that allows you to collapse and expand the comment? That doesn't seem to take up much space.

That doesn't make comments any less wonkier. By personal experience, I would gladly use comments if it wasn't so broken and flies off into the sun when I try to attach it to a block.

I also agree with this but think it should probably be in its own separate topic.

The second suggestion I made addresses the comment system problem (item 2), and is here:

https://scratch.mit.edu/discuss/topic/286505/?page=1#post-2930115

<string [thing to test for v] includes [thing to search for]?::operators>
if <condition 1::operators> then {
...
} else if <condition 2::operators> then {
...
} else {
...
}::control
return [thing to return]::custom-arg cap
<[] \<= []::operators>
<[] \>= []::operators>
create instance of [thing to make copy of v] with values [1] [10] [-20]::control
(get value [value to get v] of [sprite to get from v]::sensing)
execute based on text [code to execute]::control
break::control cap
continue::control cap
store cookie [name of cookie] [value]::variables
(get cookie [name of cookie]::variables)
(replace [item to look for] with [item to replace with] in [string to do this for]::operators)
(amount of times [item to look for] shows up in [string to do this for]::operators)

0037318 wrote:

Scratch is supposed to be the easiest programming language there is. But there are many points where it is actually the hardest. This topic details on what these things are and why they are so hard to work with. The main question is, why are these things so, and does scratch plan on changing them?

These things make scratch hard to deal with:

1. Lack of returning values. The current custom block arrangement only allows you to execute code and not return values. This may not seem like such a big deal since you could store it in a variable, but on projects with a lot of variables, this is a big deal. Imagine if you had 20 custom blocks all returning a value and you had to have a variable for each one. It makes your project extremely unorganized by complicating the variable list. Unorganized projects are harder to deal with. Returning values allow you to do this as many times as you want without using any variables. Also, local variables (only available in a certain script) would help on this issue because values that functions use other than their output would be omitted too.
   
2. The comment system. I am sorry, but the current scratch comment system is terrible. First of all, hooking a comment to a script (the comment moves with the script) is much harder than it needs to be. Half the time, I don't do it right. Second, the way the comments are organized is pretty bad too. The comment attempts to get out of the way of all scripts, but it usually ends up going to the other side of the page. Third, comments are huge and cover up way too many blocks. This problem becomes worse when performing a block cleanup because the block cleanup ignores all comments. Even compacting the comment has its flaws. Mainly the one that too little characters can be put into the compact comment. The “…” comes way too early. Even if you do get these things down, it is too easy to mess up the comments. And when you put a sprite/script in your backpack, none of the comments are copied. These things (and more) make scratch comments a nightmare to deal with (these are also why I don't bother adding comments to my code).
   
3. The sound editor. This one I don't have much to say about. Essentially, the way that you apply effects to sounds in scratch is very strange. First, you have to figure out how to select a section (it isn't obvious). Then, you have to figure out what each effect does. I think effects are the only thing in scratch without built-in help. This makes the sound really hard to deal with.
   
4. Insufficient Parameter Options. Currently, only 3 types of parameters are allowed without hacked blocks. But there are so many more scratch is capable of. The 2 main examples of this are the variable parameter and the list parameter. Because of the lack of a variable parameter, you need to create a separate variable for the result of each function. If you want that result to be passed to another variable, you have to add another line of code. With the variable parameter, the result can be stored directly into the desired variable. The list parameter is basically the same thing, but more extreme. Currently, there is no way to pass a list to a function. That means that if you want to do anything to a certain list, you will have to either copy that list onto another global list and then copy the result onto the first list, or create a separate custom block for each list you want to use. Both of those solutions can get annoying really fast. With the list parameter, none of that is needed. Just select the list you want in the drop-down menu. Sure, hacked blocks can be used for that purpose, but they have their own problems. For one thing, they confuse new scratchers. For another, if you break a hacked block, you cannot fix it unless you hack it again. This causes for some really annoying and hard to deal with situations.
   
5. Absolutely NO debugging tools. This one really makes no sense. As most of you probably know, scratch has no debugging tools whatsoever. No error reports, no crashes, no console, no nothing. In fact, it seems like they go out of their way to avoid these debugging tools. For example, having a block with an undefined variable in it could be a problem, especially if you just deleted that variable. Instead of reporting a simple error, scratch decides to create that variable for you. You then realize that the variable you just deleted is back. You delete it again, but it's no use. You are forced to track down every single block that uses that variable and delete it WITHOUT deleting any part of the other stack (which is very hard to do, by the way). This can be such a huge pain to do. And that's just one example. Another one would be the almost unavoidable undefined block created when moving scripts that contain custom blocks to other projects. That can really get you. But perhaps the most ridiculous thing relating to this item is the lack of being able to view what has happened/is happening. Currently, the only support for that is a very generic highlight around a script that is currently running. The bigger the script, the less helpful the highlight gets. The lack of these debugging tools (and many more) makes debugging a total nightmare in scratch. Some of these tools can be added manually, but that is a lot of work to fix a few bugs.
   
6. No strings allowed in the cloud. The fact that strings are not allowed in cloud variables complicates almost every interaction with the cloud. Complex translator and transcriber blocks are required to store something that represents a string into the cloud. It becomes even more complex with lists. These already complex blocks are made even more complex due to item 7.
   
7. Almost nothing is case sensitive. This not only creates obstacles with naming things but makes item 6 even WORSE (at least in my algorithm). You see, in order for maximum resiliency and the least amount of code, you need o implement case sensitivity in at least transcribing blocks. This is so hard to do, that the scratch wiki only has 3 methods to do it. Two of which are so ridiculously slow, they could completely ruin any script. The other one involves having 53 variables, which directly works against item 1 by complicating the variable list even more. So It's either unorganized or really slow. Both are a pain. Even if this function wasn't a pain, it would still be hard to deal with due to requiring extra conditions and code to implement. Why can't scratch just make their strings case sensitive?
   
8. The “NOT SAVED” popup. As if the above isn't enough, there is still one more thing that makes scratch hard to deal with. That would be the popup informing you that your project is “NOT SAVED!” This popup shows up in the middle of the screen and doesn't go away until the project is saved. It blocks so many blocks no matter where you move it. So it is basically just a giant, un-removable comment (see item 2).
   

All of these things make scratch very hard to deal with. And I'm sure there's more that I just didn't notice. Can somebody please tell me why these features are included in the “easiest programming language ever” and if they are planned to be fixed?

When you say that scratch having no debugging tools is bad, it's actually good, scratch hasn't added them because then you don't feel like you are bad at coding if you got loads and loads and loads of messages saying the code is wrong, plus it's not their fault, it is more likely going to be yours if the code doesn't work the way you wanted it to.

0037318 wrote:

The second suggestion I made addresses the comment system problem (item 2), and is here:

https://scratch.mit.edu/discuss/topic/286505/?page=1#post-2930115

Can't you edit one post instead of posting loads?

Scratch is not meant to be highly capable, it’s meant to introduce people to programming. Think of scratch as the first step on a staircase. The first step is the easiest to walk up to. Tell me on my profile if this helps,

FuturePr0 wrote:

When you say that scratch having no debugging tools is bad, it's actually good, scratch hasn't added them because then you don't feel like you are good at coding if you got loads and loads and loads of messages saying the code is wrong, plus it's not their fault, it is more likely going to be yours if the code doesn't work the way you wanted it to.

Debugging tools are meant to help you. Not fix the problem for you. they can help you avoid some really infamous errors, like the undefined block. It is not really anyone's fault that this happens, as programmers always have to debug their code. However, debugging tools make this process a lot faster and help everyone.

<string [thing to test for v] includes [thing to search for]?::operators>
if <condition 1::operators> then {
...
} else if <condition 2::operators> then {
...
} else {
...
}::control
return [thing to return]::custom-arg cap
<[] \<= []::operators>
<[] \>= []::operators>
create instance of [thing to make copy of v] with values [1] [10] [-20]::control
(get value [value to get v] of [sprite to get from v]::sensing)
execute based on text [code to execute]::control
break::control cap
continue::control cap
store cookie [name of cookie] [value]::variables
(get cookie [name of cookie]::variables)
(replace [item to look for] with [item to replace with] in [string to do this for]::operators)
(amount of times [item to look for] shows up in [string to do this for]::operators)

0037318 wrote:

FuturePr0 wrote:

When you say that scratch having no debugging tools is bad, it's actually good, scratch hasn't added them because then you don't feel like you are good at coding if you got loads and loads and loads of messages saying the code is wrong, plus it's not their fault, it is more likely going to be yours if the code doesn't work the way you wanted it to.

Debugging tools are meant to help you. Not fix the problem for you. they can help you avoid some really infamous errors, like the undefined block. It is not really anyone's fault that this happens, as programmers always have to debug their code. However, debugging tools make this process a lot faster and help everyone.

But what will be the use of so said debugging tools? Examples perhaps?

Also, the undefined block is a server error btw.

awsome_guy_360 wrote:

0037318 wrote:

FuturePr0 wrote:

When you say that scratch having no debugging tools is bad, it's actually good, scratch hasn't added them because then you don't feel like you are good at coding if you got loads and loads and loads of messages saying the code is wrong, plus it's not their fault, it is more likely going to be yours if the code doesn't work the way you wanted it to.

Debugging tools are meant to help you. Not fix the problem for you. they can help you avoid some really infamous errors, like the undefined block. It is not really anyone's fault that this happens, as programmers always have to debug their code. However, debugging tools make this process a lot faster and help everyone.

But what will be the use of so said debugging tools? Examples perhaps?

Also, the undefined block is a server error btw.

I provided a great example earlier. I will now quote it for you to see.

0037318 wrote:

That is simply untrue. It is true that error reporting is only used in the programming environment, but there are so many other types of debugging tools that do much more. The most imminent example of this is the console. A console is basically a list of text. Each item represents a message. Consoles can also be used to run certain scripts or grab a certain value outside of the programming environment. You can make your program send a message into the console whenever you want. You can also include certain data about which process sent the message and when the message was sent. This is called time stamping. With just the messages themselves, you can look at exactly what happened in what order (may not match what program says). With time stamping, you can tell information like how long it took and which sprite sent it. This can be especially useful when the computer is multitasking, which scratch actively takes advantage of. For example, say you have a sprite that broadcasts a message to another sprite. The second sprite does some computations and sends a result. The first sprite would then read the result and say it. With this configuration, you would need a broadcast and wait block, but that might not be obvious in all situations. Now, say you added console capabilities to your project. The way it currently is, the console would look like this:

{0} <Sprite1> initializing the output to 0
{0} <Sprite1> sending a message…
{0.01} <Sprite2> received a message.
{0.01} <Sprite1> Saying output…
{0.01} <Sprite2> calculating output…
{0.02} <Sprite1> Said “0”
{0.03} <Sprite2> Output is 5.
{0.03} <Sprite1> End project.

when it should look like this:

{0} <Sprite1> initializing the output to 0
{0} <Sprite1> sending a message…
{0.01} <Sprite2> received a message.
{0.01} <Sprite2> calculating output…
{0.03} <Sprite2> Output is 5.
{0.04} <Sprite1> Saying output…
{0.04} <Sprite1> Said “5”
{0.05} <Sprite1> End project.

The latter is with the broadcast and wait block.

Now, this is a very simple example, but if you somehow couldn't solve it, this output could help tell you what is wrong and look for a block that can fix it. What was wrong is that Sprite1 didn't wait for Sprite2 to finish calculating the output before saying it. Since the output wasn't calculated, Sprite1 said “0”. Consoles can help with much more complicated stuff also. For example, you could constantly check to see if a certain condition is true. If that condition is true, you can indicate an error and stop the project. You can then review the console and see where in the program this error was created, go to that point, and fix it. I am not going to do a real life example because this reply is getting long. Tell me if you would like one.

That is just 1 example of a debugging tool that is used for much more than just syntax errors.

<string [thing to test for v] includes [thing to search for]?::operators>
if <condition 1::operators> then {
...
} else if <condition 2::operators> then {
...
} else {
...
}::control
return [thing to return]::custom-arg cap
<[] \<= []::operators>
<[] \>= []::operators>
create instance of [thing to make copy of v] with values [1] [10] [-20]::control
(get value [value to get v] of [sprite to get from v]::sensing)
execute based on text [code to execute]::control
break::control cap
continue::control cap
store cookie [name of cookie] [value]::variables
(get cookie [name of cookie]::variables)
(replace [item to look for] with [item to replace with] in [string to do this for]::operators)
(amount of times [item to look for] shows up in [string to do this for]::operators)