<div dir="ltr"><div><div><div><div><div><div>Hi Matthias, Eli, </div>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, <a href="http://java.oracle.com">java.oracle.com</a>. Chicken Scheme's site, <a href="http://call-cc.org">call-cc.org</a>, 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. </div> 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*. </div></div>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 <a href="http://racket-lang.org">racket-lang.org</a> 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. </div> </div><div>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. </div>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. <div class="gmail_extra"> <div class="gmail_quote"> On Sun, Jun 2, 2013 at 12:15 AM, Eli Barzilay <<a href="mailto:eli@barzilay.org" target="_blank">eli@barzilay.org</a>> wrote: <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div class=""><div class="h5">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. > > <a href="http://moron4hire.tumblr.com/post/51904590190/processing-and-racket" target="_blank">http://moron4hire.tumblr.com/post/51904590190/processing-and-racket</a> </div></div>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 (<a href="http://rosettacode.org/wiki/Category:Racket" target="_blank">http://rosettacode.org/wiki/Category:Racket</a>) 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: <a href="http://www.texample.net/tikz/examples/all/" target="_blank">http://www.texample.net/tikz/examples/all/</a> 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: <a href="http://barzilay.org/" target="_blank">http://barzilay.org/</a> Maze is Life! </blockquote></div> </div></div>