[racket] Processing and Racket

Hi Matthias, Eli,

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. I have a lot
of friends that have just been getting in to programming recently, either
artists through Processing, electronics hobbiests through Arduino, or
economists through, ahem, Excel. I'm still rather much a beginner in Racket
myself (though not programming, I've been a software developer for about a
decade now), but already feel like it has made me more productive as a
programmer. This article initially started as a probe out to those friends
to try to pick their brains about what it was that they liked about
Processing, et. al. It seems that there are a myriad of ways that a
platform such as Racket could be used to bring these other sources of users
into the fold, where they would find not only good things for their
purposes, but room to grow into other purposes. And if they are caught
early, they won't have the learned fear of parens or lack of curly braces.

I tried to make my comparisons between pages to be more of comparisons in
kind, rather than one-to-one comparisons. I don't think it's necessary to
mirror other sites exactly, but I think users come to expect certain things
out of documentation sites and a certain maximum level of effort to finding
those things. So in that respect, I compared the home page of Ruby to the
documentation page of Racket because they were closer to each other in
layout; I felt it made them easier to compare, while the level of detail in
the information they held was not an order of magnitude different.

Some people scatter out wide and try to get a general impression of many
options before arbitrarily whittling it down to one. I think, without an
aesthetically pleasing introduction, a potential user will doubt the
utility of the language for anything aesthetic, as well as the community's
seriousness with regards to aesthetic. Ruby-lang.org's more pleasing
appearance is one less arbitrary thing for that tab to get closed
prematurely. It's not all bad--Racket-lang.org is certainly much more
functional and pleasing than, say, java.oracle.com. Chicken Scheme's site,
call-cc.org, makes it look like it's someone's pet project; it just doesn't
look serious. Clisp.org is complete garbage; I know better than to expect
aesthetic, but that is just awful. For people who care about aesthetic,
they care about it in all aspects and would not think to throw up a
functional-but-ugly website for their project.

The Ruby On Rails community's emphasis on aesthetic is a key element that I
think brought notice of Ruby to artists, who had no larger example of
another programming language to go by. All of the designers I know who got
into programming through Ruby think Ruby is the most popular language in
the world. When you have no examples to the contrary, you don't know just
how small your world really is. I know a few people who think sites built
with Ruby are pretty because of an some innate quality of Ruby. It's easier
to prevent that from being a question rather than to try to explain it as
completely and hopelessly wrong.

I share much of Matthias' same experience with Processing, it's crufty and
it lacks much ability to build any sort of large projects with it without
completely manhandling it in such a way that you might as well give up
using it completely. I have much the same problem with Arduino (with some
dreams of writing Arduino and MSP430 code in Racket floating around in the
back of my head somewhere). It hurts me to see people using it, they
struggle to do basic things that would have been simple had the editor not
hidden it away from them.

As far as I can tell, there isn't anything functionally that Processing
does that Racket cannot. It certainly wouldn't be computational constructs.
Processing's main technical feature is bootstrapping. The checkboard
example that I cribbed from the Intro with Pictures and duplicated in
Processing is a good example in that the two examples are only
superficially doing the same thing. The Racket code is much better than the
Processing analog (though it could be better, and the Racket version could
be better, too). But the Processing version is much more prepared for going
further with drawing. It's just bootstrapped to have the drawing in a
separate window. The bootstrapping is such that everyone I know who uses
Processing for serious art installations has it running on a laptop
computer, the Processing editor open, physically clicking the "run" button
on the sketch and walking away from the PC. It either doesn't occur to them
that they could create an application that ran on its own, or the path to
learning such a thing is obscured in some way.

And there seems to be a cultural feature wherein some rather complex
animations have gotten shared around between people rather easily. I see
some of the things being done with Processing and marvel to myself in
knowing that the person who made it did it as part of their digital arts
master's thesis, and had really only spent about 2 months *learning to
program and developing the sketch at the same time*.

I think Processing took off because people could see it and share it
easily. The "pretty" things came later, the people came first. The "sketch"
mentality, and willingness to copy-pasta code, helped it spread rather much
like a virus. And while other systems have lowered the barrier to entry for
compelling, graphical programming in similar ways, people talked about
Processing in ways they didn't talk about, say, Scratch.

In my own experience, it was initially very hard to find anything about
other people doing anything with Racket, to see works as developed in their
culture. It's one thing to have some source code in a tutorial that you can
copy-pasta somewhere. It's another thing to see a fully fledged program
that lives and breathes. I like the bit on the front page with the code
snippets of interesting things. And once I learned how to browse PLaneT and
even the code in the collections, then I got to see a lot more of what
makes a program--rather than just some snippets of code--in Racket. Eli,
yes, you are right that it's not a good comparison between PLaneT and the
Processing exhibition page; and you've picked up on the point that there is
no better comparison. 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. The
volume of documentation on racket-lang.org is impressive, if you know where
to look or how to work the right search terms (that's a different issue and
it is a hard one to solve).

Trying to get my friends to try out Racket instead of Python (which I don't
see a realistic difference in difficulty between, except that Python ties
your hands once you have learned all the basic stuff) they always ask "what
is it good for?" Beginners don't understand that a general purpose language
is good for anything and everything. They need to be shown what they can
do. In that regard, if Racket had an Exhibition page of its own kind,
there'd be tons of things you could include that Processing could never
begin to, as you mentioned Eli, with the many non-graphical things that you
can do.

One thing that I noticed, that got commented on in the HN thread, was that
it seems like, even though Processing's documentation isn't as good as
Racket's, it's constantly reminding you why you're slogging through the
documentation. The TikZ link is great. Both it and the Processing site are
better about "not burying the lead". I think there are some similarly
impressive visuals in the documentation for the PLoT library, but it's
buried below the fold on a tertiary page that is itself linked to below the
fold on the documentation page.

Uhm, I think that pretty much covers everything. If I didn't directly reply
to something, I probably agreed with it and was mostly seeking to clarify
my thoughts.


On Sun, Jun 2, 2013 at 12:15 AM, Eli Barzilay <eli at barzilay.org> wrote:

> 7 hours ago, Sean McBeth wrote:
> > I had some thoughts today about Racket and apparent influences it
> > has had on Processing (and by extension Arduino). I'd be interested
> > to hear what the Racket community itself thinks of Processing and
> > the sorts of things people do with it, in comparison to Racket.
> >
> > http://moron4hire.tumblr.com/post/51904590190/processing-and-racket
>
> Some random comments (keeping Matthias's comments in mind, so I try to
> not repeat them):
>
> * When you talk about the visual design of the web pages, there are
>   actually two different things that play together here, and they are
>   also coming from very different pieces of code.  (Yes, this whole
>   point is pretty much a technicality, but it's rare to find people
>   who pay a lot of attention to it...)
>
>   The first is the actual *web* pages which are built in a more or
>   less traditional way that spits out HTML directly.  Here there were
>   some suggestions to improve the contents a few times, but nobody
>   made a more serious attempt, yet.  But really, the main point is
>   that anything can be done, provided it fulfills the basic
>   requirements of being useful enough, clear enough, appealing enough,
>   informative enough, and get most people to want to switch to it.
>   (And BTW, *many* completely tiny aspects of the web page have been
>   thoroughly discussed...)
>
>   The second system is the documentation -- which is what you see in
>   the example in your snapshot.  The thing here is that you want some
>   way to render documentation so it can fit in both HTML and PDF and
>   whatever else -- which makes the kind of rendering much more
>   restricted.  There's not much that can be done at the rendering
>   level without substantial effort, but probably some improvements can
>   be done at the CSS level.  As a side-note, the actual contents that
>   you see on the web is a weird combination of the two: taking the
>   usual web page templates and slapping it on the documentation pages
>   (which originally look like the locally-installed documentation that
>   you see in your Racket installation).
>
> * "Make more dynamic examples for beginners".
>
>   IMO, this is not a good title for what you seem to be saying...
>   It's not the dynamism, or the beginner-ism that is important in what
>   you're saying.  If it was, then I think that we have a ton of them,
>   and more are being made every day...  (See for example the
>   rosettacode thing (http://rosettacode.org/wiki/Category:Racket)
>   which is becoming a nice repository for lots of such examples, at
>   varying levels.)
>
>   Instead, I think that your main point is about the presentation of
>   the examples -- the Processing page that you point to is very
>   obviously visual.  It's actually visual enough to make me suspect
>   that it's covering a shallow language since it tries so hard to make
>   cute examples instead of focusing on contents.  Given that the
>   visual appeal is so important for you, I think that the "Quick"
>   tutorial was probably something that looks misguided: it uses
>   visuals as a way to introduce the language, but the visuals
>   themselves are just demonstrations of things you can do with a
>   language, and not a goal in their own appeal-ability.
>
>   But I don't think that there's any reason to choose either this
>   approach or that approach.  If the Processing thing works well for
>   visual people, then it's most definitely worth trying.  And it seems
>   like an itch that suits you well, so you could just as well start
>   doing that kind of a page and see how it works.  We can figure out
>   later a way to link it into the rest of the pages to make it stand
>   out: I think that there's certainly a place for more "quick try it
>   out" resources that we can point to in the "getting started" page,
>   and this would fit nicely with other such entry points.
>
> * Even more specifically, I think that it's wrong to compare Racket's
>   package page (both the new one and the planet one) to the Processing
>   "exhibition" page: the package pages that we have are mostly about
>   libraries that you can use to make stuff up, so it's not like an
>   exhibition page that demonstrates full applications -- ones that can
>   be used not only as temptation points, but as templates for people
>   to just take the source and try to tweak things and play with an
>   existing thing rather than go build something up from scratch.
>
>   But again, this is not to avoid your implicit criticism: I just take
>   it as a call for making up such an exhibition page.  BTW, I don't
>   think that this must be something that is inherently tied up to
>   things that are purely visual -- the same approach can be taken with
>   more CS-ish contents.  For example, I think that Danny's brainfuck
>   tutorial and Matthew's scratchy toy are good candidates for such a
>   thing, even when neither of them is particularly graphic.
>
> * Finally, I notice that in the HN thread that you made someone
>   pointed to this thing: http://www.texample.net/tikz/examples/all/
>   and I really think that something like that would be very nice to
>   have.  I think that it falls somewhere between the "real
>   documentation" and an "exhibition" pages -- more like a collection
>   of impressive examples and a way to quickly play with them, even
>   when the visual and instant feedback are probably not helping the CS
>   aspect of learning a language...
>
> --
>           ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
>                     http://barzilay.org/                   Maze is Life!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20130602/7b734a9e/attachment-0001.html>