Debate Guidelines

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 real analysis.

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 code?

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 debate.

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.

Debate Format

• The audience (the rest of the class) gives an initial vote on the issues.
• 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.
• Rebuttal
  • A ten (10) minute break will provide time for each team to formulate rebuttals.
  • 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. Those 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.

Preparing for the debate

• 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.

New guidelines

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.

Citations

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.