Rick Decker

The top 10 reasons why object-oriented programming can't be taught in CS 1

Over the past year we have changed our CS 1 course from a standard Pascal-based, procedural programming course into one that emphasizes C++ and object-oriented programming (OOP). While our experience to date indicates that this was a good decision for both our students and our department, the decision did not come easy. We struggled long and hard with many, if not most, of the questions and issues that have come to be associated with teaching OOP to undergraduates. This paper recounts our struggles, and presents our responses to the more serious of the pedagogical questions that we considered. In hindsight, many of the reasons we came up with for not using OOP in CS1 are seen to reflect our lack of understanding of the paradigm, our fear of the language, and our past experience teaching Pascal and the procedural paradigm. Furthermore, we believe that our reservations (which appear to be quite common) stemmed from a growing body of misleading OOP folklore that is contrary to our experience and that this paper attempts to dispel.

Top-down teaching: object-oriented programming in CS 1

This paper advocates the positwn that the primary source of our collective difficulties in teaching introductory programmhg is that our goals for CS 1 and our tools for teaching it are seriously and irreconcilably mismatched. While we have been preaching top-down methodologies for many years now, we have been teaching languages that support most directly bottom-up prograntnu”ng. Such languages, which focus primarily on the details of coalng and algon”thms, en

Using C++ in CS1/CS2

orce a tactical paradigm which obscures from our students the more giobal, strategic issues we want them to develop and appreciate from the start. Object-oriented languages, on the other hand, allow us to concentrate initially on top-level &sign considerations, and to progresw”n true top down fashior+to working, worhble programs that embody the principles of sofmare engineering and program sty[e. The following &scribes a new labbased implementation of CS 1 which we are now developing mung Object Pascal. Our intut”tion and our experience to &te indicate that it better prepares more stucknts than does the prewx”ling pedagogical mo&L I. The Problem: Teaching Introductory Programming Despite considerable effort and a great deal of rhetoric, the past two decadeshave seenrelatively little progress in the effectiveness with which we teach computer programming. Indeed, the most common programming languages for teaehing (Pascal, BASIC, FORTRAN, C) are essentially the sameones that we have used for the past 20 years. To be sure, the implementations of these languages have become increasingly sophisticated. The languages are now more expressive, offer additional Permission to copy without fee all or part of this material ia granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission. ACM-24thCSE-2/93 -lN, USA 01993 ACM 0-89791 -566 -6/93 /000210270 . ..

The PIPPIN machine: simulations of language processing

1 .50 features to addresssoftware engineering concerns,and support more sophisticated interactive programming and debugging, but the paradigm for teaehing programming hasremained essentially intact. We teaeh pmeduml languages-languages m which the basic unit of abstraction is a procedure, or an algorithm, and there is a clean distinction between an algorithm and the data it operates on. We do so knowing that such languages have welldoeumented theoretical and practical limitations. Simply stated,pmcedud languages (1) do not support the development of effieientj reusable software, (2) are illsuited to modelling real-world applications and, so, are not particularly useful for systemdesign, and (3) are difficult to teach, perhapsbecaust of (1) and (2), and perhaps becausethey impose an algorithmic (as opposed to dataoriented) method of problem solving that is eotmterintuitive to many otherwise bright students. This algorithmic method enfaees a tactical paradigm, in which the emphasis and level of organizadon are foeussed primarily on the details of ding. ‘he principles of program design are not enfomed by procedural languages rather they are Wressed by languageadd-enswhich have been introduced to make the programming process more efficient. The byproducts of our varied and well-intentioned efforts at teaching procedural jrogramming~ CS 1 smden~range from those who, after three weeks of the semester,are irretrievably lost and will never learn to program a loop, all the way to those who whiz through CS 1 and quite possible go on to major in CS and graduate. All but the very best am ill-prqrared to work as professional programmers becausethey have yet to develop what are currently regardedas basic sofhvare engineering skills. In many casesthey have difficulty analyzing and designing large-scaleprograms, and producing code that is readable,reliable, verifiable, reusable, maintainable, and soon, Our collective responseto these failings has been, fm~ to blame the students, citing their tack of preparation, eroding quantitative skills, and lack of effort. More constructive, at least, have been our attempts to adapt the

Revitalizing the computer science course for non-majors (abstract)

Statement from Michael Berman: We started using C++ in CS2 in Fall 1993. In Fall 1994 we will start using C++ in our CS 1 class. Our motivation for using C++ came from several directions. First, we use C in advanced courses, and needed a better place in the curriculum to introduce C (or, better, C++). Second, we wanted a language that could fully support implementation of abstract data types and OOP. Third, external forces (employers, MIS department, and a future Engineering School) pointed towards C++. There’s no time in CS UCS2 to learn everything about C++, but I don’t think you need to. Ideally, the relevant features are covered as they are needed. I am developing a CS2 textbook based on this approach. Introducing features in this way is nearly impossible in C, but is actually easier in C++ because pre-written classes can be used to hide some of the complexity of the language.

The top 10 reasons why OOP can't be taught in CS1

This article describes two simulations which, together, areintended to help students make the leap from writing programs in asimple high-level language to understanding how such programs cometo be translated and executed on a simple computer. The firstprogram simulates the compilation of an assignment statement from atypical programming language into a mock assembly language. Thesecond program simulates the fetch-execute cycle on a computerbuilt expressly to process that same assembly language. We describethe design and use of each simulator, and conclude with anecdotesabout our experiences using these tools in class.

The Analytical Engine: An Introduction to Computer Science Using the Internet

The panel will examine a variety of issues. What can computer science offer to the non-major? What material should anon-majors’ course contain and how should the material be presented? Even better, how should the material be learned? Should we teach non-majors to use word processors and spreadsheets? Can we give them something more than spreadsheetsand databaseswithout losing their interest? What’s the best use of laboratory time for a non-major? How do we get the most educational value out of limited laboratory budgets?

Data structures

Over the past year we have changed our CS 1 course from a standard Pascal-based, procedural programming course into one that emphasizes C++ and object-oriented programming (OOP). While our experience to date indicates that this was a good decision for both our students and our department, the decision did not come easy. We struggled long and hard with many, if not most, of the questions and issues that have come to be associated with teaching OOP to undergraduates. This paper recounts our struggles, and presents our responses to the more serious of the pedagogical questions that we considered. In hindsight, many of the reasons we came up with for not using OOP in CS1 are seen to reflect our lack of understanding of the paradigm, our fear of the language, and our past experience teaching Pascal and the procedural paradigm. Furthermore, we believe that our reservations (which appear to be quite common) stemmed from a growing body of misleading OOP folklore that is contrary to our experience and that this paper attempts to dispel.