Recitation 1 follow-up

Today's recitation was lively - I had a lot of fun. However, some of you may have felt the recitation had a little of a "Wild West" feel. I'd like to share with you why I think that was, and some rules that will help you structure the discussions this month.

Reason number 1: Unclear Assumptions

I spewed out an argument filled with lots of implicit assumptions. These came out later, much later. For example: "star" programmers using "the right thing" languages were easy to find. Another assumption - "the right thing" languages are faster to prototype in than "worse is better" languages.

Reason number 2: Unclear Purpose

Up front, I did not state a clear purpose or objective I was measuring against. In lecture, I listed a lot of reasons you would want to build systems - robustness is one.

Reason number 3: Unclear Tradeoffs

Up front, I did not state the tradeoffs I made. I also did not state the reasons I made the particular tradeoffs I made. It took a while before we got to that. There are always tradeoffs. Don't be surprised if you read papers or attend talks that feel like today's discussion. By the end of the month, I want you to learn how to extract something useful from these kinds of discussions - by imposing structure. The success of your final project will depend, in part, upon how well you develop this skill.

Therefore, during tomorrow's group presentations, I suggest you listen, ask questions, then respond. Before you respond, you should have a clear understanding of the assumptions, objectives, and tradeoffs. That's why you should ask lots of questions before you respond. Otherwise, you will likely become very frustrated and you won't learn as much.

Note that this framework is similar to the critical analysis framework. You cannot know what the problem is or why a particular approach was used, or why a particular experiment was performed unless you understand the assumptions and objectives.

Similarly, you cannot evaluate the results of the experiment or the conclusions unless you know why certain tradeoffs were made.

Learning about systems will require to your learn from the experience of others. Whether or not you agree with someone else's conclusions is not the point of a discussion. The point is to be able to extract and apply someone else's experience.

Myths about systems discussions

Myth 1: Discussing systems requires lots of technical knowledge

Suppose I said, "Scheme is better for prototyping because it has first-class continuations that can model any known control structure." If you don't know what I'm talking about, ask questions: What's a continuation? What are your assumptions? Is time to finished prototype one of your key objectives? Any others? What tradeoffs are you making? (note I don't need any technical knowledge to ask these questions)

If you are still not convinced, you should say, "show me an example of your assertion". At the end of this conversation, you will know what a continuation is. You'll also have an example of when, where, why you might or might not want to use Scheme for prototyping. Mission Accomplished!

Notice that whether or not I was right in using Scheme for prototyping is irrelevant - after all, there is no wrong or right here. What is relevant is you being able to learn from my experience. Now, you can make better decisions the next time you are prototyping. The discussion might even lead to a set of prototyping principles you can write about to help others.

How not to respond: "Scheme is a dead language. Java is clearly the way to go. I much prefer it. Therefore, you must be wrong. Conversation over." In this case, all we've learned is that someone prefers Java. So what?

More myths to come...