[racket] Advice: simulating stateful API in functional setting

On Jul 15, 2011, at 3:12 PM, Matthias Felleisen wrote:

> I don't understand your solution. But if students cannot test their event handling functions in a functional style, then the answer to the last question is YES, you're pregnant. 

Based on my toy examples so far, they can test their event-handling functions for the sprite they return, but not for their effect on the world picture.  One could provide a "test-drawing" function or macro that takes in a picture, calls a student's function, and compares the new picture with a specified right answer.  (In fact, one could provide something like that for testing almost ANY mutating operation.)  Not ideal, but better than not testing it at all.

> If so, the question is what you wish to accomplish with the library. If you're fine with teaching things that look like algebra but are actually imperative, join the club. Everyone else except us is doing it. 

I'm looking at our competition in the marketplace of ideas, and I want to beat (or at least match) them at their own game.

Our competitors at present are Alice, BYOB, Processing, and Python.  Alice and BYOB do drag-n-drop programming, which I'm not trying to replicate: any menu-based UI requires limiting the available operations to at most a few dozens, and that's not an accurate reflection of high-level programming.  Alice does a lot of 3-D, so I want to play with a 3-D version of universe and see how it works in the classroom.  BYOB does 2-D turtle graphics, so I want to figure out how to do many of the same problems in a natural, functional, testable style.  Every workshop on Python or Processing in education includes an example ("which students can do on the first day," although largely by copying and tinkering rather than deep understanding) of processing an image pixel by pixel with nested for-loops, so I wrote map-image and build-image to accomplish the same things functionally.

Who's with me?

Stephen Bloch
sbloch at adelphi.edu