bump

theonlygusti wrote:

bump

It feels like you're changing the name of the topic after every bump? xD

With block name change, support.

Whew! Congrats on an amazing idea! It took very little from you for me to understand what you were talking about, which leads me to believe this may even be superior to the list system we have going now! But that's all qualitative. Still, its simplicity makes me drool. Hopefully that's not the unpopular perception! Full support.

Deerleg wrote:

No support.

For one, beginners would not understand the purpose of this block.

And couldn't you just do this with a couple lists?
1. Empty three pre-made lists
2. Put stuff in them with the “add stuff” block
3. Go through each list with a loop of some sort and add each thing in the lists to another list
4. Done!

And

add (stuff) to [ list v]

Not sure how it would work with functions but it should be possible.

What she said

JoeyTheChicken wrote:

Whew! Congrats on an amazing idea! It took very little from you for me to understand what you were talking about, which leads me to believe this may even be superior to the list system we have going now! But that's all qualitative. Still, its simplicity makes me drool. Hopefully that's not the unpopular perception! Full support.

Hah hah! Thank you, I think this is the most drawn-out (but flattering) support post I've ever seen in suggestions

Deerleg wrote:

theonlygusti wrote:

Deerleg wrote:

No support.

For one, beginners would not understand the purpose of this block.

And couldn't you just do this with a couple lists?
1. Empty three pre-made lists
2. Put stuff in them with the “add stuff” block
3. Go through each list with a loop of some sort and add each thing in the lists to another list
4. Done!

And

add (stuff) to [ list v]

Not sure how it would work with functions but it should be possible.

No.

The point of this is to have first-class lists, not more lists than needed.

Your suggested method doesn't create multidimensional lists, just four named lists, three of which are redundant, and one of which is pointless.

Well, at least my first point is right.
No support anyway.

Ehh.. I don't particularly like this card being played. I mean, New Scratchers aren't stupid, some come in and understand all of it. But some need a little help. I'm not going to say “most” because I'm sure a lot of New Scratchers know about these, but some New Scratchers don't understand Custom Blocks, should we not have them? No. We definitely need them. In case I haven't made my point, it's that we shouldn't no support a suggestion because it MAY be confusing to some New Scratchers.

I support, though I find it slightly confusing. 2D “arrays” are almost needed for boards for games. Especially online board games.

If we get first class Scratch-style (dynamic arrays) first class lists, what about linked lists? It's probably not as high priority, but it would be very nice.
But Scratch *really* needs lambda…

Scratcher1002 wrote:

Deerleg wrote:

theonlygusti wrote:

Deerleg wrote:

No support.

For one, beginners would not understand the purpose of this block.

And couldn't you just do this with a couple lists?
1. Empty three pre-made lists
2. Put stuff in them with the “add stuff” block
3. Go through each list with a loop of some sort and add each thing in the lists to another list
4. Done!

And

add (stuff) to [ list v]

Not sure how it would work with functions but it should be possible.

No.

The point of this is to have first-class lists, not more lists than needed.

Your suggested method doesn't create multidimensional lists, just four named lists, three of which are redundant, and one of which is pointless.

Well, at least my first point is right.
No support anyway.

Ehh.. I don't particularly like this card being played. I mean, New Scratchers aren't stupid, some come in and understand all of it. But some need a little help. I'm not going to say “most” because I'm sure a lot of New Scratchers know about these, but some New Scratchers don't understand Custom Blocks, should we not have them? No. We definitely need them. In case I haven't made my point, it's that we shouldn't no support a suggestion because it MAY be confusing to some New Scratchers.

I support, though I find it slightly confusing. 2D “arrays” are almost needed for boards for games. Especially online board games.

Yes! People come to Scratch to learn. If we add more “confusing” features, it doesn't make them stop and never go on. It gives them a chance to learn and expand their logical mind.

I've got to disagree with ya, guys. Don't knock elegant design. Its simplicity is exactly the reason Scratch is so popular, right? The “low floor, high ceiling” that the Team talks about is a big deal. After all, the purpose of Scratch is for it to be inviting to programming newbies. There are still confusing blocks allowed in, such as:

([sin v] of (9))

But these blocks have to exist for that high ceiling to exist. “Confusing to new users” is a big deal. It's the difference between Scratch and Java. Java is confusing to new users. Scratch is not so much. If a block doesn't have to exist for a high ceiling, it will be harder to make it into Scratch, because the Team is very particular about avoiding confusion. Doesn't mean it can't make it in, but its chances are a lot better if it's not convoluted. From what I understand, this is the design pillar Scratch pivots on. Again: “Confusing to new users” is a big deal.

That said, I really don't think this block is confusing! I may be wrong, but it seems very easy to understand, yet would be excellent! First class lists would help me very much.

JoeyTheChicken wrote:

I've got to disagree with ya, guys. Don't knock elegant design. Its simplicity is exactly the reason Scratch is so popular, right? The “low floor, high ceiling” that the Team talks about is a big deal. After all, the purpose of Scratch is for it to be inviting to programming newbies. There are still confusing blocks allowed in, such as:

([sin v] of (9))

But these blocks have to exist for that high ceiling to exist. “Confusing to new users” is a big deal. It's the difference between Scratch and Java. Java is confusing to new users. Scratch is not so much. If a block doesn't have to exist for a high ceiling, it will be harder to make it into Scratch, because the Team is very particular about avoiding confusion. Doesn't mean it can't make it in, but its chances are a lot better if it's not convoluted. From what I understand, this is the design pillar Scratch pivots on. Again: “Confusing to new users” is a big deal.

That said, I really don't think this block is confusing! I may be wrong, but it seems very easy to understand, yet would be excellent! First class lists would help me very much.

The reason I put “confusing” in quotes because it really isn't that confusing. It's just a bit hard to understand and that's good for new people.

adespotist wrote:

JoeyTheChicken wrote:

I've got to disagree with ya, guys. Don't knock elegant design. Its simplicity is exactly the reason Scratch is so popular, right? The “low floor, high ceiling” that the Team talks about is a big deal. After all, the purpose of Scratch is for it to be inviting to programming newbies. There are still confusing blocks allowed in, such as:

([sin v] of (9))

But these blocks have to exist for that high ceiling to exist. “Confusing to new users” is a big deal. It's the difference between Scratch and Java. Java is confusing to new users. Scratch is not so much. If a block doesn't have to exist for a high ceiling, it will be harder to make it into Scratch, because the Team is very particular about avoiding confusion. Doesn't mean it can't make it in, but its chances are a lot better if it's not convoluted. From what I understand, this is the design pillar Scratch pivots on. Again: “Confusing to new users” is a big deal.

That said, I really don't think this block is confusing! I may be wrong, but it seems very easy to understand, yet would be excellent! First class lists would help me very much.

The reason I put “confusing” in quotes because it really isn't that confusing. It's just a bit hard to understand and that's good for new people.

To an extent I believe that's good for new users, but then you have to remember we can't scare them away either. The low floor means it's easier to want to learn and overcome the confusion. Too much of it and there's no low floor anymore, and Scratch is as exclusive as Java.

Complete Support
sorry for necroposting, but this CAN be done in scratch already. the way it is possible now makes it more confusing for BOTH new and old users and takes a lot more time and processing power. the way it cane be done (unless you want to use text) is to take a list, and for practical use, fill each item in the list with something like:101-248-173-659-203-… and have some sort of custom block to decode it all the way to the x/y variable of which you look for. problems: it is EXTREMELY hard to get it right on the first try, and after you do it is way too slow for practical use. There have indeed been several projects I worked on that I had to give up because I could not do this with any required efficiency.

In other words, making lists a first-class variable would make it simpler for new scratch users, and would add immensely to the possibilities scratch has already.

Full Support!

TheCreeperCake wrote:

Complete Support
sorry for necroposting, but this CAN be done in scratch already. the way it is possible now makes it more confusing for BOTH new and old users and takes a lot more time and processing power. the way it cane be done (unless you want to use text) is to take a list, and for practical use, fill each item in the list with something like:101-248-173-659-203-… and have some sort of custom block to decode it all the way to the x/y variable of which you look for. problems: it is EXTREMELY hard to get it right on the first try, and after you do it is way too slow for practical use. There have indeed been several projects I worked on that I had to give up because I could not do this with any required efficiency.

In other words, making lists a first-class variable would make it simpler for new scratch users, and would add immensely to the possibilities scratch has already.

Full Support!

Erm, you are wrong: this cannot be done in Scratch already.

You said:

TheCreeperCake wrote:

. . . it cane be done (unless you want to use text) is to take a list, and for practical use, fill each item in the list . . .

The point of this block would be to avoid having to use lists.

Also, another problem with your preposition: how would you create nested lists?

if only you could search Snap! projects using keywords or tags…

Please do not add to suggestions post with unrelated things.

This suggestion wouldn't be immediately intuitive to New Scratchers as it is implemented in Snap!, so I will suggest steps to make this suggestion more intuitive, and gain more support for it.

1. Change the block name to something more verbose

(a new list with items [thing1] [thing2] [thing3] \<\> :: list)

This name for the block clearly communicates to the Scratcher that this reporter block creates and reports a new list with those items. When they click on the block to see what it reports, they will see a new list with the specified items in the report bubble, which further communicates this.

2. Two lists should always be completely different
What I mean here is that in Snap!, two variables (or list items, or parameters) can refer to one list - changing the list in one variable will change the list in another variable, and the reason for this won't be intuitive to Scratchers, new and experienced.

The downsides to this are that it prevents some neat things that you can do in Snap!, and that it may be more confusing if people with experience in Scratch try out Snap! for the first time, but I think that this would be an absolute necessity if you ever want first-class lists in Scratch. Feel free to challenge that notion, though.

theonlygusti wrote:

Bump?

Bump

2D lists are rejected:

Za-Chary wrote:

1.7 2D lists
2D lists, also known as 2D arrays, nested lists, or matrices, are a type of data structure that allows you to put an entire list as an element of another list; that is, it allows you to put lists inside of lists. These sorts of data structures are used widely in other programming languages.

The block below, and others, would allow you to create 2D lists to store information, sort of like a table. However, this is too complicated for what is supposed to be an introductory programming language. In addition, there are workarounds possible by using an ordinary list and an indexing function.

For those who are interested, it may be worth checking out Snap!. It is a block-based programming language designed for more experienced programmers, and has more advanced data structures than Scratch does.

add () to sublist () of [list v] :: list