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.
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.
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:
- 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.
- 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).
- 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.
- 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 :)
Philipp
On 03.06.13 18:13, Sean McBeth wrote:
Okay, I'll draw up a plan soon and start documenting some of these
ideas better.
On Sun, Jun 2, 2013 at 11:28 PM, Jay Kominek <[email protected]
<mailto:[email protected]>> wrote:
On Sun, Jun 2, 2013 at 10:00 AM, Sean McBeth
<[email protected] <mailto:[email protected]>> wrote:
> So, an Exhibition page would have a curated selection of
community entries.
> There'd always be a sidebar of highly-ranked community examples.
Based on the response the Rosetta Code effort got, you could probably
just put up a web page describing a bunch of cool examples you wish
you had, mention it here, and get other people to produce all the
code.
I had fun with the piece I (re)did for the recode project
(http://recodeproject.com/), so you could even put up a picture of the
output you want and I'd be tempted to produce code that could
duplicate it.
--
Jay Kominek
____________________
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
