As you know, when designing an algorithm or developing a computer program,
it often becomes necessary to decide between different design options. These
decisions can be quite large, such as which programming language to use, or
quite small, such as which hashing function to use. In many cases, it is
imperative that these design decisions be made carefully, with analysis of
the costs and benefits of the competing options within the context of the
current project. In both research and industrial settings, project teams
need to be able to successfully discuss these options, with different team
members arguing for different points. Even when the team contains only
one member, that member must find ways to anyalyze and weigh the options.
Unfortunately, the decisions we make are often quick and casual, with little
The design of a compiler and corresponding language presents many design
decisions, particularly in class situations in which the requirements
may be less formal. For example, one might consider
- What kind of language should we implement: a traditional imperative
language using techniques that have been studied for many years, or
a modern functional or object-oriented language, with techniques on
the cutting edge of compiler design?
- What language should we use to build our implementation? The textbook
for our course comes in three "flavors": ML, Java, and C. It is also
possible to use almost any language for the implementation.
- How much of our compiler should be built by hand, and how much from
compiler generation tools?
- What type of scoping should we support, static or dynamic?
- Should we implement a garbage collection algorithm or require programmers
to do explicit memory management?
- Should we compile to a known assembly code or develop our own intermediate
To ensure that we analyze these issues in sufficient depth, I will be
assigning you to teams of three to debate selected issues. Each student
will participate in two debates during the term, one at the beginning of
the semester (when we make our initial and global design desicions) and
one at the end of the semester (when we consider both specific and
global issues). While I will evaluate your work in the debate at both
parts of the semester, I will only grade you on your work in the second
Debates will not be the only way in which we discuss design
alternatives. They are an exercise to examine one technique of
evaluating alternatives. You are expected to participate in other, more
regular, forms of discussion throughout the semester.
- The audience (the rest of the class) gives an initial vote on
- Opening statement
- Each member gives a three to four minute opening statement.
- Together, these statements should explain the team's basic position and
provide convincing evidence.
- As such, the team's slate of presentations should be coherently organized.
- The statements as a whole should provide a comprehensive review of the
topic without being redundant.
- A ten (10) minute break will provide time for each team to formulate
- Each team member has two minutes to respond to a point or points made
by the opposite team.
- You should speculate about points the other side is likely to make and
prepare possible counter arguments before the day of the debate.
- Question period. The audience will ask questions of either team.
of you not participating in a particular debate are expected to formulate
appropriate questions during opening statements, break, and rebuttals.
- The audience votes on a winner and critiques the debate.
Your primary goal should not be to ``win'' the debate. Rather, the
primary goals of these debates are (1) to ensure that we think carefully
about these design decisions and (2) to improve our skills in thinking
about such design decisions.
- Analyze the audience and occasion. The debate you give for your fellow
CS362 students may be quite different than one you'd give for faculty
or for less experienced students.
- Analyze the topic and side I have given you. Identify a set of reasons
to choose your side. If you have difficulty doing so, feel free to
chat with me.
- Gather appropriate materials. It is unlikely that you will be able to
find sufficient information in our text, and you may have to be creative
in what you do. For example, you might examine existing implementations,
read papers on the software design process, or even survey appropriate
people (e.g., what do employers expect you've done in a compilers class).
- Make an outline and draft. If you'd like some ideas of where to start,
feel free to chat with me.
- Rehearse in front of your teammates. Use your rehearsals to refine and
strucutre your arguments.
- Prepare initial ideas for rebuttal.
Given our experiences in the first debates, we are going to make a few
changes to the guidelines.
- Each group may make one introductory opening presentation outlining
the structure of their argument. This opening presentation may
be no more than two minutes. The person making this opening
presentation can make a second presentation after everyone else in
the team has made their presentation.
- The other opening arguments will be limited to two minutes (groups
of four) or three minutes (groups of three).
- Each rebuttal will be limited to 1.5 minutes.
- Everyone not participating in the debates is required to develop
at least one question for the debators.
The debate format is taken from a handout labelled "Tutorial-Debate"
distributed by Jan Czechowski at the Summer 1998 Faculty Oral Skills
Seminar. The original author of that handout is unknown. The section
on preparing for the debate is loosely based on another anonymous
handout from the same session.
Disclaimer Often, these pages were created "on the fly" with little, if any, proofreading. Any or all of the information on the pages may be incorrect. Please contact me if you notice errors.
Source text last modified Mon Sep 7 12:21:57 1998.
This page generated on Wed Sep 16 11:35:02 1998 by SiteWeaver.
Contact our webmaster at firstname.lastname@example.org