Ok this may sound weird but it's the best i could come up with on the weekend 

Its more than atoms when it comes to ClojureScript. The MUTATION GALORE that is 
the DOM cannot be made immutable via Virtual DOM or any other abstraction 
because in the end there is a single visual artifact whose wave function (using 
that other familiar analogy) has collapsed and whose state is singular in time 
and space. Same with anything that engages with nature (human users) which 
works via mutation aka change over time. 

If we split the program into the part that engages with the user  and the part 
that observes then the latter can be made purely immutable while the former 
will not have an identity crisis, as it will be based purely on mutation and 
reflects the mutation driven environment its engaging with. 

This thinking is based on the educated opinion that if there is mutable shared 
state then mucking around with immutables is not gonna help much, not saying 
it's useless per se but something that provides potentially false assurance is 
more dangerous than one that doesn't provide those assurances 

But inmutability has a rightful place in the part of the program that observes 

I think! Not sure. Maybe. Hmm.

Sent from my iPhone

> On Jul 11, 2015, at 4:02 PM, Gary Verhaegen <[email protected]> wrote:
> 
> The point is to have controlled, slightly exceptional mutation, instead of 
> rampant mutation.
> 
> In other words, you as a snippet of code that calls other code know whether 
> you pass in a mutable value (an atom), and so you need to be careful, or you 
> pass in an immutable valie (anything else from the Clojure world) and you can 
> count on the code you're calling not to modify it.
> 
> In the particular case of JavaScript, this distinction is really great for 
> callbacks, among others.
> 
> Clojure recognizes that mutation is both useful and complex, so it needs to 
> be available, but not the default.
> 
>> On Sunday, 12 July 2015, gvim <[email protected]> wrote:
>>> On 11/07/2015 21:54, Marc Fawzi wrote:
>>> What I was trying to say (I think) is the need for shared mutable state
>>> be it in an atom or in a DOM tree puts in doubt the idea that
>>> immutability in and by itself is of great benefit.
>>> 
>>> I'm trying to find out how immutability and mutability can co-exist
>>> without undermining each other conceptually. I am sure there are many
>>> sane patterns.
>> 
>> I also had my doubts about this, though from a less advanced perspective. 
>> The same could be said of mixing Clojure and Java, though, so you're really 
>> questioning the whole edifice of Clojure not just its application with atoms 
>> in Javascript.
>> 
>> gvim
>> 
>> 
>> -- 
>> Note that posts from new members are moderated - please be patient with your 
>> first post.
>> --- You received this message because you are subscribed to the Google 
>> Groups "ClojureScript" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected].
>> To post to this group, send email to [email protected].
>> Visit this group at http://groups.google.com/group/clojurescript.
> 
> -- 
> Note that posts from new members are moderated - please be patient with your 
> first post.
> --- 
> You received this message because you are subscribed to the Google Groups 
> "ClojureScript" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/clojurescript.

-- 
Note that posts from new members are moderated - please be patient with your 
first post.
--- 
You received this message because you are subscribed to the Google Groups 
"ClojureScript" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/clojurescript.

Reply via email to