For example, filterNot:
That one needed a comment to tell me what it was doing.
And another example, map (my nemesis):
Now in all circumstances I like the general style – nice and simple. I liked it in Ruby too (or the equivalent), but to me, while “filter” makes sense on its own as something which will give me things which match the filter, filterNot only makes sense like this in light of knowledge of filter. And I’ve already posted about map before…
Even as I’m writing this I can appreciate that I’m grousing. The above comments even now seem silly and petulant. Perhaps I’m slowly coming round to the Scala way of thinking. It is a different mindset. In light of it’s hyper-terse API names, even Ruby is beginning to look verbose. I didn’t think I’d be saying that two weeks ago. Its beginning to feel like I need to build up a massive hashmap in my head of common function names and their associated activity. Then when I read some Scala code they’ll light up in my mind with a little associated picture of what they’re doing. That’s not unlike how Heisig gets into your head too. It’s surprisingly effective.
So in light of that:
- filter – a sieve, with the resulting things left in it, everything which matched the provided expression-argument
- filterNot – the same sieve, but now we’re looking at the stuff that didn’t get caught in it, the stuff in the sink, the stuff that didn’t match the provided expression-argument
- map – … I’m sorry, I still can’t think of a good mental image that’s going to fit this one. Not yet. Not without using “apply” heavily and I know that’s reserved for a whole other area of significance…
Maybe think of map as a little assembly line. Imagine telling your son to take one bite from each crisp on his plate, leaving the rest behind. The "take one bite" is the function, the plate full of intact crisps is the starting list, and the plate full of crisp-halves is the result list.
ReplyDeleteOr if you want a mnemonic which includes the word "map", imaging handing your son a stack of black and white maps and telling him to color in one country. First list = black and white maps, function = "color in a country", and result = partially colored maps.
The main key for map is to think (for now) that your function doesn't make the list bigger or smaller - your function does not change one input item into more than one output item. There's a way to do that, which is actually pretty cool, but we'll worry about that once you get there. For now, you can manipulate the values while maintaining type, you can change type, etc, but will keep the same number of items.
ReplyDeleteBy combining map and filter (or filterNot) you can manipulate the values and then remove some. Picture your assembly line (map) adding some piece to the item, then a quality check (filter) making sure that the items pass muster.
Thanks @Semeru. I hadn't expected to get comments on these posts. This is helpful though. I'm beginning to realise I need to change my mind to match Scala rather than the other way round. I think your second comment really adds to my understanding of this particularly. Thanks very much. I'll keep posting and hopefully you can keep pointing me in the right direction.
ReplyDelete