3 ms·
Not sure if I agree - it's more natural to have only immutable collections if taking a functional approach. Eg see scala or haskell. Does strong typing change t
by ninjakeyboard 12y ago
Not sure if I agree - it's more natural to have only immutable collections if taking a functional approach. Eg see scala or haskell.
Does strong typing change that? It's very clear if you're whole code base has no side effects what is happening when and where.
- pimlottc 12y ago> It's very clear if you're whole code base has no side effects what is happening when and where. And how likely is that? It's great if you start with a purely functional project but in most projects you're starting with a existing codebase, and you don't always have the time to go back and change everything when you figure out a better way to do it. So I don't think it would be that unusual for someone to want to use immutable objects alongside alongside "normal" mutable objects. But it would be harder to distinguish the two in code when the methods are all the same, particular when you don't have type information at hand.
- ninjakeyboard 12y agoI suppose ruby is the example where you have map! and map. I don't know - the java stream API is clear enough IMO. The Java8 approach was to allow mutating functions on collections and then have lazy-non mutative stream api. As a java8 dev, I don't think it's so hard to understand that map on a play promise is non mutative though - I'm not dropping requests for typesafe to change the api.