Multi-paradigm programming is often required in complex scenarios and one design pattern does not fit all despite it being of course great! (and limited)
For example, deeply integrating D3 with anything like React has been proven a terrible idea over and over again since D3 is in a way a DOM differ with datasets being the state, and the re-inventing D3 transition subsystem using something like React.tweenState would be an adventure in itself. So then when you arrive at the conclusion that the immutable/reactive pattern would require you to do far more work that will blow up all your deadline commitments you may fall back on the language itself but if the language has no concept of immutability and only way is thru a design pattern that is at conflict with your current libraries then you find yourself having to reinvent the wheel that is easiest to reinvent and that would have the most universal usefulness, which in this case was adding some sort of immutability to JS. Then these questions came up! What if ClojureScript had to be multi-paradigm in some complex project then how would you deal with the fact that mutable things like DOM and atoms can be accessed not only thru the sane design pattern of React/Flux but also directly. Mutative accidents will happen and Immutability that is built into the language won't help.. That is, when you think beyond the React/Flux paradigm because you have to do that sometimes then things start to look shaky. I'm still thinking about it. Sent from my iPhone > On Jul 13, 2015, at 3:11 AM, Gary Verhaegen <[email protected]> wrote: > > Have you already seen the "Are we there yet?" presentation from Rich Hickey? > I found it quite enlightening on the subject of immutability. > > With regards to the dom, I think it's more about having the application state > at any point in time being represented by an immutable data structure, and > modeling time as a succession of these structures, with atoms providing the > link between these successive structures, or the identity. If the dom only > contains derived state, then we don't really care that it's mutable, and we > can actually abstract that mutation away like om and the other react wrappers > are doing. > > As to how to translate all of that to JS, well... I'd look into > omniscient.js, but I've only taken a cursory glance at it. At this point all > I can say about it is that if I had to use JS, that would be the first > library I would evaluate. > >> On Sunday, 12 July 2015, Marc Fawzi <[email protected]> wrote: >> In JS we don't have native persistent data structures and the ES6 const >> keyword only gives us shallow immutability without any of the gains of >> persistent data structures. ImmutableJS is nice but existing libraries >> expect regular JS maps and arrays. So what i have been thinking is to use >> ES6 Proxy with a Frozen reference and that way all writes go to the Proxy >> object while all reads come from a diffing operation on Proxy and original >> object, thus giving us some form of immutability. For now, however, I've >> implemented it as deep freezing the referenced object and using HTML5 >> structured cloning algorithm for when a mutable clone is desired. This is >> admittedly half assed but it allows me go cleanly isolated all shared >> mutable state into an atom like structure in JS. So far so good and it has >> helped a lot with my D3 app since D3 charts can be 2000 lines long with a >> ton of global var use, which makes them very hard to debug, which is now all >> eliminated. >> >> Without that i couldnt implement the great ideas I'm learning from >> ClojureScript in my JS work. >> >> Sent from my iPhone >> >> > On Jul 12, 2015, at 8:44 AM, Matt Ho <[email protected]> wrote: >> > >> > What problem are you looking to solve here? >> > >> > My take is that immutability is a design pattern rather than something >> > enforced by the language constructs. If you want the language constructs >> > to enforce immutability, Haskell is an excellent choice. Even Elm (a >> > Haskell like language) treats immutability as a design pattern rather than >> > a language construct. >> > >> > For me, immutability is a design pattern, much like FP, intended to >> > simplify how we reason about apps. I think Om, Reagent, Flux, and Elm are >> > all excellent examples of the power of immutable thinking. For >> > comparison, the mutable frameworks would be Ember, Angular, and Backbone. >> > >> > M >> > >> > -- >> > 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. -- 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.
