Stuart Hirshfield

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.

This is your brain on interfaces: enhancing usability testing with functional near-infrared spectroscopy

This project represents a first step towards bridging the gap between HCI and cognition research. Using functional near-infrared spectroscopy (fNIRS), we introduce tech-niques to non-invasively measure a range of cognitive workload states that have implications to HCI research, most directly usability testing. We present a set of usability experiments that illustrates how fNIRS brain measurement provides information about the cognitive demands placed on computer users by different interface designs.

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

A survey course in computer science using HyperCard

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

New models for the CS1 course: what are they and are they leading to the same place?

This paper describes a survey course in computer science and the materials we have developed to support it. The course is distinctive in at least three ways. First, it presents a comprehensive, disciplinary survey of the field. Second, it emphasizes the principles upon which the discipline is based, stressing liberal education as opposed to technical training. Finally, it reflects our belief that one learns best by doing, as well as thinking, and so includes customized software in the form of HyperCard stacks to support an integrated, directed laboratory component. Our experience over the past year indicates that the audience appreciates this survey approach, that students come away with both a sense of accomplishment and a realistic feeling for the breadth and substance of the discipline, and that HyperCard is a superb medium for illustrating, demonstrating, and making accessible a wide range of computer science topics. 1. Problems With the Survey Course The problem with a survey course in computer science is twofold. First, there is no all-encompassing metaphor for computer science. Even the accepted definitions of the discipline admit to a variety of legitimate perspectives, and point to a multi-faceted, diverse field of study. Indeed, it appears that most of us are likely in the same position regarding computer science as Justice Stewart was regarding pornography: we may not be able to define it, but we know it when we see it [4]. Not surprisingly, the second problem has beenand continues to be-that there is no agreement about which perspective is appropriate for the survey course. In physics, chemistry, geology, and mathematics, in contrast, there is at least a partial consensus among professionals about the curriculum of the survey course, based upon decades or centuries of experience. Permission to copy without fee all or part of this material is 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.

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.

Computer-assisted language analysis with the Macintosh

Owens: The first course in Computer Science has been beset by several diverse approaches in the past few years. This panel proposal suggests that a reasonable way to discuss these different models is to have a representative from each of several positions describe the first course at his/her school and then speculate on where the students will be at the end of the third year in the program. Each panelist will discuss core topics covered. This panel is not intended to be a debate as to the one best way to do things, but is intended to reassure the Computer Science community that there are many paths to a solid CS foundation.

Beyond Facebook Personality Prediction

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.

New models for the CS1 course: a fifteen year retrospective

Computer programs are useful in content analysis of written and spoken language. This article describes MacCALAS, a new and streamlined Macintosh version of CALAS, the Computer-Assisted Language Analysis System, originally designed in the early 1970s (Rush et al., 1974). MacCALAS, which is written in C, parses transcripts of spoken text into grammatical-components and categorizes verb types according to Cook’s (1979) case-grammar matrix. Using four subprograms, it determines the grammatical category of each word on the basis of adjacent function words and placement of words in a sentence, rather than by using a large “dictionary.” MacCALAS also computes ratio measures of stylistic complexity and proportions of verb types. MacCALAS can be used in linguistic analysis of various kinds of texts and dyadic interaction such as psychotherapy and language development.