<div dir="ltr">I can't let this thread pass without mentioning Fluxus<div><a href="http://www.pawfal.org/fluxus/documentation/">http://www.pawfal.org/fluxus/documentation/</a> </div></div><div class="gmail_extra"><br clear="all">
<div><div dir="ltr">--<br><a href="http://www.degabrielle.name/stephen" target="_blank">Stephen De Gabrielle</a><div><br></div></div></div>
<br><br><div class="gmail_quote">On Mon, Jun 3, 2013 at 11:03 PM, Matthias Felleisen <span dir="ltr"><<a href="mailto:matthias@ccs.neu.edu" target="_blank">matthias@ccs.neu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><br><div><div class="im"><div>On Jun 3, 2013, at 5:45 PM, Philipp Dikmann wrote:</div><br><blockquote type="cite"><span style="border-collapse:separate;font-family:'Lucida Grande';font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium">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).<br>
</span></blockquote><div><br></div><div><br></div></div><div>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:</div>
<div> -- images from the teaching languags</div><div> -- slideshow </div><div> -- the raw graphics box underneath it all </div><div>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). </div>
<div class="im"><div><br></div><div><br></div><div><br></div><br><blockquote type="cite"><span style="border-collapse:separate;font-family:'Lucida Grande';font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:-webkit-auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium">- 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 :)</span></blockquote>
</div></div><br><div><br></div><div>Thanks. Errors have been a key focus of the project from its conception. </div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-- Matthias</div><div><br></div></font></span></div>
<br>____________________<br>
Racket Users list:<br>
<a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a><br>
<br></blockquote></div><br></div>