Helping an iOS coworker get ramped up into our KMP...

# getting-started

[ankushg]

Helping an iOS coworker get ramped up into our KMP codebase.

Overall things are looking great, but they mentioned that they don't quite get the point of the Kotlin StdLib Collection functional operators (map/filter/associate/etc) vs a more "standard” mutable collection + iteration

I'm gonna be honest — I've been working in Kotlin for quite a while and those list operators just come naturally to me. At the same time, I don't think “because they're more idiomatic and look better (to me)” is a good enough reason.

I know there are also benefits like Sequence-compatibility and ease of extracting narrowly scoped helper methods, but I'm sure there's many other reasons to use them (and situations where you shouldn't use them) that I've internalized but can't easily recall and articulate

Does have a link to a good post that details the pros/cons of those operators vs the “not-kotliny” approach?

[Joffrey]

You mean your coworker is not convinced that this:

val list = listOf(1, 2, 3)
val twiceAsMuch = list.map { it * 2 }

Looks better than this:

val list = listOf(1, 2, 3)
val twiceAsMuchMutable = mutableListOf<Int>()
for (n in list) {
    twiceAsMuchMutable.add(n * 2)
}
val twiceAsMuch: List<Int> = twiceAsMuchMutable

?

[ankushg]

I'm sure they'd agree in that specific example, but especially when I start whipping out less obvious things than map (like associateBy or mapIndexed), they're not convinced that the cognitive load is lower than the old-school approach

[Joffrey]

The benefits you listed are good, but the biggest obvious one IMO is DRY. It's just way shorter and less error prone to use a built-in stdlib function to do an iteration for you instead of implementing it manually.

That being said, it also depends on the actual real-life example. I would not chain complex stdlib functional calls without extracting functions out of them with meaningful domain-specific names. It does get out of hand otherwise and I would agree that the cognitive load is too big. BUT, the same would be true if we mix everything in a classic iteration too without extracting functions.

[Mejdi]

I think it is like any abstraction of complex commands, it takes time to easily recall the intent. With functions it is a bit easier as we provide a long enough names that explains better that intent. But these operators come usually with short names. So you need some effort to easily map them to the actual meaning..the effort will be much less once you used them enough.

[andylamax]

Also, the stdlib collection functions do not limit them from going the route they like

[Tom Haywood]

Send them some links on functional programming. map/filter are not Kotliny, they're available in many other languages.

[Chris Miller]

I felt a bit like your coworker when I first started with functional programming. It initially felt somewhat "backwards" (somewhat like the difference between infix vs postfix expressions). I guess it was because I'd been iterating over collections literally for decades, in multiple languages. It was completely second nature to me.

Even though functional operators were generally more succinct, the cognitive load was still higher because my brain wasn't really wired to process them subconsciously yet. Took a while to come around, with various "ah-ha" moments along the way. I'm guessing your coworker probably still needs to go through the same process.