I also value pragmatism and code simplicity over everything else, so
I'd say: keep your "shared" state into "shared" refs, write down a few
functions to manage such a state and limit every state changing
activity to them, writing everything else, in particular all
algorithms and logic, in purely functional style.

Given Clojure facilities to manage shared state (that is, its STM), I
think this approach to be pretty Clojure-style and effective too.
Also, well-known Clojure programmers seem to use it, i.e.:
https://github.com/amitrathore/swarmiji
And, the author of the previously cited articles wrote another piece
about that, which seems to be more pragmatic:
http://prog21.dadgum.com/54.html

BTW, I'd also like to know what others think too.
Cheers,

Sergio B.

On Thu, Jul 28, 2011 at 8:44 AM, Oskar <oskar.kv...@gmail.com> wrote:
> On Jul 27, 5:07 pm, Benny Tsai <benny.t...@gmail.com> wrote:
>> Hi Oskar,
>>
>> I just came across this article yesterday, which I thought you may find
>> useful.  It's a 4-part series where the author discusses his experience
>> implementing games in a functional style:
>>
>> http://prog21.dadgum.com/23.html
>>
>> He was using Erlang, but I think many of the same ideas apply here as well.
>>  Hope this helps.
>
> Hm it seems like what he did was a bit extreme. Would you do it that
> way? In Clojure you could just use atoms and all would be well, right?
> My game is going to be quite a bit more complex than Pac-Man, the game-
> state is going to be way more complex.
>
> I have a hard time coming up reasons why this would be better. My
> function that I wanted that checks if two characters are close enough
> to each other is just a very small part of my game. And I could make
> just that function fuctional and my list of benefits would be nil.
> Sure, immutable data structures is great, for example, but in this
> case, I don't see how making the game purely functional would make the
> code better. But I could be wrong of course. It's kind of hard to
> imagine. If enough people say "Yes, do it!" I might try it.
>
> --
> 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



-- 
Sergio Bossa
http://www.linkedin.com/in/sergiob

-- 
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

Reply via email to