[racket] Processing and Racket

Hi all,

I've been keeping half an eye on this thread, a lot of people (me
included) use fluxus/racket for teaching programming to artists, and we
have a growing community of live coders who use it in performance
settings (VJing and making music too).

One of my current projects with fluxus is to use (graphical) scheme
programming to control bots in minecraft style environments:
http://www.pawfal.org/dave/blog/2013/03/building-pyramids-with-code-composition/

This is partly born from a frustration with processing and particularly
scratch (due to 2D graphics and it's imperative focus) which I'm
currently teaching at a local primary school. I'll be trying this out on
them soon!

cheers,

dave

On 04/06/13 02:23, Sean McBeth wrote:
> Incidentally, I had someone reply to my tumblr blog with a link to
> fluxus (wait, was that you?). There are some interesting things there. I
> like how it showcases people who are using it.
> 
> On Jun 3, 2013 8:34 PM, "Stephen De Gabrielle"
> <stephen.degabrielle at acm.org <mailto:stephen.degabrielle at acm.org>> wrote:
> 
>     I can't let this thread pass without mentioning Fluxus
>     http://www.pawfal.org/fluxus/documentation/ 
> 
>     --
>     Stephen De Gabrielle <http://www.degabrielle.name/stephen>
> 
> 
> 
>     On Mon, Jun 3, 2013 at 11:03 PM, Matthias Felleisen
>     <matthias at ccs.neu.edu <mailto:matthias at ccs.neu.edu>> wrote:
> 
> 
>         On Jun 3, 2013, at 5:45 PM, Philipp Dikmann wrote:
> 
>>         but when the problem is always simply 'reproduce this image',
>>         a single language still allows multiple interesting ways of
>>         thinking about it (esp. considering the idea of 'language' in
>>         the Racket context :P), and even better: demonstrate,
>>         graphically, what that particular way of thinking entails
>>         (e.g. like the 'experimental translations' of the Recode Project).
> 
> 
>         This suggests an interesting comparative programming project.
>         Within Racket you can easily show off a range of programming
>         style for just this "produce this image" special-purpose domain:
>          -- images from the teaching languags
>          -- slideshow 
>          -- the raw graphics box underneath it all 
>         and in each case, we can show off a functional and an OO
>         approach. Indeed, we might even be able to show off a CONSTRAINT
>         programming approach (make an image that satisfies the following
>         constraints). 
> 
> 
> 
> 
>>         - One last thing: In my experience, errors are more plentiful
>>         in Processing, because keeping track of state gets difficult.
>>         However, in an artistic / experimental setting, errors can be
>>         very productive. I've had considerably less 'happy accidents'
>>         in Racket, because there are very few accidents at all;
>>         'breaking things' must be done more purposeful. I understand
>>         this is the result of continued efforts to make reasoning
>>         about Racket programs as effortless as possible, so hats off
>>         to that :)
> 
> 
>         Thanks. Errors have been a key focus of the project from its
>         conception. 
> 
>         -- Matthias
> 
> 
>         ____________________
>           Racket Users list:
>           http://lists.racket-lang.org/users
> 
> 
> 
>     ____________________
>       Racket Users list:
>       http://lists.racket-lang.org/users
> 
> 
> 
> ____________________
>   Racket Users list:
>   http://lists.racket-lang.org/users
>