JS-1 Week 3: push, pop, shift and unshift array methods are missing from the lesson content

[szemate]

Which module(s) and week(s) does this change effect?
Module(s): JS-1
Week(s): 3

What is the work that needs to be done?

The Array methods section of the lesson doesn't cover push, pop, shift and unshift methods. The slides attached to the lesson include these, therefore I assume that they should be part of the lesson, but those teachers who don't teach from slides can easily forget about them.

Why is this work important to do?

These are possibly the most commonly used array methods, it is important that the students hear about them in class.

[SallyMcGrath]

I think that perhaps we shouldn't teach these actively, in accordance with our functional programming paradigm, as they are all array mutators.

@illicitonion @ChrisOwen101 what do you think?

[szemate]

I think that perhaps we shouldn't teach these actively, in accordance with our functional programming paradigm, as they are all array mutators.

I believe trainees still need to hear about these methods as they should understand what array mutation is. At most workplaces (code bases) they will encounter these methods.

[SallyMcGrath]

They will encounter them, for sure, but I think it's a mistake to load them up with syntax at this point. I don't think they should be part of the core lesson. They are not forbidden knowledge, but I don't think we should focus on them or put them in the core content.

[illicitonion]

I think it's fairly important that we teach at least push. I can certainly live without the others - I think the others are easy for trainees to work out on their own (though pop could be useful for illustrations).

My thinking is:

1. Our trainees frequently get very confused by the difference between returning values, and having side effects. I think contrasting push and concat is a way to try to make this really clear - push just has a side-effect, concat just returns a value. I also think that pop on its own may be really useful for this (because it does both - it has a side effect of removing a value, and it returns the value, and the two things are different, which means it can be a good example of the difference). In general we struggle with teaching the idea of side-effects (mostly we hand-wave over "console.log has a side effect of doing logging" or similar, and it doesn't land). (I still resent JS for sort both sorting in-place and returning the sorted array, because it should be a great function for this, but...)
2. I often see trainees not quite "getting" callback functions, and having them step back and just use a for loop while they're still trying to grok map and filter is really useful to have them still make progress while they're blocked on understanding callbacks. Also, there are definitely times that a for loop is more clear than a chain of maps and filters, and I'm a big fan of telling the trainees that it's better to do whatever reads more simply - without knowing how to build up arrays incrementally, this gets a lot harder.

I think that side effects are an important concept for our trainees to understand - if we can find a really good way of teaching them without array mutability I guess we could do that instead, but arrays seem like a really natural place to be teaching this...

[40thieves]

👍 To throw another reason on the pile, push is common enough that trainees would come across it in other materials. In my experience it's better to get out in front of very common things like this, as it eats lesson time in later lessons to explain.

I like @illicitonion's points about using push to contrast side-effecting and pure functions. But I'll also add that there's a trend that I've observed of folks saying that purity should be considered in context. If you have a local variable and mutate it within a single function, then that is effectively pure.

I worry that if we only teach the pure methods for the sake of purity, then we'll have trainees tying themselves up in knots sticking to that rule: a bit like how trainees have interpreted semantic HTML to mean "div is bad".