There is not much difference in flexibility. It is...

# stdlib

[elizarov]

There is not much difference in flexibility. It is just that updating nested structures with lenses becomes an exercise in following chains of maps. Moreover, if you are using lenses in Haskel-like (pure) language, then you get a benefit of do-notation and advanced optimizations over sequences of lazy operations. If we were to naively rewrite Monad-style lenses approach from Haskell to Kotlin, it would be quite verbose, because in Kotlin you’ll have to do :: to refer to functions and properties and you don’t have a do notation, and it would have been very inefficient, because you don’t have an advantage of purity to optimize back-to-back updates into one. However, Kotlin is an imperative language, so you should not be needing a do notation to start with, and you can directly express a sequence of updates to the the same object, without the need to rely on the smart optimizer to make it efficient.

[masted]

Indeed, the do notation is a way to an imperative within a functional paradigm, there is no point to follow such way in a natural imperative language. It's my general point against functional features that are coming to imperative languages as is - just a bit of deconstruction required to see what happened with all these monads and lenses implementations: at some time a functional language meets a real non-ideal world that requires some kind of imperative declaration to making it just do some actions over things, not only definitions of things; a functional language involves some constructions to declare over functional definitions; a functional language constructs handy imperative structures to manipulate by these new constructions. So, if an imperative language trying to adopt such structure as is, the imperative language is requires to implement a core functional concepts first, just to define an imperative structure over it. It's seems so redundant for me.