Processing and Racket
moron4hire.tumblr.com
moron4hire.tumblr.com
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.
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.
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. :-)
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."
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.
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.
The comparison with Visual C++ isn't apt. Visual C++ for the most part is libraries over C++(not language core).
People will complain either ways. When they were PLT Scheme, people cribbed about non-compliance with rnrs. Also, "it's still on the inside" has a threshold. Objective-C and C++ have C inside, but neither of them are C. Racket has added so much to r5rs that it should be considered a scheme derivative, and not a scheme.
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.
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!
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.
May be Racket has a very small mindshare when it comes to Emacs users, otherwise someone would have written a better indentation mode by now.
> 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.
I am not sure what you mean by proper plugin control, but pathogen and vundle have existed for some time now. I use terminal vim running under screen with a repl open in another screen window and some vim plumbing to send text to the repl for my racket experimentation.
Just this week I made the switch from MIT/GNU Scheme to Racket for solving SICP exercises. Have been using DrRacket but as I am writing this I am in the middle of configuring emacs for Racket development. So far I have installed Quack and it works reasonably well. Didn't really find any differences between it's indentation and DrRacket's. Next, I will be installing Geiser that will bring the inline image support for working with the picture language exercises.
Quack: http://www.neilvandyke.org/quack/
Geiser: https://github.com/jaor/geiser
DrRacket indents things rather intelligently. If you newline after the first-position element, it will indent things just past the paren before the first-position element, so that everything lines up in a list. If you newline after any of the other elements first, it will line them up ahead of the function name. But really, most importantly, it seems to understand constructs like "(let ([x 3])\n (displayln x))" should line up the displayln call under the let keyword, not under the value expressions.
Emacs, on the other hand, understands varying levels of scope by matching parens, but just indents things a set number of spaces. I fully admit that this could just be my own ignorance of how to work Emacs. But as mentioned, lacking the Macro stepper, the live syntax checking, and many other features, it just didn't seem worth it to track down this one annoyance.
That's not to say there isn't some corner case where they differ, but it sounds like you're noticing more than that. Try Quack or Geiser.
That's also not to say DrRacket is bad. It feels a bit slower to me when typing, than Emacs. But it has all the cool tools others mentioned. You can also use Emacs most of the time, and use DrRacket for the tools.
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).
Good point. This would probably be easier if schools like Northeastern had programs for technology in music/arts.
Yes big pictures make your page more attractive. But this is going way too far.