Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
zacg30317yI definitely agree that immutable state is more reliable and easier to reason about, but the thing is, programming with mutable state is so much easier. Also, mutable programs can be scaled quite well when given lots of cores, if they’re written well
-
zacg30317y@Nanos
In a mutable language, you could write this:
a = 5
a = 2
But in a language like Haskell for example, it would result in an error since you can’t reassign to a variable -
koin5887yExplanation Lacks a bit. Strings in java are immutable but could be reassigned. I think important is was happens in memory? Example
String hehe = "hehe";
Creates a new string in the String constant pool
hehe = "XD";
Creates also a new string in the string constant pool
The same on heap if you use new String ();
Where int a = 5; a = 6; just changes values and immutable String creates new memory space and references -
Wack63117yI actually agree with the statement. However I don't think it will happen to soon. We live in a cozy Python/JS/<PHP7.1 world, where we don't even have to assign types to a variable. So while I belive scientific applications or critical infrastructure will work that way, the majority of programmers won't.
-
NullIsEvil67yThe problem is not so much mutable state, but shared mutable state. As long as you don't share mutable references/pointers between threads, there is no problem.
-
koin5887y@NullIsEvil yes totally agree in most languages threads share heap and bring their own stack with that in mind a lot of problems could be avoided
-
Wack63117yThe advantage of immutable states is, that compilers can optimize it to multithreaded without much risk.
-
mngr9407yI am an embedded developer, i'd LOVE to use functional programming, but everything here is a side effect, and I change the processor/controller quite often... I cannot make a compiler for every possible target :/
-
As one of my supervisors once said: "A computer without mutable state is just a glorified electrical heater."
-
@AlexDeLarge what do you mean?
I totally agree with this supervisor on this topic. -
koin5887y@TempestasLudi yes just because something is dangerous to use and requires some understanding it isn't bad or we shouldn't have it
-
Wack63117y@TempestasLudi take a look at barrel fish os. It's not production ready (yet, although a microsoft research team actually tried it and got office runnig on it and used it as a "show off" on a conference) and probably will never be! It is a research os. But focused on multiprocessors, on immutable states and a lock free kernel
Edit: for the lazy ones: http://www.barrelfish.org (I'm not saying this is "it" or something like that. Just an interesting piece of research that could be part of the future. -
@AlexDeLarge I know. Once wrote a small interpreter for a lisp-like language in a course. Only immutable stuff (using "var", Scala, was banned).
The point is that at some level you'll need to mutate something. Although processors and memory units are replacable, their mutability is quite convenient. -
kiki353297yOhai.
I sincerelly don't understand why did frontenders reinvented versioning that's been around for 30 years straight and called that immutability.
There's nothing magical over here. State is mutable, otherwise your apps would be stuck in the same state, forever.
But version of the state is immutable by default. And what they call "immutability" is just persistence without version tracking convention.
Using true versioning instead of "immutability", you can achieve CRDT state sharing which guarantees that shared state is exactly the same on every connected machine even if there's no time synchronization. And it can be restored even after some downtime. The actions order is never messed up.
Further reading:
https://en.m.wikipedia.org/wiki/...
https://en.m.wikipedia.org/wiki/... -
kiki353297yYes, that's quite advanced topic, but the possibilities are stunning. Just look at gun.js. I've used it for my graduation project, sort of live collaborative diagram editing tool, and it worked just fine.
-
kiki353297yAnd yes, uncontrolled mutable state is the root of all evil. Just look at C++ style OOP, when every instance has its own state, and the whole app state is spread around instances, damn hard to maintain.
Quick maffs:
With N instances given, if you want to ensure that each instance can communicate to others, that will be N^2 with spread state. And when every single instance mutates others' state, this will quickly lead to utter mess.
And with stateless instances, that will be C (constant): every instance can write to the storage while others can subscribe to exact fields they want. You only need two methods: "modify" and "subscribe"
Oh, we've just reinvented Redux and/or Clojure atoms though. -
kiki353297yApply that pattern, put persistent data structures to let it be efficient, and you'll get undo/redo for free. Just pass the state object and voila, the whole app neatly travels back in time. You can even stream the whole state or its actions through websockets to make it collaborative. That's what Logux does.
Related Rants
"In programming mutable state is evil. In future programming we need to avoid mutable state because we will throw cores at our code which will work on it in parallel."
debate.init();
rant
mutability
immutable
multi core
future programming
state