Manifest: Thurday 19 April 2001

Assignments
Today	Problem Set 4
24-26 April	Project Presentations
Tuesday, 1 May	Project Report

Project Presentations Tuesday, 24 April

Tom Sabanosh
Haiyong Wang
Yuangang Cai
Weilin Zhong

Thursday, 26 April

Michael Deighan
Elisabeth Strunk and Mike Tashbook
Dana Wortman
Chris Taylor
Brian Clarke

Each presentation will be strictly limited to thirteen minutes. If you plan ahead and use your time wisely, this is plenty of time.

The goal of almost all presentations is to get your audience interested enough in what you are talking about that they will want to learn more. For your project presentations, the goal is to make your audience understand and remember the most important idea from your project. You cannot expect to convey a lot of technical information (that's what the report is for), but you should be able to motivate your work and convince your audience why it is important and interesting, make it abundantly clear to your audience what you actually did, and explain one nugget that came out of it.

All talks should tell a story. Don't fall into the trap of giving a list.

All good stories:

• Introduce characters (e.g., rabbit). Characters may be familiar creatures or abstract things. If your characters are abstract things, you need to give your audience a reason to care about them.
• Describe an important problem (e.g., fox wants to eat rabbit)
• Relate events related to resolving the problem (rabbit tells fox about thesis). Sometimes the problem is resolved, sometimes bigger problems are introduced.
• Draw a general conclusion that is supported by your story (moral)

Your project presentation (and nearly all other presentations you give!) should follow this model.

• Introduction
  • Introduce characters: motivate your work
    • Convey why the problem you are solving is interesting, important and exciting
    • Place your work in context: how is it different from what others have done
  • Give the audience a reason to listen to the rest of your talk.
• Guts
  • Explain what you did
    • Don't be comprehensive - get the big picture across
    • Use pictures, one clear example (maybe two if necessary), etc.
  • Convey one technical nugget - show one neat concrete thing that came out of your work.
  • Analysis
    • Did your work solve the problem?
    • What are the important results of your work
• Conclusion

  Summarize your project with one key point.
  If your audience remembers one thing from your talk, you have succeeded.

Project Reports

Your project reports are due May 1. You should turn in a paper printout of your report, and a URL for your report (which should be either .html or .pdf). I will read the paper you turn in, but make the web reports available from the course site.

Like talks, papers should also tell stories. Your reports should include substantial technical details, though.

The final report should motivate, describe and evaluate your work. You may organize your final report into sections as you see fit. It should include (but is not limited to):

• Problem: A clear description of the problem you are addressing. It should motivate your work by arguing that this is an important problem and that there is no satisfactory solution.
• Related work: A good summary and analysis of the work relevant to your project. Everything you describe should be related directly to your project:
  • Why is it relevant? (Don't assume the reader can read your mind.)
  • If it attempts to solve a similar problem, why is it not a satisfactory solution?
  • What ideas in the other project can be applied to your project?
• Solution: Describe what you did to address the problem. This section should make it clear what exactly you did, and how it relates to the problem you motivated in the first section.
• Evaluation: Analyze the success of your solution. This section should provide objective and subjective arguments showing how well your solution addressed the problem. You should have some substantial support for your arguments, but it is not unacceptable to conclude that more work needs to be done to produce a definitie evalution, and describe what additional work is needed.
• Conclusion: What has the programming languages community learned from your work? Your conclusions should be supported by your evaluation section.

There are no length constraints for the final report, but you should aim to be as concise, clear and organized as possible. The writing and presentation should be at a high quality. It would be highly worthwhile to exchange reports with a classmate and review each others reports before submitting them.

Links
Some Intro to CS courses:

• UVA CS101
• MIT 6.001
• Berkeley CS 61A, Berkeley CS 3
• Rice Comp 200: Computer Science for Poets, Rice Comp 210: Principles of Computing and Programming
• Georgia Tech: Introduction to Computing
• Cornell: Introduction to Computer Programming

Throughout the history of computer science education, the structure of the introductory computer science course has been the subject of intense debate. Many strategies have been proposed over the years, most of which have strong proponents and equally strong detractors. Like the problem of selecting an implementation language, recommending a strategy for the introductory year of a computer science curriculum all too often takes on the character of a religious war that generates far more heat than light.

In the interest of promoting peace among the warring factions, the CC2001 Task Force has chosen not to recommend any single approach. The truth is that no ideal strategy has yet been found, and that every approach has strengths and weaknesses. Given the current state of the art in this area, we are convinced that no one-size-fits-all approach will succeed at all institutions. Because introductory programs differ so dramatically in their goals, structure, resources, and intended audience, we need a range of strategies that have been validated by practice. Moreover, we must encourage institutions and individual faculty members to continue experimentation in this area. Given a field that changes as rapidly as computer science, pedagogical innovation is necessary for continued success.

7.2 The role of programming

One of the most hotly debated questions in computer science education is the role of programming in the introductory curriculum. Throughout the history of the discipline, introductory computer science courses have focused primarily on the development of programming skills. The adoption of a programming-first introduction arises from a number of practical and historical factors, including the following:

• Programming is an essential skill that must be mastered by anyone studying computer science. Placing it early in the curriculum ensures that students have the necessary skills when they enroll in intermediate and advanced courses.
• Computer science did not become an academic discipline until after most institutions had already developed a set of introductory programming courses to serve a much wider audience. By the time our predecessors began to develop computer science curricula, the antecedents of our introductory courses had already evolved explicitly as "skills courses" to serve the needs of other disciplines. Thus, computer science curricula were often built on top of existing programming courses, which never had the opportunity to evolve into a more broadly based introduction to computer science as a field.
• The programming-first model was implicitly endorsed by the early curriculum reports through the design of their recommended courses. Curriculum '68 [ACM68], for example, begins with a course entitled "Introduction to Computing" in which the overwhelming majority of the topics are programming-related. The centrality of programming in introductory courses was further reinforced by the definitions of CS1 and CS2 in Curriculum '78 [ACM78], which defined these courses as an "Introduction to Programming" sequence.

The programming-first approach, however, has several shortcomings. The most commonly cited objections to this approach are the following:

• Focusing on programming to the exclusion of other topics gives students a limited sense of the discipline, thereby reinforcing the common misperception that "computer science equals programming."
• Theoretical topics that would enhance the students' understanding of the practical material are deferred to later points in the curriculum, when they no longer have the same immediate relevance. This limitation has implications for both majors and nonmajors. Nonmajors who take only introductory courses are deprived of any exposure to the conceptual and intellectual foundations that underlie the revolutionary technological developments driving change throughout society. For majors, the fact that theory is not introduced in the early courses fuels the bias of many students who conclude that theory is irrelevant their educational and professional needs.
• Programming courses often focus on syntax and the particular characteristics of a programming language, leading students to concentrate on these relatively unimportant details rather than the underlying algorithmic skills. This focus on details means that many students fail to comprehend the essential algorithmic model that transcends particular programming languages. Moreover, concentrating on the mechanistic details of programming constructs often leaves students to figure out the essential character of programming through an ad hoc process of trial and error. Such courses thus risk leaving students who are at the very beginning of their academic careers to flounder on their own with respect to the complex activity of programming.
• Introductory programming courses often oversimplify the programming process to make it accessible to beginning students, giving too little weight to design, analysis, and testing relative to the conceptually simpler process of coding. Thus, the superficial impression students take from their mastery of programming skills masks fundamental shortcomings that will limit their ability to adapt to different kinds of problems and problem-solving contexts in the future.
• Programming-intensive courses disadvantage students who have no prior exposure to computers while giving the illusion to those who have previously used computers that they know more than they really do. As a result, students who are new to computing are often overwhelmed, while students who have a prior background often simply continue bad habits.
• Programming-first approaches can lead students to believe that writing a program is the only viable approach to solving problems using a computer. The power and versatility of application programs have increased substantially in recent years, and it is important for students to recognize that such applications can be extremely effective as a problem-solving tool without the need for classical programming. This concern is particularly relevant to nonmajors, whose problem-solving abilities and sense of empowerment can be significantly increased through a knowledge of modern applications.

From ACM Computing Curricula 2001.

University of Virginia Department of Computer Science CS 655: Programming Languages

David Evans evans@virginia.edu