Processing and Racket(moron4hire.tumblr.com)
moron4hire.tumblr.com
Processing and Racket
http://moron4hire.tumblr.com/post/51904590190/processing-and-racket
6 comments
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.
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.
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. :-)
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. :-)
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."
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."
"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.
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.
> 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.
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.
> 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 :-)
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.
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.
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.
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.
That's a good point, there is a lot to learn from Processing's history as well as its less popular offshoots.
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!
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!
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.
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.
> 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).
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).
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.
What do you mean by "DrRacket indents better"? (Genuine question :-) and not to start a war between emacs and DrRacket)
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
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
I hadn't heard of Quack. I have Geiser installed, though now it's been a little while since I last used it (honeymoon got in the way!).
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.
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.
As the other reply points out, Quack indents exactly like DrRacket but your other reasons for sticking with DrRacket are totally valid. My primary motivation to move to emacs is that I find myself doing too much of "C-x o" in DrRacket!
In my experience Emacs with Quack (or with Geiser, or with both) indents exactly the same as DrRacket.
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.
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.
> Emacs is a bit easier to use for long typing sessions, but DrRacket indents better.
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.
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.
> 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.
Good point. This would probably be easier if schools like Northeastern had programs for technology in music/arts.
Good point. This would probably be easier if schools like Northeastern had programs for technology in music/arts.
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?
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.
Kawa plays well with Processing: http://www.gnu.org/software/kawa/
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.
Yes big pictures make your page more attractive. But this is going way too far.
I am so sorry, OMG, I apologize profusely. Please, forgive me for offending your delicate sensibilities. I knew not what I did.
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.