"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();

I 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

@Nanos like in python, for example, where you can reassign variables

@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

Explanation 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

I 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.

@Wack most of scientific computing I have seen and worked on was in C and openmp or MPI with openACC to minimize the deadlock and race condition risks.

The 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.

@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

The advantage of immutable states is, that compilers can optimize it to multithreaded without much risk.

Learn Haskell. Or don't. I will for sure.

I 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.

@TempestasLudi yes just because something is dangerous to use and requires some understanding it isn't bad or we shouldn't have it

@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.

@Nanos holy... Written entorely in assembly?

@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.

Ohai.

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/...

Yes, 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.

And 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.

Apply 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.