(Sorry for replying to it in a way that will potentially make the discussion longer, but I think that you're hitting an important point...)
An hour and a half ago, Sean McBeth wrote: > 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. And in case it wasn't clear: I think that this would be a really good thing to do. Not only that, but even if you're a newbie (for any value of "you" who wants to work on such a project), you'll get lots of help in improving the code. The result of that, I think (or hope), is not only in making sexy-looking pages for an "exhibition" kind of thing, but code to make such things easier to do. Here's why I think that this is especially true for the Racket case. Whenever you talk about "art", in probably any form (visuals, sounds, music, beautiful web pages, animation, etc), and probably any methodology (computer-generated content, human creations, or a combination of both), in all of these, the main point is that you have a person who is not really interested in the language as the main focus, but in the end product. This means that an ideal language is one that is not really there -- instead, you want the description (ie, the code) to be as close to the world you want to play with as possible. This is a view that many people around the Racket circles and more generally in CS don't have. Such people are more focused on the actual linguistic support for making such things happen. That's not to say that they're ignoring it, or that what they do is irrelevant. Take for example the concept of drawing images, and your average popular imperative approach (draw a line from 10,20 to 30,30), or the logo approach (move 50, left 30), and compare that to the functional approach that you see on the "Quick" tutorial, which (roughly) has its origins in HtDP of images as values. You can create beautiful images with all of these things (obviously), but the expressions that you're using in the first two are indirect -- in order to get to your target image, you need to think in unnatural terms. Take for example composing two sub-images side-by-side: with the first, you need to think about screen positions and how they change when you draw an image on one part of the screen instead of all of it. With the logo thing are a bit better, but you still need to introduce some additional parameter to multiply all sizes by -- but you also get additional state to maintain (be careful to have the turtle at a specific location and pointing in a known direction; or reset it which throws you back into the problems of the absolute world). There's ways to make it easier -- like having a drawing context with some transformation matrix attached (which our dc% object do) -- but when it's a global state you need to make sure that you deal with it properly or you get bad results. Compared to that, the functional approach is not only much easier, it's doing exactly what I said above: the code is kept closer to the goal product -- the language is not in your way. This is a kind of an obvious example, but there's lots of these things, and IMO, much more than people would think. The reason that I'm saying that it's kind of obvious is that it's something that could be done in any language with some care (and "recently" the world seems to finally acknowledge the benefits of keeping things functional). In other cases you have features that are much harder to achieve. Think about some tool to make sound effects that works with a network of filters -- it's something that can be mimicked with a conventional language, but not well. Or take reactive programming -- something that is directly intended to make it easy to focus on the final product instead of details like callbacks and events: this is even further away from something that could be imitated in a conventional language. And getting back to Racket, my point should be obvious now... Because the language itself is very flexible, you get to not only do nice things with it as you do with other languages -- you also get to re-invent your own language to make things easier. The meta-pattern of doing this is usually very similar: you work with whatever standard tools you have, and at some point you run into something that is way too repetitive and verbose, or you find yourself drowning in details to implement something that you have a simple description for. (This is exactly the drawing example: add a scale argument to all functions in an existing piece of code vs "draw that at half the size".) In some cases, you can improve things with conventional languages, but IMO this is risking the "when all you have is a hammer" syndrom: there's a whole part of a potential solution space that you can't even think of, since you're constrained by some language. But of course I'm not naive enough to say that artists would start using meta-tools like macros to hack their language to be more fitting for what they want... Instead, my "newbie" point above is that as you work on something like this in Racket, and you don't know how to do all of these advanced things but you do know that they're possible -- you ask about it, and will probably get some answers on how to do things better, and maybe in rare cases the result would be some completely new way to write code. In any case, this is why I think that such an exhibition page might begin as a useful thing in one direction (having example code to start with, and having a web page with things that look like you want to try them), but it can end up being useful in the more Rackety way. > 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. It's even more than that: there's a lot of things that are barely mentioned and could go much farther. You've mentioned plot as one such library -- and there's also things like the images collection who only a few people know how to use properly, or John's rsound library, or slideshow (and its ability to do animations), or opengl, and many more. These are all things that could be used to make such nice looking exhibition style pages, and they would also really benefit from someone excited enough to actually play with them and do such things. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! ____________________ Racket Users list: http://lists.racket-lang.org/users