6 ms·

> Not a panacea, but calling it "overrated" usually means "I haven't felt its benefits yet" or "I'm optimizing for the wrong thing" I think immutability is goo

> Not a panacea, but calling it "overrated" usually means "I haven't felt its benefits yet" or "I'm optimizing for the wrong thing" I think immutability is good, and should be highly rated. Just not as highly rated as it is. I like immutable structures and use them frequently. However, I sometimes think the best solution is one that involves a mutable data structure, which is heresy in some circles. That's what I mean by over-rated. Also, kind of unrelated, but "state management" is another term popularized by react. Almost all programming is state management. Early on, react had no good answer for making information available across a big component tree. So they came up with this idea called "state management" and said that react was not concerned with it. That's not a limitation of the framework see, it's just not part of the mission statement. That's "state management". Almost every programming language has "state management" as part of its fundamental capabilities. And sometimes I think immutable structures are part of the best solution. Just not all the time.

iLemming 11mo ago
I think we're talking past each other. > I like immutable structures and use them frequently. Are you talking about immutable structures in Clojure(script)/Haskell/Elixir, or TS/JS? Because like I said - the difference in experience can be quite drastic. Especially in the context of state management. Mutable state is the source of many different bugs and frustration. Sometimes it feels that I don't even have to think of those in Clojure(script) - it's like the entire class of problems simply is non-existent.
- recursive 11mo ago
  Of the languages you listed, I've really only used TS/JS significantly. Years ago, I made a half-hearted attempt to learn Haskell, but got stuck on vocabulary early on. I don't have much energy to try again at the moment. Anyway, regardless of the capabilities of the language, some things work better with mutable structures. Consider a histogram function. It takes a sequence of elements, and returns tuples of (element, count). I'm not aware of an immutable algorithm that can do that in O(n) like the trivial algorithm using a key-value map.
  - iLemming 11mo ago
    > I made a half-hearted attempt to learn Haskell Try Clojure(script) - everything that felt confusing in Haskell becomes crystal clear, I promise. > Consider a histogram function. You can absolutely do this efficiently with immutable structures in Clojure, something like (reduce (fn [acc x] (update acc x (fn [v] (inc (or v 0))))) {} coll) This is O(n) and uses immutable maps. The key insight: immutability in Clojure doesn't mean inefficiency. Each `update` returns a new map, but: 1. Persistent data structures share structure under the hood - they don't copy everything 2. The algorithmic complexity is the same as mutable approaches 3. You get thread-safety and easier reasoning for a bonus In JS/TS, you'd need a mutable object - JS makes mutability efficient, so immutability feels awkward. But Clojure's immutable structures are designed for this shit - they're not slow copies, they're efficient data structures optimized for functional programming.
    - pka 11mo ago
      > immutability in Clojure doesn't mean inefficiency. You are still doing a gazillion allocations compared to: for (let i = 0; i < data.length; i++) { hist[data[i]]++; } But apart from that the mutable code in many cases is just much clearer compared to something like your fold above. Sometimes it's genuinely easier to assemble a data structure "as you go" instead of from the "bottom up" as in FP.
      - iLemming 11mo ago
        The allocation overhead rarely matters in practice - in some cases it does. For majority of "general-purpose" tasks like web-services, etc. it doesn't - GC is extremely fast; allocations are cheap on modern VMs. The second point I don't even buy anymore - once you're used to `reduce`, it's equally (if not more) readable. Besides, in practice you don't typically use it - there are tons of helper functions in core library to deal with data, I'd probably use `(frequencies coll)` - I just didn't even mentioned it so it didn't feel like I'm cheating. One function call - still O(n), idiomatic, no reduce boilerplate, intent is crystal clear. Aggressively optimized under the hood and far more readable. Let's not get into strawman olympics - I'm not selling snake oil. Clojure wasn't written in some garage by a grad student last week - it's a mature and battle-tested language endorsed by many renowned CS people, there are tons of companies using it in production. In the context of (im)mutability it clearly demonstrates incontestable, pragmatic benefits. Yes, of course, it's not a silver bullet, nothing is. There are legitimate cases where it's not a good choice, but you can argue that point pretty much about any tool.

iLemming 11mo ago

I think we're talking past each other. > I like immutable structures and use them frequently. Are you talking about immutable structures in Clojure(script)/Haskell/Elixir, or TS/JS? Because like I said - the difference in experience can be quite drastic. Especially in the context of state management. Mutable state is the source of many different bugs and frustration. Sometimes it feels that I don't even have to think of those in Clojure(script) - it's like the entire class of problems simply is non-existent.

recursive 11mo ago
Of the languages you listed, I've really only used TS/JS significantly. Years ago, I made a half-hearted attempt to learn Haskell, but got stuck on vocabulary early on. I don't have much energy to try again at the moment. Anyway, regardless of the capabilities of the language, some things work better with mutable structures. Consider a histogram function. It takes a sequence of elements, and returns tuples of (element, count). I'm not aware of an immutable algorithm that can do that in O(n) like the trivial algorithm using a key-value map.
- iLemming 11mo ago
  > I made a half-hearted attempt to learn Haskell Try Clojure(script) - everything that felt confusing in Haskell becomes crystal clear, I promise. > Consider a histogram function. You can absolutely do this efficiently with immutable structures in Clojure, something like (reduce (fn [acc x] (update acc x (fn [v] (inc (or v 0))))) {} coll) This is O(n) and uses immutable maps. The key insight: immutability in Clojure doesn't mean inefficiency. Each `update` returns a new map, but: 1. Persistent data structures share structure under the hood - they don't copy everything 2. The algorithmic complexity is the same as mutable approaches 3. You get thread-safety and easier reasoning for a bonus In JS/TS, you'd need a mutable object - JS makes mutability efficient, so immutability feels awkward. But Clojure's immutable structures are designed for this shit - they're not slow copies, they're efficient data structures optimized for functional programming.
  - pka 11mo ago
    > immutability in Clojure doesn't mean inefficiency. You are still doing a gazillion allocations compared to: for (let i = 0; i < data.length; i++) { hist[data[i]]++; } But apart from that the mutable code in many cases is just much clearer compared to something like your fold above. Sometimes it's genuinely easier to assemble a data structure "as you go" instead of from the "bottom up" as in FP.
    - iLemming 11mo ago
      The allocation overhead rarely matters in practice - in some cases it does. For majority of "general-purpose" tasks like web-services, etc. it doesn't - GC is extremely fast; allocations are cheap on modern VMs. The second point I don't even buy anymore - once you're used to `reduce`, it's equally (if not more) readable. Besides, in practice you don't typically use it - there are tons of helper functions in core library to deal with data, I'd probably use `(frequencies coll)` - I just didn't even mentioned it so it didn't feel like I'm cheating. One function call - still O(n), idiomatic, no reduce boilerplate, intent is crystal clear. Aggressively optimized under the hood and far more readable. Let's not get into strawman olympics - I'm not selling snake oil. Clojure wasn't written in some garage by a grad student last week - it's a mature and battle-tested language endorsed by many renowned CS people, there are tons of companies using it in production. In the context of (im)mutability it clearly demonstrates incontestable, pragmatic benefits. Yes, of course, it's not a silver bullet, nothing is. There are legitimate cases where it's not a good choice, but you can argue that point pretty much about any tool.