Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Ask HN: Thoughts on immutability in programming languages?
2 points by diegojromero on June 14, 2021 | hide | past | favorite | 3 comments
I have developed a proof-of-concept Python package to freeze objects [1]

I've developed it for the fun of doing it, without any useful use-case in mind, and to tell you all the truth, I can't find any. I have some idea of what a functional language is (have developed a bit with Haskell and Erlang), but I've not used them in any job. I suppose that's why I can't find a way to use this package to solve any real issue.

What are some sources to learn about immutability on programing languages? How could you use a freeze package in Python or other languages? Would it be useful to share information between threads?

Any advice/idea/feeback/criticism or comment on this matter is appreciated.

[1] https://github.com/diegojromerolopez/gelidum



I think immutability isn't really a feature with use cases.

It's a way of programming without modifying data structures in place/in memory. It's also enables us to retain old values by generating new ones without modifying them. To learn the value of immutability, I suggest watch rich hickeys talk titled "The value of values".

Coming back to freezing a python object, the most obvious way to use that is to ensure that the object isn't modified by another function when passing it around, this may not seem like a feature at small scale but when working it large code bases it absolutely is.

Immutability's main feature is that it makes concurrency easier, if you have some data that's immutable, you can share it freely and everyone can read from it and is guaranteed to get a consistent view of the data without placing any locks or synchronisation.


Immutability can be good for complex data structures that you'd like to have multiple versions of.

For instance in a chess program you might be traversing a tree and decide you want to go back a few moves and with persistent data structures the original data structure is still there and shares a lot of memory with the current board state.

Oddly though last time I wrote a chess program it used Markov Chain Monte Carlo and to do that you always run playouts forwards so there is no advantage to persistent data structures in the playouts even though it might be useful for keeping counts of how many times you won after playing out different moves.

In Java half-understanding of "immutability" can be dangerous. For instance, that persistent list is really immutable of the member objects are immutable. However, you can't write

   final PersistentList myList;
if you ever want to add or remove to the list (you need to replace the reference with a new list.)

   final List myList;
on the other hand cannot be replaced with a new list but you can add and remove items from it as much you like.

   final ImmutableList myList;
won't let you add or remove anything or change the reference, but if the members are mutable nothing stops you from changing them.

Thus it is easy to get in trouble if you have been taught maxims like "final is good", "immutable is good", etc.


Thank you, going to take a look to that talk!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: