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.
- Rule #1: Know the key assumptions
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.
- Rule #2: Identify a purpose or objective(s)
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.
- Rule #3: Identify the tradeoffs and the rationale for the tradeoffs
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
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
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...