3 ms·

The issue isn't computation, it is modeling. The next order of evolution for computation is quantum computation. What R Hickey is addressing is modeling. I t

by lucifer 17y ago

The issue isn't computation, it is modeling. The next order of evolution for computation is quantum computation. What R Hickey is addressing is modeling. I think the modeling problem could be alternatively addressed by unlearning the notion (conceit?) that every program is a representation/simulation (which is where (domain) state creeps in) and instead embrace a descriptive/measurement approach. Or more precisely, to accept that a program is always orthogonal to the domain model and give up chasing after the holy grail/folly of seeking a paradigm to express "reality" in computer instructions. One could argue that this is what FP is all about, but suggestion here is that the issue is fundamentally the conceptual view of the programmer and it can apply equally to OO or any other paradigm of programming. For example, the "Date" case he outlines conceptually works if one is to suspend disbelief and accept the notion that a "Date" type object is really a point in time. "How can September 22, 2009 change?" But at some level this is just semantics. Would calling the "Date" object "DateDatum" cause a similar conceptual problem? DateDatum lastUpdate = now (); //... doSomething(); lastUpdate = now();

richhickey 17y ago
> DateDatum lastUpdate = now (); //... doSomething(); lastUpdate = now(); Yes, this highlights the crux of the argument: MutableDate lastUpdate = now(); doSomething(); lastUpdate.changeInPlace(); versus: ImmutableDate lastUpdate = now(); doSomething(); lastUpdate = changedVersionOf(lastUpdate); In the first case, when someone reads lastUpdate they get a chunk of memory that could change right out from under them, with no clear recipe as to how to obtain a consistent value. In the second case, they get a consistent value they can use without worrying or synchronization. The first conflates identity and state, the second separates them. Now, all is not right with the second case, as there still aren't coordination semantics for putting new values in lastUpdate: TransactionalRef<ImmutableDate> lastUpdate = now(); or AtomicRef<ImmutableDate> lastUpdate = now(); or something similar would fix that. It's not a matter of removing mutable memory, but one of using it in a way with clear coordination semantics, other than "good luck with that".

by lucifer 17y ago

richhickey 17y ago

> DateDatum lastUpdate = now (); //... doSomething(); lastUpdate = now(); Yes, this highlights the crux of the argument: MutableDate lastUpdate = now(); doSomething(); lastUpdate.changeInPlace(); versus: ImmutableDate lastUpdate = now(); doSomething(); lastUpdate = changedVersionOf(lastUpdate); In the first case, when someone reads lastUpdate they get a chunk of memory that could change right out from under them, with no clear recipe as to how to obtain a consistent value. In the second case, they get a consistent value they can use without worrying or synchronization. The first conflates identity and state, the second separates them. Now, all is not right with the second case, as there still aren't coordination semantics for putting new values in lastUpdate: TransactionalRef<ImmutableDate> lastUpdate = now(); or AtomicRef<ImmutableDate> lastUpdate = now(); or something similar would fix that. It's not a matter of removing mutable memory, but one of using it in a way with clear coordination semantics, other than "good luck with that".