4 ms·

Is that true? It doesn't match many of the comments on HN around React, Om, Clojure etc...

by porker 11y ago

bitL 11y ago
Yes, it is slow. Immutability is allowing you to write elegant concurrent algorithms at the expense of speed and memory. Imagine you are forced to never change an array of numbers for an algorithm computing matrices, rather creating new matrices for each step and specifying numbers only during initialization. But hey, you can cache them and keep track of every single copy without any confusion now! Now imagine a non-concurrent language like JavaScript - what exactly are you going to get by using immutable structures except for the feeling you are going with the times? Reference counting and caching are probably the only areas where immutability can help for most programs. Immutability is in fashion nowadays due to functional programming being in fashion despite the inability to ever achieve "pure" functional programming in reality - I/O is by default "dirty" (I really hate these charged words in computing), no amount of flatmapping (i.e. monads) is going to help with that.
- porker 11y ago
  Thanks, that's a great answer and helps me understand. I guess there are subsets of problems where immutability is a good idea (anything needing state, 'Undo' capabilities), neutral, and a bad idea (number crunching, data processing, 'traditional'(??) programming). I have been wowed by the beauty of the immutable approach in web apps, but definitely subscribe to the right technique for a task. I can't imagine doing the data processing in physics using an immutable language...
  - bitL 11y ago
    Indeed it boils down to what you need to achieve. You might want to use both approaches and combine them for best performance/readability. There are specialized high-performance structures that are mutable (e.g. disruptor in HFT trading) optimizing all the way down to CPU cache lines to achieve unbelievable speeds, yet they work nicely if the objects they refer to are immutable. So just take all advices to switch to immutability with a grain of salt and learn to figure out which approach is suitable for what part of your system to have it both performing well and being able to conceptualize and maintain the code nicely ;-)
- rakoo 11y ago
  > Reference counting and caching are probably the only areas where immutability can help for most programs. There is another use spurred by React: when you have a new state to represent, you have to diff it against current state to know exactly what changed and work only on this diff. "Immutable" structures make this trivial.
- mtanski 11y ago
  Everything immutable (every data structure) is a really convenient way of thinking about processing data in the abstract sense. You can think about processing your (semi) structure data (records) in terms of high level pipelines and processing steps. And, for a whole class of problems this works well. Certainly this abstraction can stretch pretty well. Esp. when your language / framework can optimize immutable data structures under the covers (mutable and reuse.) But the abstraction is just that an abstraction for a mutable platform. The platforms of today (VMs, operating systems, hardware, storage) are not immutable and notoriously full of side effects and undefined behavior. So these immutable language / frameworks end up being good tools at one extreme (high level data processing), bad at the other (system level languages) and vary on a case by case basis. In today's todays platforms if you want to allocate an object in your language think of the layers and layers of side effects that will happen. 1. The allocator/GC system allocates it from some kind of pool possibly. Lots of side effects there (like operating on a pool, triggering some kind of collection / cleanup, requesting a large mapping from the OS. 2. Then at the OS level accessing mapped memory has all sorts of side effect (paging, lazy initialization, etc). 3. At the hardware levels there's lots of side effects: instruction cache, multiple layers of data caches, TLB, DMA. In conclusion, for some kinds of problems you don't need to worry about these details and for others you can't afford to ignore them.

Is that true? It doesn't match many of the comments on HN around React, Om, Clojure etc...

by porker 11y ago

Is that true? It doesn't match many of the comments on HN around React, Om, Clojure etc...

bitL 11y ago

Yes, it is slow. Immutability is allowing you to write elegant concurrent algorithms at the expense of speed and memory. Imagine you are forced to never change an array of numbers for an algorithm computing matrices, rather creating new matrices for each step and specifying numbers only during initialization. But hey, you can cache them and keep track of every single copy without any confusion now! Now imagine a non-concurrent language like JavaScript - what exactly are you going to get by using immutable structures except for the feeling you are going with the times? Reference counting and caching are probably the only areas where immutability can help for most programs. Immutability is in fashion nowadays due to functional programming being in fashion despite the inability to ever achieve "pure" functional programming in reality - I/O is by default "dirty" (I really hate these charged words in computing), no amount of flatmapping (i.e. monads) is going to help with that.

porker 11y ago
Thanks, that's a great answer and helps me understand. I guess there are subsets of problems where immutability is a good idea (anything needing state, 'Undo' capabilities), neutral, and a bad idea (number crunching, data processing, 'traditional'(??) programming). I have been wowed by the beauty of the immutable approach in web apps, but definitely subscribe to the right technique for a task. I can't imagine doing the data processing in physics using an immutable language...
- bitL 11y ago
  Indeed it boils down to what you need to achieve. You might want to use both approaches and combine them for best performance/readability. There are specialized high-performance structures that are mutable (e.g. disruptor in HFT trading) optimizing all the way down to CPU cache lines to achieve unbelievable speeds, yet they work nicely if the objects they refer to are immutable. So just take all advices to switch to immutability with a grain of salt and learn to figure out which approach is suitable for what part of your system to have it both performing well and being able to conceptualize and maintain the code nicely ;-)
rakoo 11y ago
> Reference counting and caching are probably the only areas where immutability can help for most programs. There is another use spurred by React: when you have a new state to represent, you have to diff it against current state to know exactly what changed and work only on this diff. "Immutable" structures make this trivial.
mtanski 11y ago
Everything immutable (every data structure) is a really convenient way of thinking about processing data in the abstract sense. You can think about processing your (semi) structure data (records) in terms of high level pipelines and processing steps. And, for a whole class of problems this works well. Certainly this abstraction can stretch pretty well. Esp. when your language / framework can optimize immutable data structures under the covers (mutable and reuse.) But the abstraction is just that an abstraction for a mutable platform. The platforms of today (VMs, operating systems, hardware, storage) are not immutable and notoriously full of side effects and undefined behavior. So these immutable language / frameworks end up being good tools at one extreme (high level data processing), bad at the other (system level languages) and vary on a case by case basis. In today's todays platforms if you want to allocate an object in your language think of the layers and layers of side effects that will happen. 1. The allocator/GC system allocates it from some kind of pool possibly. Lots of side effects there (like operating on a pool, triggering some kind of collection / cleanup, requesting a large mapping from the OS. 2. Then at the OS level accessing mapped memory has all sorts of side effect (paging, lazy initialization, etc). 3. At the hardware levels there's lots of side effects: instruction cache, multiple layers of data caches, TLB, DMA. In conclusion, for some kinds of problems you don't need to worry about these details and for others you can't afford to ignore them.