In my opinion it is probably a mistake to focus on the language features in the beginning. They will be meaningless.
My approach would be to ask them to write a simple chess program. They have to learn to do conditional statements, iteration, work with data structures, and do I/O. They have to parse simple input (K-P4), and draw a simple ascii chessboard using --- characters. They also have the opportunity, though not the need, to do recursion in either depth-first or breadth-first search. The game is small, it doesn't have to have any strategy beyond "make the next legal move" but could be more complex. In that way you'll get to see who has a handle on the language. You'll also be able to suggest improvements by citing examples from their code. Anonymous examples can be shown to the class to illustrate ideas for improvements. You can move from simple optimizations to very complex ideas (e.g. concurrent threads searching for suggested moves, memoization of board positions, learning by self-modification to play better games, etc.). Once they get past the point where they have to look up every single function they will be able to use the language. This approach isn't Clojure specific. I've used it for several languages and it seems to work well. Tim Daly -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
