My thoughts on the new list item behavior

[ego-lay_atman-bay]

I know this is probably gonna be controversial, but here me out. I love and hate the new addition to the item of list block. I'll explain why

I'll start with what I like about it. I don't need to use the asoc block anymore, it automatically returns the value(s) associated to the key, meaning, no longer needing to get the second item from a list, and dealing with what happens when the key was not found. It's also easier to deal with csv tables, although they weren't hard to deal with in the first place (get index of column in the first item). Overall, pretty good things coming from it.

What I don't like about it is a bit more in-depth

I don't like the ability to type text in an oval input slot.

Each input slot represents the type of value that goes into it. A list input represents a list, a reporter ring indicates a reporter goes in, a predicate slot indicates a predicate, an any input (rectangle) input indicates text or anything else goes in it, and an oval slot indicates only numbers are allowed.

Snap just ruined this principle by letting users type text into the oval slot in the list blocks. This ruins the reason it was a round input slot in the first place, to say that only numbers go in it.

I will admit, there are some cases that you can stick text in an oval slot, but those are always indicated with the text being italic. Italic means that this is not an index, and does not report a value specific to other values. I mean, last always reports the last item in the list, and does not rely on the list having some specific value. Random chooses a random item, also not based on the values in list. Both of these do not rely on specific values in the list, whereas a string index is based off the values in the list.

I think this new function should be split into a separate block, because then you don't have to worry about keys being numbers, or the different behavior of "last" and "last", "random" and "random". This block should also have sn any input, to say that text goes in it.

I also do not like how it's not explained anywhere what list structure you need in order to use string indices. It may be in the manual, but honestly, what kind of teenager wants to read a 168 page reference manual that doesn't even have what they're looking for (yet)? (No offense @bh, there are still plenty of people who read the manual.) It would be nice if there was more info, as well as a new features dialog when you open snap for the first time after an update.

Ok, I may have spiraled away from the item of block, but tldr, I would much perfer if it were separated into a different block, all because it's an entirely new function altogether.

Alright, now is the part that I just personally have something to say.

I was reading this post, What’s new in v8.1.1? - #61 by jens and the bit that kind of stuck out to me is this

@jens

we've been implored by professors and teachers to find a way that lets them teach "objects" and "dictionaries" in Snap without having to use a library

My issue with this is that, if you're gonna try and implement a new data type, it's better to implement it, instead of building it on top of an existing data type.

@jens

so we can refer to imported data fields by their names instead of counting columns or indices in sub-lists.

It's already easy to do that without much of a hassle

I also think you shouldn't just give teachers everything they want to teach on a silver platter, but instead use those things they want to teach about, to teach how to implement it themselves. Relying on a library is not bad, in fact, it's good, because in most programming languages, you have to rely on libraries. Python is practically built off of the idea of libraries, I mean, you need a library to get the date and time, you need a library to add arrays (and that library doesn't even come with python), and so much more. Teachers should be encouraging students to use libraries, instead of asking for the features to be implemented into snap.

Alright, my rant is over, so feel free to talk about all this. I'd like to know what others think.

[d4s_over_dt4]

i just like the fact that you no longer need to make a lot of item(2)of blocks

[bh]

@ego-lay_atman-bay

if you're gonna try and implement a new data type, it's better to implement it, instead of building it on top of an existing data type.

Not if you're a teacher. Probably most of the programmers in the world think you have to use an object oriented language (by which they never mean Smalltalk) to do object oriented programming. To fix that, you have to teach students how to make OOP by rubbing two sticks together. In fact, one of the things I dislike about the new feature is one of the things you like about it: You don't have to write ASSOC to use a-lists.

@ego-lay_atman-bay

it automatically returns the value(s) associated to the key, meaning, no longer needing to get the second item from a list

There's a reason ASSOC works the way it does: so you can have complete control over what to do when the user inserts another item with the same key. (Where "you" is the writer of the library.) And also so ITEM can distinguish between having False (or nil or whatever) as the value associated with a key and there not be a value for that key at all. It's too bad, for some purposes, that keyed ITEM is so permissive.

[bh]

@ego-lay_atman-bay

I also do not like how it's not explained anywhere what list structure you need in order to use string indices. It may be in the manual, but honestly, what kind of teenager wants to read a 168 page reference manual that doesn't even have what they're looking for (yet)?

Yeah, yeah, I have to catch the manual up. Aside from general laziness, I've been reluctant to edit the manual because we need a fixed version to make progress on the project of moving to TeXInfo.

[odysseus_ssb]

@ego-lay_atman-bay

I also do not like how it's not explained anywhere what list structure you need in order to use string indices. It may be in the manual, but honestly, what kind of teenager wants to read a 168 page reference manual that doesn't even have what they're looking for (yet)?

Me. I'm that teenager who will read the manual (although I think I mostly just read areas I didn't feel confident in)

[cymplecy]

I think this is the pertinent bit of Jens's post for those of us with issues with it

@jens

If you don't like the new feature, just pretend it's not there. The blocks look the same as always and they can be used the same as always by simply using numbers inside every oval input slot. Just now there's also another way to use them that formerly didn't do anything at all.

I

[ego-lay_atman-bay]

Yeah, but still, separating the function into another block would be better.

[cymplecy]

It'll be interesting to see how the BJC people get on with using it with students in practice.

It's a bit confusing for us old timers and it might be too confusing for them as well - time will tell

[bh]

@ego-lay_atman-bay

Yeah, but still, separating the function into another block would be better.

Jens has a Thing about adding blocks to the palette.

@cymplecy

It'll be interesting to see how the BJC people get on with using it with students in practice.

Yeah. Although as Jens says you can just ignore this feature. The real threat to BJC is hyperblocks, I think. Sadly, we don't have funding for another revision of the curriculum. :~(