[racket] Processing and Racket

(Sorry for replying to it in a way that will potentially make the
discussion longer, but I think that you're hitting an important
point...)


An hour and a half ago, Sean McBeth wrote:
> Oh, I hope it didn't come off as criticism. Yes, my intention is
> that these would be areas in which I would try to contribute,
> personally.

And in case it wasn't clear: I think that this would be a really good
thing to do.  Not only that, but even if you're a newbie (for any
value of "you" who wants to work on such a project), you'll get lots
of help in improving the code.  The result of that, I think (or hope),
is not only in making sexy-looking pages for an "exhibition" kind of
thing, but code to make such things easier to do.

Here's why I think that this is especially true for the Racket case.
Whenever you talk about "art", in probably any form (visuals, sounds,
music, beautiful web pages, animation, etc), and probably any
methodology (computer-generated content, human creations, or a
combination of both), in all of these, the main point is that you have
a person who is not really interested in the language as the main
focus, but in the end product.  This means that an ideal language is
one that is not really there -- instead, you want the description (ie,
the code) to be as close to the world you want to play with as
possible.

This is a view that many people around the Racket circles and more
generally in CS don't have.  Such people are more focused on the
actual linguistic support for making such things happen.  That's not
to say that they're ignoring it, or that what they do is irrelevant.
Take for example the concept of drawing images, and your average
popular imperative approach (draw a line from 10,20 to 30,30), or the
logo approach (move 50, left 30), and compare that to the functional
approach that you see on the "Quick" tutorial, which (roughly) has its
origins in HtDP of images as values.  You can create beautiful images
with all of these things (obviously), but the expressions that you're
using in the first two are indirect -- in order to get to your target
image, you need to think in unnatural terms.  Take for example
composing two sub-images side-by-side: with the first, you need to
think about screen positions and how they change when you draw an
image on one part of the screen instead of all of it.  With the logo
thing are a bit better, but you still need to introduce some
additional parameter to multiply all sizes by -- but you also get
additional state to maintain (be careful to have the turtle at a
specific location and pointing in a known direction; or reset it which
throws you back into the problems of the absolute world).  There's
ways to make it easier -- like having a drawing context with some
transformation matrix attached (which our dc% object do) -- but when
it's a global state you need to make sure that you deal with it
properly or you get bad results.  Compared to that, the functional
approach is not only much easier, it's doing exactly what I said
above: the code is kept closer to the goal product -- the language is
not in your way.

This is a kind of an obvious example, but there's lots of these
things, and IMO, much more than people would think.  The reason that
I'm saying that it's kind of obvious is that it's something that could
be done in any language with some care (and "recently" the world seems
to finally acknowledge the benefits of keeping things functional).  In
other cases you have features that are much harder to achieve.  Think
about some tool to make sound effects that works with a network of
filters -- it's something that can be mimicked with a conventional
language, but not well.  Or take reactive programming -- something
that is directly intended to make it easy to focus on the final
product instead of details like callbacks and events: this is even
further away from something that could be imitated in a conventional
language.

And getting back to Racket, my point should be obvious now...  Because
the language itself is very flexible, you get to not only do nice
things with it as you do with other languages -- you also get to
re-invent your own language to make things easier.  The meta-pattern
of doing this is usually very similar: you work with whatever standard
tools you have, and at some point you run into something that is way
too repetitive and verbose, or you find yourself drowning in details
to implement something that you have a simple description for.  (This
is exactly the drawing example: add a scale argument to all functions
in an existing piece of code vs "draw that at half the size".)  In
some cases, you can improve things with conventional languages, but
IMO this is risking the "when all you have is a hammer" syndrom:
there's a whole part of a potential solution space that you can't even
think of, since you're constrained by some language.

But of course I'm not naive enough to say that artists would start
using meta-tools like macros to hack their language to be more fitting
for what they want...  Instead, my "newbie" point above is that as you
work on something like this in Racket, and you don't know how to do
all of these advanced things but you do know that they're possible --
you ask about it, and will probably get some answers on how to do
things better, and maybe in rare cases the result would be some
completely new way to write code.

In any case, this is why I think that such an exhibition page might
begin as a useful thing in one direction (having example code to start
with, and having a web page with things that look like you want to try
them), but it can end up being useful in the more Rackety way.


> Every once in a while, I'll see a link come up on the listserv here
> that goes out to someone's personal Scribble site that has a lot of
> Racket examples on it. I eat those links up, they are great.

It's even more than that: there's a lot of things that are barely
mentioned and could go much farther.  You've mentioned plot as one
such library -- and there's also things like the images collection who
only a few people know how to use properly, or John's rsound library,
or slideshow (and its ability to do animations), or opengl, and many
more.  These are all things that could be used to make such nice
looking exhibition style pages, and they would also really benefit
from someone excited enough to actually play with them and do such
things.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!