Thanks, there's so many different ways to do the same thing. It can be a bit confusing actually

Not really. As in all programming languages you can either write a long low level imperative code that explicitly spells out “what to do”, or you can use abstractions and ready-to-use implementations. Like the

chunked

,

max

, etc are building blocks that are used by developers all the time, so there are ready-to-use abstractions out-of-the box that you can use to avoid reinventing the wheel.

Yea, I need to get more familiar with these abstractions out of the box. For some reason I still find the original imperative code more readable though. Maybe I just need to get used to the fp way

People used to be writing in assembly. We came a long way from there to start trusting that the code like

if (a > b) max = b

would turn into proper instructions. The whole progress in programming hinges on constant raising of the bar of abstractions.

I'm pretty sure this could also be written in terms of a hylomorphism which is technically a higher abstraction than chunked and maxBy

There is no point in raising abstractions just for the sake of rising abstraction. The point is to avoid repetition. This whole

for (...) if (a > b) { update max & index }

loop is a boiler plate that you have to write over and over again countless times. That’s why we have Kotlin standard library, so that you don’t have to constantly reinvent the wheel.

A hylomorphism is even less repetitive and further spells out the structure of the algorithm. I'm not suggesting to use one here as it would be unreadable but there are indeed many ways to write this. And I think this whole thing is more of a learning exercise for OP anyway, so it might actually be better for them to use an explicit fold here, despite being more repetitive.