Re: More functional Quil

2014-03-19 Thread J . Pablo Fernández
Hello Nikita, I think Quil should definitely provide a way to write functional style processing code. At the moment, my knowledge of both Clojure and Processing is not enough to evaluate these solutions. I'm certainly going to write my code following some of this and if someone proposes a solut

Re: More functional Quil

2014-03-10 Thread Gary Trakhman
The complicated-looking semaphore code was adapted from http://stackoverflow.com/a/5275254/2559313 . I think some issues with other alternatives are in there. On Mon, Mar 10, 2014 at 1:27 PM, Nikita Beloglazov wrote: > Lee, > > I think question about managing/updating state in quil pop ups prett

Re: More functional Quil

2014-03-10 Thread Nikita Beloglazov
Lee, I think question about managing/updating state in quil pop ups pretty frequently and many people expect quil to have built-in tools to do it in functional style. And using atoms to update state may feel hacky. I think this tools should exist and quil 2.0 is a good time to address the issue. Y

Re: More functional Quil

2014-03-09 Thread Gary Trakhman
FWIW, I've got an example of a decoupled update/draw loop here: https://github.com/gtrak/quilltest/blob/master/src/quilltest/balls.clj On Sun, Mar 9, 2014 at 10:16 PM, Lee Spector wrote: > > FWIW I'm not crazy about these suggestions because they seem to me to be > mostly cosmetic, and actually

Re: More functional Quil

2014-03-09 Thread Lee Spector
FWIW I'm not crazy about these suggestions because they seem to me to be mostly cosmetic, and actually negative if they end up leading to multiple incompatible modes of operation. The Processing model seems to me to be intrinsically imperative, and it's also well-known by lots of people and eas

Re: More functional Quil

2014-03-09 Thread Nikita Beloglazov
Hi Pablo You can find similar old thread on Quil github repo: https://github.com/quil/quil/pull/19 It may serve as good background what other people considered to make Quil more "functional-style". I like your suggestion though I would split your :draw function to 2 fns: an :update function, w

Re: More functional Quil

2014-03-09 Thread Laurent PETIT
2014-03-09 14:21 GMT+01:00 J. Pablo Fernández : > > > On Sunday, March 9, 2014 1:02:52 PM UTC, Laurent PETIT wrote: >> >> Hello, >> >> To be honest I don't see any fundamental difference between your first >> attempt and the improvement: both share the fact that the mutation of the >> state happen

Re: More functional Quil

2014-03-09 Thread J . Pablo Fernández
On Sunday, March 9, 2014 1:02:52 PM UTC, Laurent PETIT wrote: > > Hello, > > To be honest I don't see any fundamental difference between your first > attempt and the improvement: both share the fact that the mutation of the > state happens within the draw function. So in both cases, you have a

Re: More functional Quil

2014-03-09 Thread Laurent PETIT
Hello, To be honest I don't see any fundamental difference between your first attempt and the improvement: both share the fact that the mutation of the state happens within the draw function. So in both cases, you have a temporal coupling between updating the state of the app and rendering a new v

More functional Quil

2014-03-09 Thread J . Pablo Fernández
Hello Clojurians, I'm starting to play with Processing and I want to use my favorite programming language for it, so I started using Quil. The problem is that Processing has a imperative architecture and makes my Clojure code look bad. For those that don't know Pr