What about immutability? A key part of functional programming is using immutable structures to avoid side effects.
My understanding is that Swift has these to some extent ("let" vs "var", structs being immutable etc). And since Kotlin is built on JVM compatibility I _assume_ that Kotlin does not support an immutable style of programming. Maybe someone here has more clarity on this.
> And since Kotlin is built on JVM compatibility I _assume_ that Kotlin does not support an immutable style of programming.
The underlying host doesn't imply anything about language support as that's handled at the compiler level, not at the machine or VM level.
Even in Haskell data isn't immutable if you have a debugger or modify the machine code. It's simply a tool provided and enforced solely by the compiler - other JVM languages do support it like Clojure or Scala.
You can have immutability by making the setters methods of a class private. So if you combine it with "val" you have immutable objects. It is a bit more job in kotlin but as it is also object oriented programming you can achieve exactly what you want.
And for structures you have list, mutablelist, map, mutablemap, etc.
For immutability to be practical one would need to implement structural sharing in their collections otherwise copying would be prohibitively expensive.
I get your point now. Yes, it is read-only, not immutable. For me, I only need read-only. I think kotlin wasn't meant to be pure functional. I see it as object oriented with some functional programming.
out of curiosity, what cases will you use an immutable collection instead of a read-only? I cannot imagine any use case where immutable is a gain over read-only.
"Read-only" would not implement structural sharing.
Consider the situation where you had a linked list with 10,000
elements and you wanted to return a new list with one new element added to the 'head' of the list. With "read-only" you would literally have to make a new linked list with 10,001 elements which would kill performance.
While semantically correct, immutability via deep-copying is very impractical. So, immutability (of Collections in particular) needs to be implemented via structural sharing of elements.
In the above example, with structural sharing, the new list would have the new element and inside would point to the old 10,000 element list but the whole 'structure' would appear to you as just a normal list.
Sorry, I don't see the difference. With read-only you can create a new object which is the first element of the list and also points to the rest of the list. Instead of an structure you have an "immutable" object.
Yes, but the resulting object is not a "List" and hence would not inter-operate with any function that took a List as input.
In essence if the original object implements a List _interface_, then the new one should as well. If you do all of this, then you've essentially implemented immutability and structural sharing. But then you have to do this for 10 other Collection types as well.
Now, you could do all this, but I could do it as well and do it differently. Then my function which took MyList as argument would not interoperate with your function that wants to pass YourList as argument.
Something as fundamental as an (immutable) collection needs to be standardized so that all functions can take these and return them and thus compose easily.
This is the case with languages that implement immutability like Elixir, Haskell etc.
There are already interfaces for Immutable collections in kotlin. And all the functional operators as map, filter, etc, returns them. But it is not true immutability as you said, because under the hood they are normal list. They aren't even read-only objects, but you encapsulate this behaviour under an interface.
This needs to be built into the language or somehow standardized by the community.
With lack of standardization of immutable collections, there would be lots of different ways that libraries would implement immutability. This would result in losing one of the main benefits of functional programming (i.e. awesome composability).
This is already in the language. It is just an interface which makes the common lists only visible as immutable objects. But inside they are a normal list. And in this case the object is read-only, not immutable, as we were discussing in the other comment thread.
My understanding is that Swift has these to some extent ("let" vs "var", structs being immutable etc). And since Kotlin is built on JVM compatibility I _assume_ that Kotlin does not support an immutable style of programming. Maybe someone here has more clarity on this.