On Jun 3, 2013, at 5:45 PM, Philipp Dikmann wrote: > but when the problem is always simply 'reproduce this image', a single > language still allows multiple interesting ways of thinking about it (esp. > considering the idea of 'language' in the Racket context :P), and even > better: demonstrate, graphically, what that particular way of thinking > entails (e.g. like the 'experimental translations' of the Recode Project).
This suggests an interesting comparative programming project. Within Racket you can easily show off a range of programming style for just this "produce this image" special-purpose domain: -- images from the teaching languags -- slideshow -- the raw graphics box underneath it all and in each case, we can show off a functional and an OO approach. Indeed, we might even be able to show off a CONSTRAINT programming approach (make an image that satisfies the following constraints). > - One last thing: In my experience, errors are more plentiful in Processing, > because keeping track of state gets difficult. However, in an artistic / > experimental setting, errors can be very productive. I've had considerably > less 'happy accidents' in Racket, because there are very few accidents at > all; 'breaking things' must be done more purposeful. I understand this is the > result of continued efforts to make reasoning about Racket programs as > effortless as possible, so hats off to that :) Thanks. Errors have been a key focus of the project from its conception. -- Matthias
____________________ Racket Users list: http://lists.racket-lang.org/users
