<html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> Chipping in another 2 cents, I'd like to second Matthias, Eli & Jay in finding the idea quite splendid! Narrowing the focus of a documentation/community project on graphical output is a promising way to encourage more conversation about Racket.<br> <br> Being a design professional with little CS education myself, and having struggled with languages all the way back to Logo in High School, I am in general very satisfied with the state of documentation on Racket, considering its vast range of applications, and even the way that graphical output is incorporated - because it has similar potential to blow your mind like the notorious 'picture language' of SICP, at least for non-CS staff living most of their lifes in a Kingdom of Nouns.<br> On the other hand, some experience in teaching impatient design students (me being the first) the bare minimum to get anything on the screen made me appreciate the perks of Processing & its hands-on documentation to that end. I'd like to add some points of interest to the distinction of Racket and Processing:<br> <br> - Processing, out of the box, is tailored to a very specific domain: drawing images at a fixed framerate. This is of course incredibly instrumental in demonstrating & sharing the language, in bite-sized code snippets, with colorful images alongside. It's an interesting challenge to cast a similar harness for Racket, which quite a few of the (educational) languages shipping with Racket have already done, so there's an abundance of good ideas on that.<br> <br> - The techniques that are motivated by Processing - object orientation, imperative style - are a nice fit for drawing images, because they are so immediately analogous to drawing an image in the real world - picking tools, executing steps, arranging discrete objects on a flat canvas. In contrast, the expressivenes of Racket is more abstract. That might prove to be a nice segue for showing off different approaches to the same 'problem' - with each 'solution' talking about it in different concepts, enabling different treatments & developments. Rosetta Code does it by contrasting different programming languages on a wide range of problems; 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> <br> - An aside: the development of Processing code, especially in the Processing Environment, is rather rigid (write-compile-run-repeat). Racket enables a more organic approach with DrRacket, the REPL etc. I wonder if the Processing culture of fire-and-forget has implications for the way that code sharing is handled and accepted by the community, and wether Racket would inherently motivate a completely different approach; but that might be a bit far-fetched.<br> <br> - 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 :)<br> <br> <br> Philipp<br> <br> <br> <div class="moz-cite-prefix">On 03.06.13 18:13, Sean McBeth wrote:<br> </div> <blockquote cite="mid:CAJgfiauU8kFsckqmzicYT=BsUPE=HQVKaKdyTcxZ4YGUVKTxWA@mail.gmail.com" type="cite"> <div dir="ltr">Okay, I'll draw up a plan soon and start documenting some of these ideas better.<br> </div> <div class="gmail_extra"><br> <br> <div class="gmail_quote">On Sun, Jun 2, 2013 at 11:28 PM, Jay Kominek <span dir="ltr"><<a moz-do-not-send="true" href="mailto:kominek@gmail.com" target="_blank">kominek@gmail.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="im">On Sun, Jun 2, 2013 at 10:00 AM, Sean McBeth <<a moz-do-not-send="true" href="mailto:sean.mcbeth@gmail.com">sean.mcbeth@gmail.com</a>> wrote:<br> > So, an Exhibition page would have a curated selection of community entries.<br> > There'd always be a sidebar of highly-ranked community examples.<br> <br> </div> Based on the response the Rosetta Code effort got, you could probably<br> just put up a web page describing a bunch of cool examples you wish<br> you had, mention it here, and get other people to produce all the<br> code.<br> <br> I had fun with the piece I (re)did for the recode project<br> (<a moz-do-not-send="true" href="http://recodeproject.com/" target="_blank">http://recodeproject.com/</a>), so you could even put up a picture of the<br> output you want and I'd be tempted to produce code that could<br> duplicate it.<br> <span class="HOEnZb"><font color="#888888"><br> --<br> Jay Kominek<br> </font></span> <div class="HOEnZb"> <div class="h5">____________________<br>   Racket Users list:<br>   <a moz-do-not-send="true" href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a><br> </div> </div> </blockquote> </div> <br> </div> <br> <fieldset class="mimeAttachmentHeader"></fieldset> <br> <pre wrap="">____________________ Racket Users list: <a class="moz-txt-link-freetext" href="http://lists.racket-lang.org/users">http://lists.racket-lang.org/users</a> </pre> </blockquote> <br> </body> </html>