
Processing and Racket - moron4hire
http://moron4hire.tumblr.com/post/51904590190/processing-and-racket
======
gus_massa
The example from the Racket documentation is from "Quick: An Introduction to
Racket with Pictures": <http://docs.racket-lang.org/quick/> . I think that the
idea is to give a step by step tutorial for the beginners that introduce one
instruction at a time.

The example from the Processing documentation is from "Tutorials. A collection
of step-by-step lessons covering beginner, intermediate, and advanced topics."
<http://processing.org/learning/> It looks like a collection of unrelated
projects with very nice drawings but the learning curve is much stepper.

They are different things. Nevertheless, I like the idea of some nice visual
projects and snippets and it would be a nice addition to the Racket
documentation. (But I'm not a Racket developer.)

This reminds me the example page of one of the LaTeX drawing packages: "TikZ
and PGF examples" <http://www.texample.net/tikz/examples/all/> It creates the
"I must learn this." feeling in an instant.

~~~
moron4hire
Yes, you are correct that they are different things. I am presenting them as a
potential user's earliest visual introduction to the projects. But it seems
you've got the premise, that pictures excite people and draw them in, keep
them around. I like that, "I must learn this!"

For Racket, it takes us at least an hour of reading to get to that first "oh!"
moment, and it's not that compelling to boot. With Processing, the "look at
that!" moment is immediate and continually reinforced. It's a sideways
reminder of why you're continuing to slog through the documentation.

In terms of quality of documentation, Racket's is far superior to
Processing's. I just fear that beginners are more likely to quit before
getting very far.

~~~
gngeal
_that pictures excite people and draw them in, keep them around_

They may also excite them because doing pictures the "traditional" way
(PHP/GD, GDI, even Cairo) feels like using stone age tools, while combinator
libraries (such as Alex Shinn's fmt, for example) are a hip new thing, for a
reason.

 _Where Racket succeeds over Lisp and Scheme_

Huh, that's almost like like saying "Where Visual Studio C++ succeeds over C".
It's still on the inside, isn't it? It was a shady move on their part :-), but
I guess that whatever helps Racket helps Scheme in general as well.

Nice article, BTW. Thanks. :-)

~~~
moron4hire
From my own reading, it seems that most Schemes are almost 100% R5RS
compliant, and don't tend to do much more. When they do much more, it's
towards R6RS compliance. R6RS adds a lot, but still nowhere near the full
range of a full-package applications development language, much the same as
your analogy of VC++ vs, say, C99. And as for Lisp, I guess I'm just used to
saying Lisp and meaning Clisp, but any of the "ready for app dev, with parens
and prefix notation" languages would fit here--e.g. Clojure--as they all take
the approach that compromises in pure syntax are necessary to achieve
practical usability.

So I think that's where Racket _is_ apart from the Lisps and the Schemes: its
core language is syntactically minimalist, as a Scheme, while it strives to
have a vast standard library, as a Lisp. Three years ago, they renamed it from
PLT Scheme to Racket for this reason.

Anyway, I don't know anything about relative user bases for any of the paren
languages. I guess "succeeds" was poor word choice on my behalf. I meant more
"seems like a better idea to me."

~~~
gnosis
_"So I think that's where Racket is apart from the Lisps and the Schemes: its
core language is syntactically minimalist, as a Scheme, while it strives to
have a vast standard library, as a Lisp. Three years ago, they renamed it from
PLT Scheme to Racket for this reason."_

Chicken Scheme is in the same position. It has a pretty extensive library,
extends far beyond R5RS, avoids R6RS, and plans to be R7RS compliant.

It also has the great advantage of compiling down to C.

~~~
irahul
> Chicken Scheme is in the same position. It has a pretty extensive library,
> extends far beyond R5RS,

May be I am looking from Racket's vantage point, but chicken scheme is R5R7 +
some srfi. Compared to Racket which adds oop, myriad of languages(lazy, typed,
datalog...), units, factories...chicken looks like a pretty loyal scheme.

> It also has the great advantage of compiling down to C.

I am curious. If I am not planning cross compilation, what other advantage
compiling to C has? I can bundle the runtime to produce a standalone
executable in case of racket as well("raco exe" and "raco dist"). Chicken
produces smaller executable but that depends on libchicken. Static linking(for
distribution, either I will have to bundle libchicken or static link) produces
executable big enough that the size difference is negated.

------
mos2
At first I thought this article was how to use processing and racket together
(headline) but it seems that it advocates for the use of racket and possibly
for it to have richer documentation.

I have been using processing for many years and there are many different ways
people get into the language: 1) through artists and their works, think Casey
Reas, Aaron Koblin and the tutorials by Daniel Shiffman. 2) through specific
use cases like, I want to hook up my kinect and do x. 3) it is taught in may
experimental arts and datavis classes / tutorials. and 4) lore, I have heard
from many people "processing seems like a good fit for x" 5) an so on.

I think where processing excels or has exceled in the past is being able to
quickly pick up more experimental bits of code and libraries in Java / C++ and
put a simpler syntax in front of them. People often say, processing is really
just java. And to be specfic, it is just a preprocessor and an api/library
(core.jar) for Java. The processing IDE is okay for beginners but most people
that get serious with it move to an external text editor or IDE like Eclipse.

In my opinion it is not the simplified Java syntax that makes it great to work
with it is the philosophy that drives the api. It is very easy to start
drawing shapes in just one line of code. They create duplicate methods so you
can pass in ints, floats or another datatype without resorting to casting.

There are also a bunch of offshoots, processing.js, ruby processing, etc.
which are pretty exciting. Often the way the api is ported is not the best fit
for the new host language. I have played with a bunch of these and they are
fun but they seem to not get the kind of traction the main processing project
does.

I think if you are wanting to advocate racket more effectively you should look
at the historical linage of processing (design by numbers, data visualization
by ben fry, etc.) and you will see why so many of the learning/documentation
focuses on things that interest designers and artists. If you want to do the
same for Racket, get some artists to do some awesome work. Then have them
document it, break it apart and share it. I think this is how such a large
community has sprung up around processing and why so many projects continue to
use it today.

The other project that works really well with processing/js is toxiclibs/js.
You should consider porting it if you want to draw in some of the newer crowd.

~~~
moron4hire
That's a good point, there is a lot to learn from Processing's history as well
as its less popular offshoots.

------
BrianYesh
I'd love to see Racket "feel" doable to young and old alike who aren't
computer scientists.

A visual redesign could help. Especially a redesign of the IDE user interface.
But first some fun examples to inspire people would be best IMHO.

To find this project ASK the people you're trying to reach. Listen. Then find
a young person who's game. Ask them if they'd make a project with Racket and
write a blog post about it. There's nothing like getting inspiration from your
peers. This blog post may already exist. In other words the people who are
beginners need to help reach other beginners.

Or what about Try Racket? <https://github.com/voila/try-racket> Is this
project running online somewhere?

The power of Macros with the ease of Processing would truly be a powerful
thing!

~~~
moron4hire
Yeah, I've been looking at DrRacket pretty closely lately. I jump back and
forth between it and Emacs right now. Emacs is a bit easier to use for long
typing sessions, but DrRacket indents better. I understand that most of the
serious Racket developers use Emacs, I just haven't gotten into the flow of
using it yet. I was briefly very hardcore into Vim, but I eventually realized
that its lack of proper plugin control meant major headache was in store for
me down the road as I grew out my installation.

There are some interesting features of the toolkit that DrRacket uses to
display itself. Having done a small amount of work with formatted text editors
in the past, the controls that DrRacket has for doing its syntax highlighting
and inline-image-inclusion are very novel and advanced.

It's just all incomplete. There are things that seem like they should be
there, like a file browser, that either aren't or I'm not seeing.

I'm not sure what is going on with Try-Racket. There was talk on the listserv
about putting it on racket-lang.org, but I'm not involved in the dev group,
I'm just a user. It's probably one of the many things they'd love to have, but
have bigger fish to fry.

~~~
soegaard
> I understand that most of the serious Racket developers use > Emacs, I just
> haven't gotten into the flow of using it yet.

You would be surprised how many of the die-hard Racket programmers use
DrRacket for Racket programming. Nothing beats Emacs/Vi for normal text
editing, but since DrRacket was written with one purpose only, namely editing
Racket code it has a few tricks up its sleave.

Syntax checking while you edit your code, means that any errors you make are
highlighted immediately. This also catches misspelled identifiers.

After syntax check you can right click any identifier to rename the identifier
(which automatically changes all occurences of the identifier in the file).
The renaming even respects lexical scope.

You can easily jump to the file where a identifier is defined (I love to see
how things in the builtin libraries are written).

DrRacket will display bitmap and other image values directly in the REPL. This
must more convenient than seeing <struct: bitmap>.

You can even change the default REPL printer, to print your own user defined
values using gui elements.

One of the most impressive features is how precise the error messages are
reported. This goes for both standard errors, but not the least when macros
are involved. If you compare the error reports you get from a few errorneous
macros in DrRacket and in a standard Racket implementation, you'll see that
you can save a lot of time if you use DrRacket.

And while at it, don't forget to try the macro stepper...

Oh! And syntax objects are clicable, so you can see "inside" them. This is
gold when debugging macros.

A recent feature: String constants are now spell checked. (if you have
ispell/aspell installed).

~~~
moron4hire
Yes, those are all exactly the reasons I still use DrRacket. It seems it would
be easier to add features to DrRacket than to write plugins for Emacs/Vi,
especially considering the goals of Racket to train users, the default system
should be as best of a system as time and manpower allow.

------
jamesbritt
Might it be easier to start with Clojure and make it more like Processing,
since it can already use all the Processing Java code from the start?

~~~
moron4hire
I don't think there is anything significant from a technology standpoint that
prevents using Racket in a manner similar to Processing. It's more of a set of
priorities, a reorganization of documentation, a small amount of
bootstrapping. Frankly, it's probably nothing more than establishing a
presence of the community's projects on the main language site.

------
keithjohara
Kawa plays well with Processing: <http://www.gnu.org/software/kawa/>

------
breser
What a horrible page design. The content takes up less than 30% of the page.
And devotes the rest of the real-estate to a picture that has nothing really
to do with the article.

Yes big pictures make your page more attractive. But this is going way too
far.

~~~
moron4hire
I am so sorry, OMG, I apologize profusely. Please, forgive me for offending
your delicate sensibilities. I knew not what I did.

