Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Answer to part 1: Immutable objects don't by themselves support anything like "merging" to allow the results of two thread's updates to be combined. There are two major strategies for that: the pessimistic and the optimistic. If you're pessimistic, you assume it's quite likely that two threads will want to update the same piece of data at the same time. So you employ locking, such that the second thread will freeze up until the first thread says it has finished. If you're optimistic that this will happen only rarely, you let both threads work on their own logical copy of the data. The one that finishes first supplies the new version, and the other has to start again from the beginning - only now it starts from the results of the first thread's changes. This expensive restarting only happens occasionally though, so over all it performs better due to the lack of locking (although this is only true if your optimism was well placed about how rarely a clash occurs).</p> <p>Part 2: Pure functional stateless languages do not really eliminate that problem. Even a pure Haskell program can have state associated with it. The difference is that stateful code has a different return type. A function that manipulates state is expressed as a sequence of operations that operate on an object representing that state. In an absurd example, consider the computer's file system. Every time a program modifies the contents of a file (even by a single byte) it has created a new "version" of the entire file system. And by extension, a new version of the entire universe. But let's focus on the file system for now. Any other part of the program that examines the file system may now be affected by that modified byte. So Haskell says that functions operating on the file system must effectively pass around an object representing a version of the file system. Then because this would be tedious to manually deal with, it turns the requirement inside out and says that if a function wants to be able to do IO, it must return a sort of container object. Inside the container is the value the function wants to return. But the container serves as evidence that the function also either has side-effects or can see side-effects. It means that Haskell's type system is able to distinguish between functions-with-side-effects and "pure" functions. So it helps to contain and manage the statefulness of code, without really eliminating it.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload