List tutorial

This is a 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...


Cool.


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.

Thank's

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.

OKay.

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))
or
(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.