this post was submitted on 23 Mar 2025
259 points (98.5% liked)
LinkedinLunatics
4198 readers
9 users here now
A place to post ridiculous posts from linkedIn.com
(Full transparency.. a mod for this sub happens to work there.. but that doesn't influence his moderation or laughter at a lot of posts.)
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
No mutable types? So like.. no lists? no for ... i++?
I get that there are alternative approaches, but I don't quite see why you'd want to go to that extreme with this idea? It's useful for some applications but even for a simple video game it's likely not helpful.
It's perfectly possible to work without mutability.
Is it desirable to be entirely without it? Probably not, but leaning immutable is definitely beneficial.
Yeah, copying can totally screw you over. Mutability is fine, just make sure it's safe (e.g. what Rust does).
There are non-mutable lists and every other data type.
https://docs.scala-lang.org/overviews/collections-2.13/overview.html
https://docs.scala-lang.org/overviews/collections-2.13/concrete-immutable-collection-classes.html
“for… i++” is easily replaced with a foreach, range, iterable, etc… in any language of reasonable capability.
I get that there are alternative approaches, but I don't quite see why you'd want to go to that extreme with this idea? It's useful for some applications but even for a simple video game it's likely not helpful.
I should've said that right away, really. That's on me being online while tired. At that time I did not really think outside the box I was working in that day
It's just a very common foot gun, especially in legacy code where it is not explicit in the design. Even when you have proper getters and setters, it's way to easy for someone to overload the scope of some object, either intentionally or accidentally and modify it inappropriately.
I suppose immutability is a solution, I'm not sure if it's a good idea to radically isolate everything though
it’s not radical, it’s just a guarantee that if you hold a reference to an object, it won’t change state under you. It’s a bit like every object has MVCC and copy-on-write semantics built in.
It’s easy enough to edit the object, producing a new copy, and then explicitly store it back where it goes or send it to whatever consumer needs it.
I get the idea, and how you keep it from copying a lot of data unnecessarily. A radical approach would be using immutable types exclusively
Oh, regarding copying data - immutable collections are based on https://en.m.wikipedia.org/wiki/Persistent_data_structure - when a change is applied, you get back a reference to a new data structures where as many inner references as possible are shared with the old one. So, all the parts that didn’t change, are not copied.
For something like a Scala case class (similar to a record), o.copy(membername1 = newvalue) returns a new object, with a new membername1 reference, but all other member references are the same as the copied-from object. So it’s a shallow copy with minimal changes.
you might see how default immutability as a policy makes this more predictable and able to be reasoned about - any mutable object in an object graph that has a shared reference in a copy may surprise you by suddenly changing state.
Of course, that’s the situation everywhere, all the time, in default-mutable languages. How many people set a default value of a Python function argument to [] or {} and were baffled when things started breaking because the instance of the default value was mutated?
Clever! But I'd worry to run into performance problems when some operations effectively require copying or becoming a sort of linked list.
Although I suppose you could also be explicit if you do need it to behave in a particular way.
I like it!
There is a bit more overhead when you can’t just overwrite a value in memory. But cpu time and memory space are some of the most cheap and straightforward resources to scale up compared to engineering time to resolve consistency bugs.
There is also a performance hit associated with mutexes or locking required to ensure mutable structures are updated consistently, and many high-scale systems have moved to append-only logs and copy-on-write semantics - structures that leave already-written data in place - because mutability/locking doesn’t scale.
You are absolutely right. And that would be easier to maintain too. Thank you for the insight!
I guess, as a Scala enthusiast, it’s second nature to me - Scala incorporates immutable-by-default into its design so there are accommodations for it (.copy() methods on case classes, well-thought-out operators and methods on collections, “val” bindings, expression-oriented syntax).
It also lets you have normal OO classes and mutable vars anytime you want them, so you’re not stuck in a corner like you may sometimes be in Haskell if you don’t know the applicable FP pattern.
This helped me out quite a bit in a recent programming test for an employment screen – the challenge was to implement a time based key value store. One of the requirements that was revealed was that it needs to be able to back up and restore – this was as simple as storing the current root of the data in a list or map; it is effectively a snapshot.
That is definitely handy, and easy to make lazy if required. I might have a look into scala
Pure functional programming is often like this.
Or pragmatic functional programming, or rediscovered by “OO” programmers who realize they are messing up the Redux store bad.
Erlang/Elixir doesn't have muteable variables/types. Appending to a list would just create a "new" lists.