I think that it is difficult to picture this documentation/pattern drawing program without using it. In addition, this seems to focus on patterns to make the documentation process for people other than the programmers. Is this something that we want to teach?

How much importance is readability when it comes to our design of programs. Are we really concerned that someone else will be able to read the code and understand the design as long as it makes sense to us (without it being pure hackery)? Documentation is something that we teach to make TAs lives easier, not for any other reason. Maybe we need to rethink that.

An interesting excercise could be to take two programs that do similar things, and have one that is nicely documented, and one that is straight code, and see how students react to reading both of them. What is clearer, simply what the code does, the design of the program, ways of building on, etc.?

How does this relate to our discussion last year of teaching design only in the first few weeks of class. Is using a "design-only" language a possibility. Are the tools discussed in this paper meant to be a version of that? Seeing how I personally find this unappealing, does that indicate that students would probably feel the same way? If this is meant to facilitate design, do we (as Brown CS students) know of a better way, and would we be able to implement it? Or does this show that it's been done before, and it's not something that we find interesting (and therefore might not be beneficial to the students we are trying to teach)?

MY COMMENTS

I agree that it makes virtually no sense without practice... I am still a bit confused by what they were talking about < grin >