On Oct 14, 2011, at 8:48 AM, Timothy Baldridge wrote: > On Fri, Oct 14, 2011 at 7:58 AM, pistacchio <pistacc...@gmail.com> wrote: >> I'm implementing a litte "game" thing in Clojure. So far I'm passing >> around a "world status" object among functions. It is very >> "functional" and I can simulate any moment of the game my simply >> feeding the system with a made-up world state. > > > Well you're going to get a slight performance boost by going to a > controlled mutable state as you won't have to modify your entire state > tree whenever any object changes, you'll only have to modify the part > that changes. But what I see as the biggest benefit to using mutable > state, is being able multi-thread your program. Running everything on > one thread is soooo 20th century. ;-)
Clojure's data structures are designed to support efficient creation of modified versions via structural sharing; e.g. a map created via assoc shares much of the same memory as the map from which it was created. So unless you're building the entire game state from scratch each time, you don't have to worry about modifying the "entire" state tree as opposed to a small portion of it. Not saying you won't get any performance boost from using mutation, just that the performance of the functional solution is not nearly as bad as you might think. As always, profiling trumps guessing about performance bottlenecks. On Oct 14, 2011, at 7:58 AM, pistacchio wrote: > Since Clojure has a very sophisticate system for managing state > (references, atoms...) I wanted to know what is the more idiomatic way > of programming Clojure, whether to use its system or to stick to a > more functional approach. Don't feel you have to just use atoms etc just because they're there. Clojure is basically a functional language; mutability is limited to a few specific constructs precisely because idiomatic Clojure code is expected to be nearly all functional, with mutability used only as necessary. Performance might be one reason to use mutability (though see above); another might be that some framework you're using more-or-les requires it. For example, Java's Swing has you provide a callback function that is supposed to know how to draw your app's content. But Swing can't pass your current world state to your callback, so the callback needs to be able to access the world state in some other way. A "global" atom holding the world state is a pretty natural solution in that case. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
