this post was submitted on 23 Mar 2025
266 points (98.2% liked)
LinkedinLunatics
6544 readers
3 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).
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
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
That is definitely handy, and easy to make lazy if required. I might have a look into scala
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!
You are absolutely right. And that would be easier to maintain too. Thank you for the insight!
Pure functional programming is often like this.
Erlang/Elixir doesn't have muteable variables/types. Appending to a list would just create a "new" lists.