List tutorial - update

This is the v2 of the tutorial on list for the beginner
It's a work in progress... Not complete but it's a start!
Enjoy !

Don't forget to run the program so the covid list will be loaded over the internet...


You know you can say ITEM (LIST 6 1 2 3 5) OF, right?

Yeah, i forgot to mention it ! i think (item 6 of, item 1 of, ...) it's more easy to understand for a beginner. But i will mention it.


Love it!

One of the biggest hurdles for learning Snap! LISTS is that some of the solutions (shown above) are too complex for many children who are used to Scratch (until now). So they are usually avoided as being 'too difficult' for primary (elementary) school aged children (except the most able coders). An easy example for Snap! LISTS is this demo that could be used. Hope this helps the classroom coders.

Interesting idea, thank you. I would have been more inclined to make one list of question-answer pairs, like this:

You didn't do it that way because you want to give kids code they can run in Scratch. But I don't think we have to limit our tutorials to things you can do in Scratch. Why not just use Scratch if that's what you want? I don't think we want to be competing with Scratch for their target audience; we want to give the older kids, who've maybe gotten as much out of Scratch as they're going to get, an alternative to Python, or whatever else they might study.

Empty input in for loop alert.

Yes, FOR EACH fills empty input slots, just like MAP.


Thanks Brian, I must admit I am in awe of many of the things you demonstrate and yet I just know if I tried to do the same I would loose the entire class. So I have had to work sideways, using SNAP! whilst that could work on both platforms without using any custom blocks. Your solution, unique to SNAP! is a very good example using SNAP! Good for your older students, perhaps, but hopeless for my young coding students!

Coming from a totally different angle (teaching), SNAP!, with Scratch and Python examples. I totally agree that SNAP! has huge advantages, but both platforms have the odd disadvantage. Snap! LISTS are often tricky to get right, even without your very good examples you provide! I must admit I am not greatly in favor of any custom block solutions that are not universal on both platforms.

Answer for Mushroom is fungus, not funghi, and even then it isn't a perfect synonym.

Yes, it's like saying a synonym of "cat" is "animal".

I'm not sure what the point of using Snap! is, then. All else being equal, if you're going to write code that runs in Scratch, it's better just to use Scratch, with its community of a bazillion kids!

My solution isn't "unique to Snap!." It's how any programmer would do it in any language other than Scratch, which limits itself to lists of strings and numbers. If, like Python, the language has dictionaries as a primitive data type, the programmer would probably represent the quiz as a dictionary rather than a list of lists, but basically a dictionary is a list of lists, so (following our general principle of not providing as primitive things that can be implemented in Snap!) that's how we implement it.

If you think you'd lose your class with my code, implement dictionaries yourself and give them to your students as quasi-primitive.

Well, I tend to agree with you on that ideal. In practice I have to compromise a bit and find 'bridges' that attract students. I adapt and learn so I do take your point (well argued). So I will be apply your method more than I do. But I also aim to make things easier for most (new) users to Snap! So we all benefit in some way. A before and after maybe. However; I cannot ignore such legacy code, in practice. Your policy for first class (clean) code is good. But I disagree that 'retro-fitting' such legacy code is a totally bad idea to be avoided entirely. Mny of us are in fact are 'Oldies' who are willing to build bridges between the two platforms). It may not be the ideal but its an option. Maybe not the solution as yet but I am working on it.

New users aren't afraid of lists; it's only old Scratchers who are afraid of lists. At least that's my experience. The trouble with empirical study of this question is that there are precious few people whose first experience is in Snap!. Either they're old Scratchers (most common) or they're precocious 8-year-olds who already know Javascript, Java, Python, and C++. (With the occasional really precocious one who knows all of the above plus Haskell and ML.) So it's hard for us to know for sure what's easiest for a real beginner.

I'm sure it also depends on whether you present it as, e.g.,
(item 1 of (item i of quiz))
(question-part of (item i of quiz))
The former might be kind of headache-inducing, which is why I suggested giving them dictionaries as an abstract data type.

Version 2 of the tutorial !
See what's new inside !

In sprite add/insert:

You copied the comment from the previous line, intending to edit it, and didn't.

In sprite HOF:

I think the use of an empty slot to hold each item of the input list needs explanation, or at least start with a really simple example such as MAP (( )+2) OVER (LIST 6 5 7).

In the comment introducing KEEP, "Keep: add a filter to the list," the word "add" confuses me; it sounds as if you're adding more items to the list! If you want it worded this way, I'd say "apply a filter" rather than "add a filter." A different wording would be "Select only some items from a list based on a filter condition."

I think it might require some explanation why the country is item 1 in the first of these but item 6 in the second.

I think the GROUP block used in here needs some explanation. It does a sort, then a COMBINE for each group, then a reformatting of the data, making the entire result three-dimensional.

In sprite sorting:

The comment says "ascending" but the sort is really in descending order.

The "AND AFTER" in the comment should just be "AFTER"; otherwise it seems to imply that the sort mentioned first happens first.

The "ordering with" should refer to item 1, not item 6, because the columns have already been reordered by MAP.

In sprite Pipe: Since you are nesting HOFs inside the PIPE calls, I think this page needs some explanation of what value gets plugged into each of the empty slots.

In sprite Quiz 1: The timing comparisons are unfair, because the two sequential solutions should use REMOVE DUPLICATES from the List Utilities library to avoid that IF COUNTRY ≠ LAST COUNTRY stuff. (FOR EACH COUNTRY OF (REMOVE DUPLICATES OF (MAP ...)) ...). Also, you don't use the # upvar, so you should use the primitive FOR EACH instead of the one from the List Utilities library.

And to illustrate my point about the nesting of HOFs inside PIPEs needing explanation, in the PIPE solution you have

instead of

with the ring's unringed empty slot filled by the first input to PIPE.

Thank you for your comments and your precious time!

I will make somes corrections later.