Ask HN: Is Immutability new OOP kool-aid? | Hacker News Reader

Ask HN: Is Immutability new OOP kool-aid?

3 pointshigerordermap4 comments

Object oriented programming was once portrayed as great thing and we are now seeing a (kind of) widespread backslash.

Immutability and FP is being portrayed as next big thing these days, at least on HN and similar circles.

Do you think it will end the same way?

View on HN

FP (as it is now) will never be a mainstream. Just because it’s not how people used to think about world.

And there will always be some new “big things”.

Because A. things change and evolve B. people like seeking for the whole grail :)

Forks aren't popular as eating utensils in some parts of the world either. I certainly prefer eating sushi with chopsticks.

Concepts and tools are specific to and can be applied to different domain problems.

Use the right tools to solve the right problem, don't be a fanboy. There's no one size fits all.

IMO immutability will be but FP is not going mainstream any time soon.

I never see many local companies using Immutability and FP, but my tech scene is smaller than Silicon Valley's. I mainly get my dose of these subjects from the Internet through blogs and videos.

I think both FP and Immutability are tools and, like any tool, they can be used correctly or incorrectly. So the important questions to ask about any tool is:

* When should I use this tool?

* When should I NOT use this tool?

I can't speak too much about FP as I don't practice it and I don't see anyone locally doing the same thing (I do prefer functional style: reduce, map, iterators, etc but I see that as distinct from FP). I can speak a bit about immutability, I'm going to attempt to convince you that immutability isn't a fad, but can be a useful tool when modeling certain problems.

I find a lot that immutability is used to describe two related but different things: const/immutability bindings and immutable data structures. Usually, trying to make small items constant isn't that much of a problem. The problem arises when we start making multiple copies of items containing large data structures. Enter immutable data structures.

Immutable data structures try to provide an answer to the inefficiency of copying large data structures by using structural sharing. In the past, these were more typically known as persistent data structures. Tarjan did a lot of work on this topic and the wikipedia page[1] is quite informative.

Basically, a persistent data structure allows access to previous versions of itself. I like to think of the version as an additional dimension that one can use to solve a problem. Usually this dimension is just time, but it can sometimes be other things[2].

So okay, back to the original questions

* When should I use this tool? Immutability attempts to make copying the data structure fast. For an example, the RRB trees[3] uses immutability to provide a sequence data structure that can be concatenated quickly. I believe these are the default sequences in Scala and Clojure. You should use them if you require structural sharing or when you require the operations/complexities they provide.

* When should I NOT use this tool? Most of these data structures are implemented as trees so they are likely to not be as friendly to hardware as a flat array/vector for example. They add a lot of complexity and I have found bugs in libraries that provide these structures. If you don't require the operations or your problem space isn't sufficiently large enough you shouldn't use them.

Anyway, hope I've managed to convince you that immutable data structures aren't a fad and can be useful in many situations.

[1] https://en.wikipedia.org/wiki/Persistent_data_structure

[2] https://en.wikipedia.org/wiki/Point_location

[3] https://infoscience.epfl.ch/record/169879/files/RMTrees.pdf

Reply on news.ycombinator.com