On Sat, Aug 6, 2011 at 03:08, Danny Yoo <d...@cs.wpi.edu> wrote: > I'm thinking of writing a series called "Racket Slices", which does a > cookbook-style approach to learning about Racket. I think there's a > need for documentation that takes a "slice", a cross section of Racket > to do some simple (but real-world!) task. And since we're using the > name "Racket", it demands that we use a pun about tennis. > > Here's what I'm thinking of: > > http://hashcollision.org/racket-slices/irc-parsing/index.html > > > How does it look? >
Good work! If feels easy to read. Maybe you'll come up with more "revisions" just like it happened to the brainfudge #lang tutorial. I believe the "series" would be valuable for the community. Today I came across the following excerpt which highlights the importance of having examples to learn from: *Examples* over *Documentation*: Attempts to use components were helped not > by documentation but by the availability of example code that could be > copy-and-pasted into the application and then tweaked to fit the situation. > In some cases documentation was actually a hindrance. Misleading > documentation found through Google led one team down a blind alley trying to > use an inappropriate library that didn't actually do what was required. > Another team tried to use a component that had huge amounts of well written > documentation that was entirely useless and so slowed them down because they > had to wade through a lot of text before finding out that they were wasting > time. A team using components that had been developed test-first found the > tests to be useful both as documentation and a good source of example code. from http://www.natpryce.com/articles/000555.html So having more examples of Racket code around can be a good thing when people need to find out how to use certain functions, etc. []'s Rodolfo
_________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
