UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

What teachers know about programming Gervin, Debbe 1992

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
831-ubc_1992_fall_gervin_debbe.pdf [ 8.89MB ]
Metadata
JSON: 831-1.0086491.json
JSON-LD: 831-1.0086491-ld.json
RDF/XML (Pretty): 831-1.0086491-rdf.xml
RDF/JSON: 831-1.0086491-rdf.json
Turtle: 831-1.0086491-turtle.txt
N-Triples: 831-1.0086491-rdf-ntriples.txt
Original Record: 831-1.0086491-source.json
Full Text
831-1.0086491-fulltext.txt
Citation
831-1.0086491.ris

Full Text

WHAT TEACHERS KNOW ABOUT PROGRAMMINGbyDebbe GervinB.A., York University, 1976B.Ed., Ontario Teacher Education College, 1977A THESIS SUBMITTED IN PARTIAL FULFILLMENT OFTHE REQUIREMENTS FOR THE DEGREE OFMASTER OF ARTSinTHE FACULTY OF GRADUATE STUDIESMATHEMATICS & SCIENCE EDUCATIONWe accept this thesis as conformingto the required standardTHE UNIVERSITY OF BRITISH COLUMBIAJune 1992© Debbe Gervin, 1992In presenting this thesis in partial fulfilment of the requirements for an advanceddegree at the University of British Columbia, I agree that the Library shall make itfreely available for reference and study. I further agree that permission for extensivecopying of this thesis for scholarly purposes may be granted by the head of mydepartment or by his or her representatives. It is understood that copying orpublication of this thesis for financial gain shall not be allowed without my writtenpermission.(Signature) Department of t'/ 1i , scieNL, e-The University of British ColumbiaVancouver, CanadaDate^v h -DE-6 (2/88)ABSTRACTResearch into the teaching of computer programming seldom examines theprofound and abundant knowledge of classroom practitioners. Further, littleresearch has been carried out which compares the learning and teaching ofprocedural programming to the learning and teaching of other programmingparadigms.In this study, teachers of post-secondary computer programming were interviewedin order to gain an understanding of the ways in which their knowledge aboutprogramming and their knowledge about teaching programming are related and inorder to get a sense of the conceptual frameworks within which their knowledge isformed.The results of the study indicate that knowledge about programming andknowledge about teaching programming are strongly related. The respondents'teaching and programming experience, the social contexts within which theyoperate, their desire for control, their programming paradigm experience and themental models they employ when programming shape the ways in which theyprogram and the ways in which they teach.All of the respondents feel that languages and paradigms affect the wayprogrammers think when programming. As well, those with broad experience feelthat because there are large differences between paradigms, shifting from oneparadigm to another is very difficult. Thus they feel that the choice of students' firstprogramming language is critical.There appears to be a strong relationship between respondents' paradigm experienceand the mental models they use. Those respondents with experience in multipleiiparadigms tend to use more abstract models than those who have been exposedprimarily to the procedural paradigm. These more experienced respondents feelthat they are able to choose languages that match the way they think.The results of the study imply that investigations of programming educationresearch and practice can benefit from an understanding of researchers' andpractitioners' frameworks. In particular, it appears that the choice of programmingparadigm strongly influences research studies and classroom teaching.iiiCONTENTSLIST OF TABLES^ viiiLIST OF FIGURES ixACKNOWLEDGEMENT^ xCHAPTER ONE: INTRODUCTION^ 1Purpose of the Study^ 2Need for the Study 4Generalizability^ 4Research Questions 5Terminology and Style^ 6CHAPTER TWO: REVIEW OF THE LITERATURE^ 7Computer Science Education^ 7A Focus on Programming 7What is Programming?^ 8A Classical View 8An Adaptive View^ 8A Mathematical View 9Summary^ 10What do Programmers Do?^ 10Why Is Programming Taught? 13Professional Training^ 13Computer Literacy 13Cognitive Skills Development^ 14Summary^ 15Current Issues 15Predicting Success^ 15ivPrior Achievement^ 16Aptitude Measures 16Cognitive and Psychological Measures^ 17Environmental Variables^ 17Summary^ 18Approaches 18The Expert Approach^ 19The Spiral Approach 20The Reading Approach^ 21Summary^ 21Mode of Learning 21Group Interaction^ 22Discovery Learning 22Lecture Mode^ 23Summary 23Models^ 24Choice of Language^ 25The Paradigm Shift 27Research Perspective^ 31CHAPTER THREE: RESEARCH METHOD^ 36Data Collection Procedures^ 36Sampling^ 37Interpretation and Analysis^ 40Pilot Study^ 40James 41James' Knowledge about Programming^ 42James' Knowledge about Teaching Programming^43An Integration of James' Knowledge^ 47Melissa^ 49Melissa's Knowledge about Programming^ 50Melissa's Knowledge about Teaching Programming^52An Integration of Melissa's Knowledge^ 56Results of the Pilot Study^ 58CHAPTER FOUR: RESPONDENTS' VIEWS OF PROGRAMMING^64Ross^ 65Ross's Knowledge about Programming^ 66Ross's Knowledge about Teaching Programming^71An Integration of Ross's Knowledge^ 75Lorne^ 77Lorne's Knowledge about Programming^ 78Lorne's Knowledge about Teaching Programming^84An Integration of Lorne's Knowledge^ 87Isaac^ 91Isaac's Knowledge about Programming^ 93Isaac's Knowledge about Teaching Programming^97An Integration of Isaac's Knowledge^ 101Kyle^ 103Kyle's Knowledge about Programming^ 104Kyle's Knowledge about Teaching Programming^111An Integration of Kyle's Knowledge^ 115Mario^ 119Mario's Knowledge about Programming^ 120Mario's Knowledge about Teaching Programming^125An Integration of Mario's Knowledge^ 129viClaire^ 134Claire's Knowledge about Programming^ 135Claire's Knowledge about Teaching Programming^139An Integration of Claire's Knowledge^ 142CHAPTER FIVE: DISCUSSION OF THE RESEARCH RESULTS^146Introduction^ 146Conceptual Frameworks^ 148Life Experience 148Social Context^ 151Desire for Control 153Paradigm Experience^ 155Level of Mental Model 160Conclusions^ 174Limitations 176Implications^ 176REFERENCES 180APPENDIX A: GLOSSARY^ 191APPENDIX B: SAMPLE INTERVIEW TRANSCRIPT^194viiLIST OF TABLESTable1 Respondents' Paradigms 392 Interview Protocol 593 Respondents' Life Experience 1484 The Relationship of Mental Model to Respondents'Views 164viiiLIST OF FIGURESFigure1 29Programming Paradigms2 37Programming Paradigms3 Lorne's Conceptual Model 854 Breadth of Respondents' Paradigm Experience 1565 Respondents' Mental Models 161ixACKNOWLEDGEMENTThe process of creating this document has re-enforced the feeling that my ideas areshaped and clarified through interaction with others. Many thanks to those whoshared in the process: to the respondents for sharing their worlds; to the membersof my committee, Dr. Marvin Westrom, Dr. Gaalen Erickson and Dr. HughDempster, for their advise and encouragement; to my fellow grad students for theiropinions and companionship -- in particular to Tony for exemplifying dedication toa goal and to Ken for reminding me that the side paths are just as important; to mycolleagues, whose anecdotes sparked the idea for this research; to my family for theirpatience and support; and to Bruce, for listening and questioning and pushing methrough.CHAPTER ONEINTRODUCTIONResearch into factors affecting the acquisition of programming skills ispredominantly quantitative in nature (Ellis, 1989). Moreover, a broadening of thescope of the research to an examination of literature about learning outcomes,teaching strategies and choice of programming language reveals the samequantitative tone throughout the field (Sharma, 1987; Van Merrienboer andKrammer, 1987; Johanson, 1988).The statistical tenor of the literature represents the intrinsically quantifiable natureof computer programming. The current study might have taken the sameperspective had not the quantitative nature of the research contrasted so stronglywith the qualitative nature of the educational research being carried out in othercontent areas such as science and mathematics (Yackel, Cobb, Wood, Wheatley andMerkel, 1990; Nussbaum and Novick, 1982; Posner, Strike, Hewson and Gertzog,1982; Driver, 1989; Jacob, 1988); with the view that "truth in the fields of humanaffairs is better approximated by statements that are rich with the sense of humanencounter ..." (Stake, 1978, p. 6).Teachers of programming, in numerous papers, express opinions about predictingsuccess, cognitive outcomes, appropriate teaching strategies and best choice ofprogramming language (e.g., Bork, 1971; Hancock, 1988; Luker, 1989; Shneiderman,1985; Johanson, 1988). Their opinions, based on "perceptions and understanding"(Stake, 1978, p. 6), represent profound and abundant insights into the teaching ofprogramming that is not being captured by the plethora of quantitative analysis.What Teachers Know about Programming^ 1Purpose of the StudyThe purpose of this study is to extend the field of computer programming educationresearch by adopting a form of "educational connoisseurship" (Eisner, 1985, p. 216);by taking "the opportunity to attend to happenings of educational life in a focused,sensitive, and conscious way" (p. 221). In particular, the study examines computerprogramming education from a constructivist perspective.To the constructivist, knowledge is a human construction which enables one tocope with the world (von Glasersfeld, 1989; Driver, 1989). Moreover, the humanconstruction does not correspond with an objective truth. Knowledge is nothingmore or less than a subjective fit with experience. Public knowledge is a socialconstruction which represents a consensus rather than a recognition of existingfacts. Thus, computer scientists, teachers, students and researchers all have personalinterpretations of the socially constructed concept of programming. Theconstructivist postulates the existence of conceptual frameworks which allow peopleto deal with events. Driver and Erickson (1983) define a conceptual framework as"the mental organisation imposed by an individual on sensory inputs as indicatedby regularities in an individual's responses to particular problem settings" (p. 39)."Individual's actions", they maintain, "are influenced by their conceptualstructures" (p. 39). From a constructivist perspective, then, the existing quantitativeresearch into computer programming education is missing an important facet: anunderstanding of social and personal interpretations of programming, and a senseof the conceptual frameworks which influence teachers' pedagogical practices.In this study, in the style of studies of teachers' views in areas such as curriculumplanning (Elbaz, 1983), curriculum change (Cardwell, 1988) and occupationalpatterns (Lortie, 1975), I examine the views of programming teachers. In order toWhat Teachers Know about Programming^ 2recast the issues extant in the literature in an interpretive framework, I attempt tomake explicit teachers' constructed knowledge about programming and teachingprogramming and examine the factors which may have affected that construction.The constructivist would agree with Bogdan and Taylor that "to understand theworkings of a group ... we must also understand how they ... define their world ... "(in Spector, 1984, p. 460). In this study, in order to gain an understanding of howprogramming teachers define their world, I interviewed, in depth, six programmingteachers.The notion that it is necessary to get a sense of teachers' definitions of the worldpoints to another salient aspect of the existing computer programming educationliterature. As the field of computer science matures, distinct programming languageparadigms are emerging (Appleby, 1991). Computer science educators are justbeginning to address these distinctions and to come to grips with a professionalparadigm shift away from the conventional procedural style (Carey and Shepherd,1988; Luker, 1989; Skublics and White, 1991; Wells and Kurtz, 1989).Because programming languages "[influence] our thinking habits" (Dijkstra, inRich, 1984, p. 7), and "[serve] as a framework within which we organize our ideasabout processes" (Abelson and Sussman, 1985, p. 4), the constructivist perspectivewould suggest a close look at the role of programming language paradigms inshaping teachers' interpretations of programming and teaching programming.In this study, therefore, respondents who have experience in using and teachingvarious programming styles were deliberately selected. The study focuses on thepost-secondary training of computer professionals in an attempt to capture theviews of teachers who are most likely to be cognizant of paradigmatic differences.What Teachers Know about Programming^ 3Similarities and differences between respondents are analysed with particularattention to the paradigms with which they are familiar.Need for the StudyThe results of the existing quantitative research in the area of computerprogramming education are controversial and contradictory (Sharma, 1987; Finlay,1988; Cafolla, 1988; Oman, 1986; Sorge and Wark, 1984; Johanson, 1988; Lemos, 1975;Palumbo, 1990; Ellis, 1989). Studies of factors affecting the acquisition ofprogramming skills yield contradictory results (Finlay, 1988; Oman, 1986; Ellis, 1989).The contention that programming may be successfully used to teach problemsolving has found little supporting evidence (Johanson, 1988; Palumbo, 1990).Controversy surrounds the discussion of best first programming language(Johanson, 1988; Luker, 1989). Several authors have offered explanations for theuncertain results, citing reasons such as poor research methods and varyinginstructional styles (e.g. Johanson, 1988; Salomon and Perkins, 1987; Palumbo, 1990),but none have attempted to capture the underlying interpretations of programmingimplicit in the literature.In order to understand the emerging role of programming paradigms, it is necessaryto examine implicit interpretations of programming. Researchers must be aware ofthe underlying interpretations held by their subjects and by themselves. They mustmake explicit the programming paradigms being used. An exploration of theknowledge constructed by practitioners is a starting point for investigation intothese interpretations. An understanding of teachers' knowledge and the factorswhich affect the construction of that knowledge will allow us to take a moresystematic approach to research in computer science education; to make better senseWhat Teachers Know about Programming^ 4of the discussions of cognitive outcomes, prediction of success, choice of teachingstrategy and choice of programming language.GeneralizabilityAs Erickson (1986) explains, the concept of generalizability takes on a new meaningfor the qualitative researcher. "The search is not for abstract universals arrived at bystatistical generalization from a sample population, but for concrete universals,arrived at by studying a specific case in great detail and then comparing it with othercases studied in equally great detail" (p. 130, emphasis in original). This studygeneralizes in the sense that it is "epistemologically in harmony with the reader'sexperience and thus to that person a natural basis for generalization" (Stake, 1980, p.64). Furthermore, as Eisner (1985) states, "[what] we can productively ask of a set ofideas is not whether it is really true but whether it is useful, ... , whether it enablesone to perceive the phenomenon in more complex and subtle ways ..." (p. 241,emphasis in original).Research QuestionsThis study sets out to examine the articulated perceptions of post-secondarycomputer programming teachers in order to address the following questions:How do teachers organize their knowledge about programming?How do teachers organize their knowledge about teaching programming?How do teachers' constructions about programming integrate with theirconstructions about teaching programming?What Teachers Know about Programming^ 5Terminology and StyleThe field of computer programming makes use of terms that may be unfamiliar tothe reader. Technical terms have been defined in a glossary in Appendix A.To differentiate them from textual quotations, transcript excerpts have beenpresented in italics without quotation marks.What Teachers Know about Programming^ 6CHAPTER TWOREVIEW OF THE LITERATUREComputer Science EducationComputer science education is a very young discipline. The first high-levellanguages were defined in the 1950s and computing education has become prevalentonly in the last twenty years (MacGregor, 1988; Sleeman, Putnam, Baxter and Kuspa,1986; McIntyre, 1991). Despite the relative immaturity of the field, the computer asan object of and an aid to learning has been the subject of considerable research anddebate.This section examines current thinking about the learning of programming: why itis learned; how it is learned; and who is most likely to succeed at learning it.A Focus on ProgrammingProgramming is a major component of post secondary computer science curricula(Ralston and Shaw, 1980; Koffman, Miller and Wardle, 1984; Denning et al., 1989). Itis introduced early in the curriculum (usually in the first course (Hirshfield, 1985))and Wells and Kurtz (1989) go so far as to say that "most people equate computerscience with programming" (p. 246). Since programming appears to be central to thediscipline, much discussion has focused on the acquisition of programming skills.Before examining various aspects of the programming discussion, it is necessary toinvestigate the frameworks within which the discussion is occurring. What ismeant by the term programming, what is it that programmers do, and why do weinclude programming in our curricula?What Teachers Know About Programming^ 7What is Programming?Webster's Third New International Dictionary defines a computer program as "asequence of coded instructions for a digital computer". A programmer is one whoworks out the sequence of instructions. Programming, then, is the act of writing theinstructions. Despite the simplicity of the definition, interpretations of the term aremany.A Classical View.The classical view of programming is articulated in Appleby's (1991) recentcomputer science textbook. The practice of programming, she says, "consists ofprogram design, coding, documentation, and debugging" (p. 3). This definition hasbeen instilled in the minds of computer science educators by way of the ACMrecommended curricula (Denning et al., 1989).An Adaptive View.The classical view contrasts strongly with that of Weinberg (1971) who, inexamining the psychology of computer programming, finds that "programming ... isa single word that encompasses an infinitude of activities" (p. 121). He claims thatthe classical definition, even when extended to include problem definition andanalysis "distorts the truth" (Weinberg, p. 133) in three ways. "First of all, thesequence is not so fixed .... Secondly, not all steps need be present .... Thirdly, it neednot be a sequence at all ..." (Weinberg, p. 133, emphasis in original). The classicaldecomposition, he claims, is too refined. "[The] divisions lack sharp boundaries, orperhaps have no boundaries at all" (Weinberg, p. 133). Sheil (1981) also takes issuewith the prevailing definition of programming. In a review of the psychologicalresearch on programming, he claims that existing research takes "a shallow view ofWhat Teachers Know About Programming^ 8the nature of programming skill" (p. 101). He suggests that programming consists ofa diverse collection of complex learned skills supported by an elaborate knowledgebase.Weinberg's and Sheil's early rather holistic views of programming are echoed byKarp (1989), who speaks of "the inevitable intertwining of software developmentwith specification" (p. 1411). He quotes a colleague, Richard Fateman, who says that"programming ... is more often a process of discovery and adaptation, as variousrelevant components of a problem are examined in turn, and a goal, initiallyspecified incompletely, is reached" (p. 1411).Soloway (1988), retaining the adaptive flavour of Fateman's definition, goes furtherby redefining programming. He says,The term programming is neither accurate nor illuminating:"programming" comes from "program," which is the finalproduct of the synthesis process. Programming does not conveythe type of knowledge and skills that need to go into the process ofdeveloping that product, that artifact (p. 127).By programming, he means "the learning and use of synthesis skills" (p. 122).A Mathematical View.Dijkstra's view differs from both the classical and the adaptive views. In 1989 he"challenged some of the basic assumptions on which [computer science] curriculaare based" (Denning, 1989, p. 1397) in a talk entitled "On the Cruelty of ReallyTeaching Computer Science". To Dijkstra, "the programmer's ... main task is to givea formal proof that the program he proposes meets the equally formal functionalspecification" (Dijkstra, 1989, p. 1404). His interpretation seems to be thatprogramming is mainly a formalized task akin to that of the mathematician orlogician. Several of the esteemed respondents to Dijkstra's recommendations agree,What Teachers Know About Programming^ 9in principle, with his point of view (Denning, 1989). For example, David Parnas(1985), who resigned from the Strategic Defense Initiative Organization because ofhis lack of trust in the ability of programmers to provide for integrity in such asystem, shares Dijkstra's opinions about verifiability. Conventional programmingmethods, he claims, "[lead] to confusion and [result] in systems that nobody canunderstand completely" (p. 1330).Summary.Computer science educators ascribe differing meanings to the term 'programming'.The classical view is widely held, although seldom explicitly stated. The adaptiveview, although delineated by various researchers, does not seem to have made apowerful impact on the way in which programming is taught (Palumbo, 1990).Neither does Dijkstra's mathematical view appear to have strongly affectedcomputer science education (Oliver and Malone, 1991; McIntyre, 1991).What do Programmers Do?Although the three perspectives articulated above differ substantially, there appearsto be agreement that programming involves a process: a sequence of well-definedsteps, an adaptive learning process or a formalized methodology. What does thatprocess entail? Various studies have attempted to determine what programmersare doing when they program.Research indicates that novices' views of programming differ greatly from experts'views (Kurland, Pea, Clement and Mawby, 1989; Mayer, 1989b; McKeithen, Reitman,Rueter and Hirtle, 1981). Novices tend to hold a surface view of programming,relying on format and syntactic properties of code, whereas experts rely on a morefunctional organization based on underlying structures of problems and solutionWhat Teachers Know About Programming^ 10strategies. In programming studies analogous to the classic study of expert andnovice chess players (Chase and Simon, 1973), experienced programmers couldrecall more lines of code from a working program than could novices. Howeverexperts and novices performed equally when the program was made up of randomstatements (Mayer, 1989b; McKeithen et al., 1981). Other research shows that theredo exist in novices categories of alternative frameworks or "underlying problems"(Spohrer and Soloway, 1989, p. 411) that are independent of programming language(Joni and Soloway, 1986; Pea, 1986; Soloway, Ehrlich, Bonar and Greenspan, 1982;Sleeman et al., 1986; Lee and Lehrer, 1988; Scherz, Goldberg and Fund, 1990; Putnam,Sleeman, Baxter and Kuspa, 1989). Some argue, then, that expert programmers havewell-developed frameworks not shared by novices which, for them, provideworking interpretations of computer programs.What is it that expert programmers are doing that differentiates them from novices?Schwartz's (1975) list of recommendations concerning what programmers shouldknow may shed light on this question. Firstly, he says, programmers shouldunderstand algorithms. That is, they should recognize and understand "important"(p. 21) algorithms, by which he means well-known ones. Programmers should alsounderstand that some processes cannot be performed by a program and that somecan be performed only very inefficiently. Secondly, programmers shouldunderstand "semantic frameworks, which allow individual algorithms to beorganized into large program structures" (p. 21). Thirdly, Schwartz feels thatprogrammers should have "a conscious view of the programming process," andshould "understand the way in which programs, in their earliest origins, coalesceout of less organized intellectual structures" (p. 21). Schwartz's recommendationsallude to deep underlying structures which shape the way in which expertprogrammers work. Expert programmers are operating at a level much deeper thanWhat Teachers Know About Programming^ 11that at which novices are working. In order to inform the discussion ofexpert/novice differences, Palumbo (1990) and Shneiderman and Mayer (1979)differentiate between syntactic and semantic knowledge. Palumbo states that expertshave "two major attributes: a solid command of the factual, declarative, or linguisticbase necessary to solve the problems presented; and a collection of effectivestrategies for employing that base when solving related problems" (p. 70).Pennington (1985), delves more deeply into expert programmers' frameworks byexamining professional programmers' mental representations of programs. Shedifferentiates between procedural abstraction and functional abstraction. Aprogrammer using procedural abstraction will segment a program into groupingswhich reflect the control structures of the programming language. The program issegmented based on clues in the language syntax. The programmer usingfunctional abstraction, on the other hand, sees patterns in the code which representstereotypical functional units. The segmentation reflects the dataflow structure ofthe program, rather than the control flow. That is, functional abstraction dependson what is happening in the program, rather than on how it is happening. Theprogrammer is able to segment the program based on partial pattern matches toknown functional units. Pennington found that most programmers usedprocedural abstraction. She also found a difference between COBOL and Fortranprogrammers, leading her to wonder if the programming language may affect thedifficulty of extracting information from the program text. She does not considerthat perhaps COBOL and Fortran programmers conceptualize programming indifferent ways.What Teachers Know About Programming^ 12Thus research shows that expert programmers make use of a broad base of syntacticknowledge and an organized framework which allows them to use that knowledgebase to solve problems.Why Is Programming Taught?There are three primary reasons for which programming is included in schoolcurricula: the training of programming professionals, computer literacy and thedevelopment of thinking skills (Salomon and Perkins, 1987; Becker, 1986; Schultzand Hart, 1983).Professional Training.Programming is taught, in an industrial setting and at the post-secondary level, forthe purpose of training professional programmers, scientists and engineers -- thosewho would program computers to perform specific job-related tasks. Despite the factthat a decreasing demand for professional programmers is predicted with theintroduction of each new high-level tool, from the creation of the first high-levellanguages in the 1950s to the recent widespread acceptance of Computer AssistedSoftware Engineering (CASE) tools, industry demand for entry-level programmerscontinues to grow (March, 1989; Rifkin, 1989). Thus professional training continuesto be a major goal of programming instruction, particularly at the post-secondarylevel.Computer Literacy.With the increased acceptance and availability of computers in the early 1980s,computer literacy for all students became the goal of many curricula. The prevailingview was that in order to be computer literate, one needed to be able to program(Kay, 1989). This view of computer literacy led to the inclusion of a largeWhat Teachers Know About Programming^ 13component of programming in introductory computing courses taught to non-computer science majors at secondary and post-secondary levels. Although "theprogramming outlook might be outdated" (Kay, p. 37) and despite the sense that"the programming approach has been superseded" (Kay, p. 37) by computerapplications, many schools continue to teach programming in literacy courses(Computer Studies 11 Curriculum Guide and Resource Book 1984; Becker, 1986).Cognitive Skills Development.A more widespread justification for the teaching of programming to all students is"its possible impact on generalizable cognitive skills" (Salomon & Perkins, 1987, p.149). As Linn (1985) points out, "the avowed purpose of most programming coursesis to teach problem solving or reasoning as well as to teach programming" (p. 14).Papert (1987), an early proponent of teaching programming, says that programmingexperiences can provide the learner with new ways of thinking. For him, thecomputer's "deepest role is cultural rather than instrumental. What is important ...is not that the child drew a circle, ... but that this way of working ... provides newways to think about circles, and through them, new ways to think aboutmathematics more generally" (p. 29). Feurzeig (1988), in a discussion of the teachingof mathematics in the context of programming, states that "programming provideshighly motivated models for fostering the development of the principal heuristicand metacognitive skills" (pp. 102-103). Despite these widespread claims, Liao andBright (1991), in a meta-analysis of existing research, found only slightly positiveresults in terms of the effect of learning programming on students' cognitive skills.Educational researchers, rather than questioning the premise that teachingprogramming can potentially affect thinking skills, tend to express the opinion thatresults have not been forthcoming because of the way in which programming hasWhat Teachers Know About Programming^ 14been taught in the past or because of problems with the way in which the researchhas been conducted (Johanson, 1988).Summary.Programming continues to be included in curricula for three primary purposes,then: the training of programming professionals, the education of computer literateusers and the development of students' thinking skills. The purpose for whichprogramming is taught, as well as the interpretation of what the programmingprocess involves, will fundamentally affect the nature of programming education.Nonetheless, most authors writing about teaching programming do not explicitlydescribe what they mean by programming nor why they think it ought to be learned.Current IssuesSeveral bodies of research have taken shape within the computer science educationliterature. Extensive research has been done in the area of predicting success incomputer science and, particularly, programming courses. As well, teachingapproach, mode of learning, use of models and choice of programming languagehave been studied.Predicting SuccessMuch research has been carried out in the area of programming skill prediction.Ellis (1989) lists 52 studies which were performed at secondary and post-secondarylevels in the past twenty years. Predictor variables typically examined may begrouped into four types: prior achievement, aptitude measures, cognitive andpsychological measures, and environmental variables.What Teachers Know About Programming^ 15Prior Achievement.Grade Point Average (GPA) and mathematics achievement are the most commonpredictor variables studied (Sall, 1989). Typically predictor studies examine a largenumber of variables (Greer, 1986; Sorge and Wark, 1984; Finlay, 1988). An exemplarof these studies is that of Petersen and Howe (1979), who examine variousenvironmental variables as well as high school achievement, personality types andgeneral aptitude. They found GPA to be a good predictor of success in introductorycomputer science as did several others (Ellis, 1989). Prior mathematics achievement,although a reasonably good predictor, does not appear to merit the importance itseems to have acquired as a prerequisite for computer science students (Finlay, 1988;Schulz, 1984).Aptitude Measures.A study carried out by Morecroft and Ameen (1987) is representative of the kind ofresearch being done in the area of aptitude (e.g., Guinan and Stephens, 1988; Bitterand Lu, 1988; Oman, 1986). Grades of students majoring in post-secondary levelInformation Systems were related to Scholastic Aptitude Test (SAT) scores. Inaddition, students were separated into two groups: those who completed theircourse of studies and those who did not. Although several studies have shown thatSAT scores are a good predictor of programming success (Oman, 1986; Sorge andWark, 1984; Leeper and Silver, 1982), Morecroft and Ameen find that there is littledifference in scores between those who complete their major and those who do not.They conclude, in fact, that the best predictors for success in an Information Systemscourse of studies are students' grades in their introductory courses.What Teachers Know About Programming^ 16Cognitive and Psychological Measures.A review by Sharma (1987) summarizes investigations into relationships betweencognitive style and psychological type variables and performance in computerscience courses. Typical cognitive studies examine measures such as analytic-heuristic styles (e.g., Cheney, 1980), analytic and deductive reasoning (e.g., Bitter andLu, 1988) and field dependence (e.g., Stevens, 1983). Psychological variables studiedinclude Myers-Briggs personality types (e.g., Corman, 1986; Mawhinney andSaraswat, 1991), learning styles (e.g., Corman, 1986) and motivation (e.g., Watsonand Behnke, 1991). Although Sharma (1987) concludes that "it is reasonable todeduce that learners' cognitive styles and psychological characteristics should beconsidered in the planning of programs and strategies" (p. 396), he points out that"there seems to be a general feeling of uncertainty and indecisiveness as to who canbenefit from computer-oriented tasks" (p. 397). That is, although there are somepromising results arising from the cognitive and psychological studies, thereappears to be confusion about the implications and applications of the specificresults.Environmental Variables.Typical of the environmental variables examined are those investigated by Finlay(1988). She correlates university students' educational backgrounds (i.e. universitymajors), previous level of mathematical training, previous computer experience,attitude, age and gender to their results in a postgraduate course in InformationProcessing. Most studies which examine environmental variables correlate them toresults in a single course or to students' averages in all coursework (e.g., Greer, 1986;Sorge and Wark, 1984; Oman, 1986). In contrast, Finlay studies the relationship ofthe variables to each of the courses in the students' program and compares theWhat Teachers Know About Programming^ 17results. Interestingly, she finds that factors which predict success in certainprogramming courses do not predict success in others (p. 40). This result highlightsthe inherent difficulty in evaluating research without explicit knowledge of theresearchers' and educators' tacit understanding of what programming entails, andwithout explicit information about the sense of programming being understood bythe students, that is, its meaning and purpose.Summary.Ellis (1989) states that the studies he reviewed generally indicate that a student witha strong mathematics and science background, a high grade point average and a highprogramming aptitude score is likely to succeed in an introductory computer sciencecourse (pp. 25-26). However, there is much controversy about which variables mostaccurately predict programming success (Sharma, 1987; Finlay, 1988; Cafolla, 1988;Oman, 1986; Sorge and Wark, 1984). It appears that much of the confusion and lackof generalizability stems from the fact that researchers typically predict success inprogramming in general based on results achieved in one specific situation. Thereexist varied interpretations of the meaning, process and purpose of programming.ApproachesVan Merrienboer and Krammer (1987), in a discussion of instructional designprinciples for introductory programming courses, outline four categories of skillstypically addressed in introductory programming courses: use of the programmingenvironment; programming language syntax; language semantics and analysis; andprogram generation. They find, however, as do Linn (1985), McIntyre (1991) andJohanson (1988), that "introductory courses often emphasize learning the features[of a language] rather than how to use them to solve problems" (Linn, 1985, p. 15).Throughout the 1970s, programming courses were courses in language syntax. InWhat Teachers Know About Programming^ 18the past decade, however, the emphasis in programming courses has been onproblem solving rather than on syntax (Van Merrienboer and Krammer, 1987). Thedifficulty with this approach is that students tend to spend more time coding anddebugging than they do planning, designing and testing their algorithms (VanMerrienboer and Krammer, 1987).The introduction of the concepts of structured programming in the mid-1970sgreatly influenced the way in which programming is taught (McIntyre, 1991; Ghezziand Jazayeri, 1987). The structured approach is so well entrenched that VanMerrienboer and Krammer (1987) "presuppose the use of a structured programminglanguage" (p. 255) in the instructional strategies that they evaluate. They identifythree widespread strategies for the teaching of computer science: the expertapproach, the spiral approach and the reading approach.The Expert Approach.The expert approach is characterized by the immediate introduction to students ofnon-trivial problems. Students are expected to solve problems in a structuredmanner. That is, in the design of algorithms and program code, they work withinthe constraints of a structured language and a set of "discourse rules" (Joni andSoloway, 1986, p. 99) that an expert programmer would use. Typical of the expertapproach is the adoption of the 'stepwise refinement' model which stresses the top-down design of problem solutions. Students are presented with explicit designdiagrams and worked-out examples. Thus students concentrate on planning andhigh-level semantic content rather than on programming language syntax and basiccomputer usage. The expert approach, computer science's counterpart of thescientific method, is widely used and has been the subject of much research andWhat Teachers Know About Programming^ 19debate (McIntyre, 1991; Van Merrienboer and Krammer, 1987; Brady et al., 1989;Ezell, 1990; Ferchichi and Jaoua, 1987; MacGregor, 1988).The Spiral Approach.The spiral approach, as defined by Shneiderman (1977),is the parallel acquisition of syntactic and semantic knowledge in asequence which provokes student interest by using meaningfulexamples, builds on previous knowledge, is in harmony with thestudent's cognitive skills, provides reinforcement of recentlyacquired material and develops confidence through successfulaccomplishment of increasingly difficult tasks (p. 193).Van Merrienboer and Krammer (1987) define syntactic knowledge as "unorganizedknowledge of low level details" (p. 256). Semantic knowledge is "hierarchicallyorganized knowledge" of concepts (p. 256). Using the spiral approach, students arepresented with simple ideas in an incremental hierarchical manner in order tofoster the development of more complex forms of knowledge. Program generationis stressed. The first problems presented to the students are somewhat trivial,emphasizing syntactic and low-level semantic knowledge. As the students gaincompetence, more complex specifications are introduced and the emphasis shifts tothe design process. The spiral approach does not appear to have been widelyadopted in practice (Shneiderman, 1977; Shneiderman and Mayer, 1979;Marchionini, 1985).What Teachers Know About Programming^ 20The Reading Approach.The reading or 'whole language' approach "emphasizes the reading, modificationand amplification of non-trivial, well-designed and working programs" (VanMerrienboer and Krammer, 1987, p. 257). Students at first observe and evaluate theexecution of working programs. They are then introduced to well-structuredprogram code, which they read and trace. The next phase of the reading approachinvolves the modification of existing programs and practice with simple design andcoding. In the final phase, students write their own programs. Hence the students'tasks become more complex as the course progresses while the complexity of theprograms presented remains constant. The reading approach has been supported byBork (1971), Postma and Laing (1981) and Dalbey, Tournaire and Linn (1985).Summary.Few reports have been found which compare the success of various approaches toteaching programming. Results of the studies that do exist are conflicting (Lemos,1975; Postma and Laing, 1981; Dalbey et al., 1985; Van Merrienboer and Krammer,1987; MacGregor, 1988). Studies of educational approaches normally do not examineimplicit views of programming.Mode of LearningClarke (1989), in his discussion of instructional approaches, outlines three modes oflearning commonly used in the programming classroom: group interaction,discovery and lecture.What Teachers Know About Programming^ 21Group Interaction.As Weinberg (1971) notes, "Programmers do not ordinarily work in isolation.Although an individual programmer may find himself assigned the task of writinga program, even then he has other programmers to whom he may turn for help --and who, at the same time, may be turning to him" (p. 45). He differentiatesbetween the programming group and the programming team. The latter is a formalgroup established to work together on a single program. The former is a collectionof programmers grouped together informally by virtue of the fact that they work inproximity to one another -- at a school, a computing centre or in a computerdepartment. Interaction between programmers in both circles is important, hefinds, in promoting egoless programming, support and creativity.MacGregor (1988), Lemos (1978) and Webb, Ender and Lewis (1986), among others,studied the effects of group work on programming students' success. All found"positive relationships between group interaction and programming achievement"(MacGregor, 1988, p. 156). In particular, they found that discussion with othersallows students to explore their conceptions about the action and outcomes ofcomputer programs. Activities such as hand-tracing (tracing a program on paper),and walkthroughs (verbally tracing program behaviour in a group environment)are used by professional programmers and have been found to be applicable to theclassroom environment.Discovery Learning.Several educators support the concept of discovery learning. Bork (1971) explainsthat using this approach, "the student sees no didactic material, encounters nogrammatical information, hears no lectures about the language; but he does learn touse it simply by interacting with the language compiler itself" (p. 5). Bork (1971),What Teachers Know About Programming^ 22Dalbey and Linn (1985) and Shneiderman (1985) all contend that discovery-stylelearning will enhance students' success. However, as Dalbey et al. (1985) point out,use of the discovery method alone may preclude instruction in planning skills feltto be essential for advanced programming tasks.Lecture Mode.The use of lectures is a common approach to teaching programming. As Clarke(1989) explains, with this approach "all instruction takes place in the lecture room.At the completion of the lecture, the instructor departs and the students move to alaboratory to put the theory into practice" (p. 14). Dalbey and Linn (1985), in areview of various teaching methods, find that this approach is popular oftenbecause of practical constraints in the learning environment. Comparisons withother learning techniques show that students prefer situations that promote activestudent involvement and in which they have more control over their learning(Clarke and Donn, 1990). In a comparison of lecture-style learning to lab-stylelearning, Clarke and Donn (1990) conclude that a combination of styles may be mostappropriate, with syntactical rules being best taught using a lecture method (p. 21).Summary.Thus three modes of learning are primarily used when teaching programming:Lecture mode, hands-on learning and group interaction.Salomon and Perkins (1987) believe that differences inprogramming instruction are one of the possible reasons someresearch has yielded significant results in the relationship betweenprogramming language instruction and problem-solving skills,whereas other research has not (Palumbo, 1990, p. 78).What Teachers Know About Programming^ 23Instructional techniques, grounded as they are in understandings of what it meansto program, must be explicitly outlined so that valid comparisons of variousoutcomes can be made.ModelsModels and analogies can be helpful in leading students to adopt new conceptualframeworks (Brown and Clement, 1987). It may appear self-evident that the modelsand analogies used must be plausible to the student, but there are many examples incomputer programming of analogies that are useful to experts yet meaningless tostudents (Lee and Lehrer, 1988; Kahney, 1989; Putnam, et al., 1989; Du Boulay, 1989).A common difficulty with the use of analogy is that experts, because of theirconceptual frameworks, see the similarities between the things being compared,whereas students, with different conceptual frameworks, may focus on aspects thatare either irrelevant or dissimilar. Thus students who are told that a variable is likea box may assume that a variable may contain more than one value at a time like abox (Putnam et al., 1989). As well, students' own models and analogies, such as theanthropomorphic model described by Shneiderman (1988), may not be viable. It istherefore important that students become overtly aware of aspects of models andanalogies that fit programming processes and those that do not.Research into the learning of computer programming with and without models(Mayer, 1975; Hancock, 1988; Mayer, 1989a; Bracey, 1989) supports the view that aconcrete model enhances students' understanding of the workings of computerprograms. Interestingly, there is some indication that models help lower abilitystudents more than higher ability students and that models "may actually interferewith high ability learners who already have a rich set of more sophisticatedknowledge" (Mayer, 1975, p. 733).What Teachers Know About Programming^ 24Choice of LanguageThe choice of appropriate programming language has been the subject of a great dealof debate. Perhaps this issue is so contentious because, as Abelson and Sussman(1985) state, "[the programming] language ... serves as a framework within which weorganize our ideas about processes" (p. 4). The discussion of programming languageparallels the discussion of natural language: "It is widely believed that our thinkingis restricted by the expressive power of the language in which we communicate ourthoughts. ... Programmers in the process of developing software are similarlyconstrained" (Sebesta, 1989, p. 2). There are those computer scientists, such asConnors, who claim that a "properly trained programmer thinks primarily in termsof programming, only secondarily in terms of a particular language" (in Rich, 1984,p. 7). On the other hand, there are those who, like Dijkstra, believe that "aprogramming language ... [exerts] an influence on our thinking habits" (in Rich,1984, p. 7).As Sammet (1991) points out,an exact count of all the high-level languages ever used isimpossible even for those used in the United States .... However,since it is possible to name over 1000 that have been used at onetime or another since 1953, it is not unreasonable to assume thatthere are several hundred outside the United States ... (p. 48).Sammet asks why so many languages have been created and conjectures that thereare two main reasons for their proliferation: functional needs and personal needs.She lists several general and specialized application areas which require specificfunctions. As well, she contends that implementation requirements and sizerequirements have contributed to the large number of languages in existence.However, she feels that personal needs have been even more influential in thedevelopment of languages and cites five of them:What Teachers Know About Programming^ 251. personal taste regarding style and syntax,2. personal opinion regarding language design issues,3. the fun of language design,4. the availability of research grants and contracts for the development ofnew languages, and5. the ease with which one can publish papers about new languagedesign.Just as new languages are developed to fulfil personal and functional needs,languages for classroom use are often chosen for similarly practical reasons.Woodhouse (1983) outlines five criteria for the selection of language inprogramming courses:1. the availability of a system which can use the language,2. teacher knowledge,3. ease of teaching and learning,4. the functionality of the language, and5. whether the language is structured.Woodhouse's (1983) recommendations for secondary school computing are echoedat the post-secondary level by Pandey (1990).Not all recommendations about language are based on practicalities, however.Various opinions about the proper language for introductory programminginstruction have been expressed, with the most vociferous debate surrounding theWhat Teachers Know About Programming^ 26question of whether to teach BASIC or Pascal (Ellis, 1989). Authors advising the useof Smalltalk (Skublics and White, 1991; Borne and Girardot, 1990), PROLOG(Johanson, 1988) and LISP (Grogono, 1989) have recently joined the fray.Unfortunately, little empirical research has been done, leading one to theconclusion that what Sammet (1991) would call personal needs are being used toshape opinion.It appears that the lack of agreement about which programming language is 'best' forindustry and educational use stems from the many differing functional andpersonal needs perceived by computer scientists and educators. Again the purposefor which the language will be used and the underlying personal understandings ofprogramming will shape the decision about language.The Paradigm Shift"Never mind the language, what about the paradigm?" asks Luker (1989, p. 252).There are increasing indications that a paradigm shift is occurring in the computerindustry and in computer education (Johanson, 1988; Grogono, 1989; Abelson andSussman, 1985; Skublics and White, 1991; DiNitto, 1988). In the introduction to hertext, Programming languages: Paradigm and practice,  Appleby (1991) outlinesWegner's notion of programming language paradigms. His ideas are an extensionof the concept of scientific paradigm introduced by Kuhn (1962). Wegner feels thatas computer science matures, distinct language paradigms are emerging.Furthermore, the breakdown of older paradigms can be seen in the current feelingthat the computer industry is experiencing a software crisis: software costs areoverinflated and the integrity of major software projects is highly questionable(Luker, 1989; Parnas, 1985; Dijkstra, 1989).What Teachers Know About Programming^ 27Current researchers generally agree upon the following classifications of language(Appleby, 1991; Pete and Winder, 1990; Sebesta, 1989; Wells and Kurtz, 1989):Imperative languages:Imperative languages imply an underlying machine whose state is manipulatedexplicitly by program instructions. This type of language is characterized bysequential declaration and assignment instructions, which manipulate the contentsof computer memory. The imperative language class may be split into two sub-classes:A. Procedural or Block structured languages: Procedural languages allowfor modularization of code in the form of procedures or functions. Anexample is Pascal.B. Object-oriented languages: Object-oriented languages support interactingobjects. All data are objects, all objects are treated uniformly, and allprocessing is done by passing messages among objects. An example isSmalltalk.Declarative Languages:Declarative language programs specify relations or functions. The emphasis is onwhat is to be done, rather than on how to do it. An algorithmic engine embedded inthe language implementation produces a solution based on the constraints specifiedby the programmer. The declarative language class may be split into two sub-classes:A. Logic Languages: Logic languages are based on a subset of predicatecalculus. A logic program consists of a series of rules and facts and a theoremto be proved. An example is PROLOG.What Teachers Know About Programming^ 28B. Functional Languages: Functional languages operate only throughfunctions, which return a single value. The value of a function isdetermined solely by the values of its arguments and there are no statechanges. An example is LISP.Figure 1 graphically displays the relationships between languages.Programming ParadigmsI I^ IImperativeI^I II^I^IProcedural^Object-oriented^Logic Functional(e.g. Pascal)^(e.g. Smalltalk)^(e.g. PROLOG)^(e.g. LISP)Figure 1. Programming ParadigmsThe above classifications are not mutually exclusive. In other words, a languagemay have the attributes of more than one paradigm. For example, ADA is aprocedural language which supports some object-oriented features.The discussion of which language to teach has now taken on a different tone.Authors of recent publications are arguing in favour of languages because of theparadigm that they represent, rather than because of features specific to thelanguages per se. As well, research into the learning of new paradigms is beingundertaken (Carey and Shepherd, 1988). Many post-secondary institutes havefollowed M.I.T.'s lead in adopting a functional language (Scheme) as the firstprogramming language (Abelson and Sussman, 1985; Reid, 1992). Object-orientedDeclarativeWhat Teachers Know About Programming^ 29languages are being taught from primary grades (Borne and Girardot, 1991) touniversity (Skublics and White, 1991; Temte, 1991).Educators are finding that students schooled in one programming paradigm havedifficulties shifting to a new one (Carey and Shepherd, 1988; Skublics and White,1991; Wells and Kurtz, 1989). Therefore, there are some proposals to teach multipleparadigms in the first programming course (Appleby, 1991; Sebesta, 1989; Wells andKurtz, 1989).The maturation of the fields of computer science and computer science educationhave led to a cleaner differentiation of programming and programming languages.It would appear that a programmer working in one paradigm will have a verydifferent view of programming than a programmer working in another paradigm.The paradigm chosen for a specific course may depend on the purpose for whichprogramming is being taught. Furthermore, it is possible that different variablesmay predict success in different paradigms. Educational methodologies willcertainly be affected by choice of programming paradigm. Thus studies of thesecurrent issues must be informed by an investigation of programming paradigm.What Teachers Know About Programming^ 30Research PerspectiveJacob (1988), in an overview of qualitative research in education, points out thatwithin the last ten years researchers have been challenged to "transcend the limitsof positivism" (p. 16). Magoon (1977), Wilson (1977), Howe and Eisenhart (1990) andLincoln and Guba (1985) are among the scholars who have tried to make sense ofwhat Howe and Eisenhart (1990) call "the proliferation of qualitative methods ineducational research" (p. 2). Magoon (1977) contends thatthe prime phenomena for the educational researcher may well beat their most basic level unavoidably sophisticated and highlyorganized. ... it is not surprising that a social anthropologicalmethodology, which seeks to explicate the relationships amongsuch phenomena as well as other factors, has such appeal (p. 652).Although the term 'qualitative research' necessarily means different things todifferent people, Jacob (1988) says, four themes emerge from the discussion ofalternatives to the traditional positivist approach: "the importance of conductingresearch in a natural setting", "the importance of understanding participants'perspectives", the necessity that "researchers subjectively and empathetically" knowthe participants' perspectives and the emergence of theories and questions from thedata collection (p. 16).Qualitative research is carried out in a natural setting and, as Lincoln and Guba(1985) state, "the major and sometimes only data collection instrument utilized innaturalistic inquiry is the inquirer him- or herself" (p. 267). Wilson (1977) says that"a researcher seeking to understand behavior must find ways to learn the manifestand latent meanings for the participants ..." (p. 253). Qualitative studies typicallyattempt to uncover these meanings through the use of interviews (e.g., Posner et al,1982; Cardwell, 1988; Spradley, 1979) and case studies (e.g., Nussbaum and Novick,1982; Yackel et al., 1990).What Teachers Know About Programming^ 31According to Lincoln and Guba (1985), "Events or situations are theoretically open toas many constructions as there are persons engaged in them, or as manyreconstructions by a single individual as imaginations allows" (p. 77). They statethat the researcher working in the "naturalist paradigm" (p. 37)is likely to eschew random or representative sampling in favor ofpurposive or theoretical sampling because he or she therebyincreases ... the likelihood that the full array of multiple realitieswill be uncovered; and because purposive sampling can bepursued in ways that will maximize the investigator's ability todevise grounded theory that takes adequate account of localconditions, local mutual shapings, and local values ... (p. 40).Studies of teachers' constructions are based on the sense that "the practical wisdomof competent teachers remains a largely untapped source of insights for theimprovement of teaching" (Feiman-Nemser and Floden, 1986, p. 505). "Theprevailing view among most researchers is that teachers have experience whileacademics have knowledge" (Feiman-Nemser and Floden, 1986, p. 512). Variousresearchers have attempted to tap this source of useful experience (Elbaz, 1983;Cardwell, 1988; Lortie, 1975; Connelly and Clandidin, 1985).Wilson (1977) states, in the context of case study research, that "participants mustcome to trust and value the observer enough to be willing to share intimatethoughts with him and answer his endless questions" (p 254). In the same vein,Woods (1986) discusses the need in an interview for a sense of trust, curiosity andnaturalness on the part of the researcher. In his definition of a depth interview, theinterviewer is viewed as a peer. The interview is open-ended and the respondentmay ask questions of the interviewer. Spector (1984) also favours the open-endedinterview. Massarik (1981) presents six interview typologies ranging from thehostile interview, in which "the atmosphere is one of mutual distrust andantagonism" (p. 201) to the phenomenal interview, which is "characterized byWhat Teachers Know About Programming^ 32maximal mutuality of trust, attaining genuine and deeply experienced caringbetween interviewer and interviewee and a commitment to joint search for sharedunderstanding" (p. 203). Lincoln and Guba (1985) state that "the interview asutilized in naturalistic inquiry ... is usually unstructured" and "is almost alwaysfully overt" (p. 269). The sense of a naturalistic interview, then, is that"[interviewer] and respondents, through repeated reformulations of questions andresponses, [will] strive to arrive together at meanings that both can understand. Therelevance and appropriateness of questions and responses [will emerge] through and[be] realized in the discourse itself" (Mishler, 1986).As Spradley (1979) puts it, respondents are "nonanalytic" (p. 52) about theirtechniques; they respond "from the perspective of the insider" (p. 52) rather thanfrom an outside theoretical perspective. In order to obtain the trust and openness ofthe respondents and in order to "subjectively and empathetically" (Jacob, 1988, p. 16)know their perspectives, it is useful for the researcher to be and be perceived in theinterview situation to be a peer of the respondents. However, it is also useful forthe researcher to express ignorance (Spradley, 1979) and to "constantly monitor andtest his reactions" (Wilson, 1977, p. 259) so as to maintain the "tension in point ofview -- between outsider and insider ..." (Wilson, 1977, p. 259).We confuse ourselves if we believe that the people whosebehavior we are concerned with, whether we observe them orinterview them, can themselves provide an adequate explanationof their own behavior. That is our job, and the participantobserver makes inferences from the data he collects just as thesurvey analyst makes inferences from the data collected for him(Trow, 1970, p. 148).It is the job of the researcher to make sense, within his or her own framework, ofthe data collected. Eisner (1985) states that in order to "distinguish the significantfrom the trivial" the researcher needs "a set of ideas, theories, or models" (p. 221).What Teachers Know About Programming^ 33"We do not see and then assess significance" (p. 222), he says. "The essence ofperception is that it is selective; there is no value-free mode of seeing" (p. 222).Spector (1984) cautions the researcher to "be on guard with regard to his own colorsof observation" (p 461), but Glaser and Strauss (1970) comfort the nervous researcherby suggesting that she trust in her own knowledge when analysing qualitative data."Categories and properties," they claim, "have a life apart from the evidence thatgave rise to them" (Glaser and Strauss, 1967, p. 36). These categories are establishednot a priori, but as the data is gathered and as hypotheses are generated (Spector,1984). Thus, to Spector (1984) (as to Lincoln and Guba (1985) and Glaser and Strauss(1967)) qualitative research involves not hypothesis testing, but hypothesisgeneration. According to her, descriptions of the world the subjects live in as theysee it constitute a major segment of the reported results of a qualitative study. It isnecessary, she says, to retain the subjects' own words because they provide"important insights into how they define their world" (p. 460).Lincoln and Guba (1985) and Glaser and Strauss (1967) present slightly differentversions of the constant comparative method of qualitative data analysis (Grove,1988). The constant comparative method involves the identification in interviewtranscripts of individual data items (called "incidents" by Glaser and Strauss and"units" by Lincoln and Guba). These items are coded on index cards and thencategorized intuitively by comparing individual items to one another. As thenumber of items in a category increases, the category is labelled and provisionalrules are established which determine the items that are to be included in it. Asoverlapping categories are integrated, the number of categories diminishes. AsSpector (1984) says, the constant comparative method is not meant to establishuniversality or proof of suggested causes but rather to provide category groupings,What Teachers Know About Programming^ 34identification of category properties and clues to the relationships betweencategories.What Teachers Know About Programming^ 35CHAPTER THREERESEARCH METHODThis study examines the articulated perceptions of computer programming teachersin order to address the following research questions:1. How do teachers organize their knowledge about programming?2. How do teachers organize their knowledge about teachingprogramming?3. How do teachers' constructions about programming integrate with theirconstructions about teaching programming?Data Collection ProceduresData consists of:two interviews with each of six post-secondary programming teacherscopies of course materials (outlines, handouts) from each teacherAll interviews but one took place at the respondents' schools. The goal of the in-depth unstructured interviews was to elicit the respondents' views aboutprogramming and teaching. Thus, the interview protocol was used as a guideline,but interview questions were paraphrased and their sequence rearranged duringeach interview based on the respondent's replies. The section entitled Results of thePilot Study, below, includes an annotated version of the interview protocol and asample transcript is included in Appendix B. Before the interview sessions, therespondents sent me copies of a course outline and assignment from a languageWhat Teachers Know About Programming^ 36course they were teaching. I analysed these materials and prepared specificquestions about their content. I also took to the interviews a program written in alanguage that the respondent was teaching so that it could be referred to as necessary(See annotated interview protocol below for details). The second interview wasconducted within one week of the first and was used partially as an opportunity forboth researcher and respondent to clarify and comment on issues arising from thefirst interview. After the first interview all respondents mentioned issues whichthey had been considering.Sampling"Purposive sampling" was utilized in order to uncover the "multiple realities" and"mutual shapings" (Lincoln and Guba, 1985, p. 40) held by teachers of each of thefour programming paradigms outlined in chapter two.Recall Figure 1 from chapter two, which classifies emerging programming languageparadigms:Programming ParadigmsI I^ IImperative DeclarativeI 1^I^I^I^1Procedural^Object-oriented^Logic Functional(e.g. Pascal)^(e.g. Smalltalk)^(e.g. PROLOG)^(e.g. LISP)Figure 2. Programming ParadigmsAs described earlier, imperative languages deal with how actions are to be carriedout. Imperative languages may be classified as either procedural (i.e., languagesWhat Teachers Know About Programming^ 37which are based on the notion of functional units) or object-oriented (i.e., languageswhich are based on the notion of interacting objects). Declarative languages dealwith what is; they specify relationships and depend on a built-in facility todetermine how to produce a solution. Declarative languages may be classified aseither logic (i.e., languages which allow the specification of rules and facts) orfunctional (i.e., languages which allow the specification of mathematical functions).The sense that "a programming language ... [exerts] an influence on our thinkinghabits" (Dijkstra in Rich, 1984, p. 7) shaped the selection of respondents. The sixpeople interviewed were selected because of the language paradigms in which theywork. Table 1 outlines the paradigms with which each respondent is familiar.Most respondents have had experience in more than one language paradigm and allhave extensive experience with procedural languages. Claire's experience isrestricted to the procedural paradigm with minor exposure to a functional language.All of the other respondents have taught or used more than one paradigm andtherefore were able to offer insights into the differences and similarities theyperceive in them.What Teachers Know About Programming^ 38Table 1Respondents' ParadigmsParadigmRespondent Procedural Object-oriented Functional LogicClaire Y N S NIsaac Y S S SLorne Y Y S YKyle Y Y Y YMario Y Y Y YRoss Y S Y YNote. Y = Yes. The respondent has taught or is currently working in the paradigm.N = No. The respondent has never taught or worked in the paradigm.S = Some. The respondent has at some point used the paradigm, but is notcurrently working in it.Because this study focuses on the teaching of professional programmers,respondents were selected from two post-secondary institutes, the University ofBritish Columbia and the British Columbia Institute of Technology. Neitherinstitute requires that instructors have formal teacher training. Thus therespondents' instructional approaches and methods have been shaped by somethingother than exposure to formal teaching methodologies.What Teachers Know About Programming^ 39I conducted all of the interviews. Because I am a colleague and friend of therespondents in the study, the interviews had an openness that might not otherwisehave been possible and allowed them to take the form of what Massarik (1981) terms"depth interviews" (p. 203).Interpretation and AnalysisThe interviews were audiotaped, transcribed and then edited for accuracy against themaster tapes. I read each respondent's transcripts several times in order to get asense of the respondent's use of language and metaphor and to extract salient items,representing "the smallest pieces of meaningful information" (Grove, 1988). Usingthe constant comparative method, I then identified themes which emerged fromeach respondent's interview sessions. These themes were grouped into twosections: the respondent's knowledge about programming, and the respondent'sknowledge about teaching programming. The two groups were then compared forcommon themes and patterns. The results of each respondent's interviews wererecorded in three sections: knowledge about programming; knowledge aboutteaching programming; and the integration of knowledge. In the final stage ofanalysis, themes and patterns were analysed across respondents, again using theconstant comparative method. Differences and similarities between respondentswere noted and more global themes and patterns were identified.Pilot StudyA pilot study was conducted with two teachers from one of the institutes used in themain study. In this section I report the results of the pilot study interviews andexplain the ways in which the main study was altered based on the experience Igained from conducting the pilot study. Both of the teachers interviewed in thepilot study, James and Melissa, have strong procedural backgrounds. Melissa'sWhat Teachers Know About Programming^ 40experience is restricted to the procedural paradigm. James also has experience usingthe object-oriented paradigm.Jamesproducing really fascinating imagesI have known James for ten years. He was my teacher for one year and I haveworked with him for the past six years. Our interview took place in my office at theUniversity of British Columbia, where James had come to hear a lecture aboutgraphics. James referred to the lecture frequently during our discussion. As well,James referred to our relationship throughout the interview, using phrases like asyou know, joking about my questions and referring to shared experiences.James has taught computing at the same school for 18 years. During that time, hehas taught decision systems and introductory computing courses to students notspecializing in computing. The languages he has taught include BASIC, FORTRAN,APL, C and C++. The first four of these languages are procedural. APL shares someof the features of a functional language. C++ is a hybrid procedural/object-orientedlanguage. Currently James is teaching decision systems and an advanced course incomputer graphics. In both courses C and C++ are being used. Before being hiredfor his current job, James had no teaching experience. Neither did he receive anyteacher training.James' first exposure to computing was in the 1950s when he was working onapplications involving the calculation of trajectories for guided missiles. He did notlearn to program until 1963, however, when he taught himself FORTRAN in orderto solve structural analysis problems. James' industry experience has been in theareas of aeronautics and operations research. He has a PhD in operations research.What Teachers Know About Programming^ 41James made use of many visual metaphors during our interview. He used phrasessuch as I could imagine and the way I see it frequently. He said that we've putblinkers on the students by teaching them a certain style of programming. Jamesalso employed many physical images in his speech. He said that he was bowled overby the use of computers, that he fell into teaching and several times expressed theopinion that programmers wrestle with their problems. James told several storiesabout his experiences in industry and in the classroom and often used very detailedexamples to illustrate his points. He was able to remember specific details about datastructures used in a program he wrote many years ago.James' Knowledge about ProgrammingProgramming to James is a means to an end. To him, programming is a tool whichallows him to tap into the power of a computer. This power allows him to savetime and effort when producing fascinating images. James is intrigued by the powerand results produced by computers. He said, All of that work involved in numbercrunching, I could actually get it done by ... writing a few lines of code .... Thatfascinated me. James finds computing fun and interesting and says that it isintriguing to program away and then suddenly see some interesting results on thescreen. He enjoys the feeling of power over that machine.James organizes languages by application and power. That is, he separates thelanguages he knows, which are all used for scientific applications, from languagesused for business, like PL/I, or for list processing and logic, like LISP and PROLOG.C and C++ for him are a subset of the scientific languages. He sees them as modern,more powerful versions of the other scientific languages and he likes them morethan he likes the others.What Teachers Know About Programming^ 42James is attracted to languages that are efficient, powerful, easy to use and readable.When he learned C, he realized that it was [his] language -- that was the languagethat [he] liked. Now he says he is realizing that C++ is the way to go. James isattracted to C++ because it fits the way he thinks. He says that it models the realworld for him. It seems to be like the real world, where there are objects and theseobjects do react with an environment. In general James feels that we tend to choosethe language that matches the way we think.James sees programming and analysis as very different things. Both are concernedwith solving a problem, but whereas programming is detail-oriented and just a wayof producing a picture, analysis is a more conceptual activity which involvesthinking and modeling and theory. To James, the programming ... is not soimportant as the models.James' strong distinction between programming and analysis is echoed in his viewthat there are two different kinds of programmers. Business programmers areconcerned solely with programming. They are working continually with programsand doing maintenance. Modeling for them is trivial. Scientific programmers, onthe other hand, are using scientific applications to do analysis. For them,programming is secondary to modeling. They're not continually at the screen.They're spending a lot of time looking at the data, looking at the models and then,of course, programming.James' Knowledge about Teaching ProgrammingJames fell into teaching. He at first refused the offer of a teaching job, because hedidn't like the idea and ... hadn't even thought about doing it. It was difficult forhim to adjust to teaching, because he found that although he thought [he] knew the[course material] ... [he] realized [he] didn't. Unfortunately [he] sort of experimentedWhat Teachers Know About Programming^ 43... with [his] approaches and sort of learned by [his] mistakes which he doesn't feelwas fair to his students. He likes teaching, although he feels that he is not good atteaching the basics perhaps because he is impatient. He prefers teaching studentswho are specializing in computing to teaching those who are not because they knowa lot of the stuff and are easier to teach than people who just don't know anything atall. James likes the flexibility of teaching at his school and finds it amazing that ...we're the ones that are doing the learning. He likes the fact that he is learning allthe time and says, If I weren't learning I would leave. James dislikes the pressure hefeels in his job, but finds that he learns with that pressure. As he puts it, I hate thepressure, but I like the learning that comes along with it. To James a good class isone during which the students are interested and ask good questions. However, hedoes not like being unable to answer students' questions. He feels that being ateacher ... [he] should know the answers.James feels that programming should be learned as a means to an end. He doesn'tactually teach the details of programming, but his students learn and useprogramming techniques in order to solve application problems. When askedabout the value of teaching programming in elementary schools, James responded,It's a great idea. He thinks that programming can make learning fun andinteresting. He says that he found his own school days totally boring, but thinks thatstudents using computers could teach themselves a lot of the stuff ... and enjoydoing it rather than being bored and watching. James feels that understandingcomes from doing, in both programming, where one understands functions better ifone designs them oneself, and mathematics, where one understands calculationsbetter if one does them oneself.James' preferred mode of teaching is a combination of lecture and lab, in which heintroduces a concept and then has students implement it. Depending on whatWhat Teachers Know About Programming^ 44happens [in the lab] he and the students would then try something new. James usesa spiral approach to teaching programming. That is, he works through the concepts,moving from data types to structures, showing example programs to the studentsand of course getting them to write their own programs. As James says, I tend toteach applications and these applications require programming and obviously a partof my work involves helping students with debugging and such and occasionallytalking about approaches and algorithms, but I don't actually teach the details ofprogramming.In order to help students achieve deeper understanding, James attempts to showthem various views of a problem. His image of a perfect teaching environment isone in which many different views are available to the students. His utopianclassroom would include networked UNIX workstations so that students could seethe problems in many different ways easily and so that he could send out pop-upwindows to the students. His classroom would also have a projector to allowstudents to see what is on his screen, video projectors, an overhead projector and awhiteboard.James looks at specific programs first from a general perspective and then in termsof specific details. When asked to explain a piece of code or to describe a program, hefirst gave an overview of functionality and then moved on to explain specificdetails, mentioning particularly challenging aspects of the code. When asked todescribe how he would help a student understand a piece of C code which loopsthrough two floating point arrays assigning one to the other, he first made certainthat the 'student' understood the basic concept of an array. He then drew a picture ofthe array and gave an explanation in broad terms without going into details. Thisbroad explanation afforded some insight into the mental models James employswhen explaining program code. The array, to him, is a column of numbers. EachWhat Teachers Know About Programming^ 45element in the array is a box. James assigned a value to each element of the arrayjust to make it more .... The values were written with one decimal point ofsignificance. James' tendency to look at programs from two points of view, thegeneral and the specific, is also apparent in his description of the traits of a goodprogrammer.Debbe: What are the attributes of a good programmer? ...James:^Well, they have to be able to think really well to be agood programmer. There are some people who ...program really well, but they don't ... really know whatthey're doing because they ... can produce beautiful code,but ... they need, I would imagine, a lot of guidance. ...they'll ... start programming and then they'll continuallywant to know what to do, while I would say a goodprogrammer -- my version of a good programmer --would be somebody who can think and at the same timeprogram well. But they're able to think and see the bigpicture.Programming, he said, requires a strange mix ... of someone who thinks broadly andat the same time can implement those broad thoughts through the details of aprogram.James sees a major distinction between procedural languages and object-orientedlanguages. Students at his school, he says, just can't handle Smalltalk.Debbe: Why do you think that is, that our students can't handleSmalltalk?James:^Well, I think it's because they're so stuck with this older,not this older, but this other way of doing things that'sseparation between function: program and data. Andthat the idea of working with objects is strange to them.Debbe: So it's a matter of their previous experience?James: I think so. Yes, I think we've drilled them so heavilyinto this idea of data and programs, functions requiringdata, returning something, that we've put blinkers onthem.What Teachers Know About Programming^ 46An Integration of James' KnowledgeSeveral patterns link James constructions about programming to his constructionsabout teaching programming.Most striking is the strong sense of the computer as an aid to visualization andmodeling. James' interest in visual imagery and models is apparent in his speechand in his choice of graphics and decision systems as subject areas. His attraction tocomputing stems from his ability to use the power of computers to create fascinatingvisual models. In our discussion, when he described the results of hisprogramming efforts, he talked about colouring pixels on the screen, producingimages, and seeing what came out. He feels that students need to see variousmodels in order to learn. That is, various forms of media need to be used asteaching aids and students need to be shown conceptual models in order tounderstand specific programs. James' feels that good programmers must be able tomodel the world. His explanation of why students have trouble with object-oriented programming epitomizes James' concept of teaching as presenting variousviews: teachers put blinkers on students by teaching them only one paradigm.Also important to James is a sense of learning by doing. He taught himselfprogramming and, by trial and error, learned how to teach. His sense that oneunderstands best by doing is manifest in his view that programming is best learnedby practice and his view that learning can be made meaningful by having studentslearn how to program solutions. James loves learning new things, so he lovesteaching in a new area in which he and his students can together make newdiscoveries. Good programmers, James feels, do not need too much direction. Theyshould be able to think well on their own.What Teachers Know About Programming^ 47James' view that computing involves the ability to see the big picture as well as theability to deal with specific details is apparent in the strong differentiation he makesbetween programming and analysis. In addition, it allows him to distinguishbusiness programmers from scientific programmers. The former are preoccupiedwith programming, while the latter spend their time on analysis. This firmdistinction between analysis and programming shows up in James' explanations ofcode segments, as he first gives a broad view and then goes into detail, and in hisconception of what makes a good programmer, which includes the strange mix ofhigh-level analysis and low-level detail work.James' conception of the traits required to be a good programmer touches on all ofthe themes mentioned here: a good programmer can see the big picture as well asthe detail, does not just write code, but applies knowledge to an application area, canmodel the world and works well independently.For James, programming is a means to an end. He learned programming in order touse the computer's power to perform scientific applications. He selects languagesbased on their power and ability to model the real world. Programming is just a wayto produce a picture. His role as an instructor is that of someone who introducesconcepts which the students then implement. The fact that the students areprogramming in order to achieve their goals is secondary to the end product, whichis usually a picture. His sense that programming could be used to make learningfun and meaningful further supports his conception that programming is simply atool with which to produce really fascinating images.What Teachers Know About Programming^ 48Melissaa sense of masteryI have known Melissa for ten years. She was my teacher for part of one term and Ihave worked with her for the past six years. We have a personal friendship inaddition to our collegial relationship. Melissa's two interviews took place one weekapart and were conducted in our school office after her classes were finished for theday. The interview discussions felt very personal. Melissa referred often tosituations we had discussed outside of the interview setting. Several times duringthe interview she asked my opinion about a question I had asked her.Melissa has taught computing at the same school for 11 years. During that time, shehas taught BASIC, Pascal, FOCUS, RPG, Fourth Generation Languages (4GLs) andintroductory computing courses to students not specializing in computing. Thisyear she is teaching COBOL, PL/I and assembly language. All of the languages thatshe knows are procedural. Before being hired for her current job, Melissa taught anight school introductory computing course. She has also taught motorcycle ridingand is currently a flying instructor.Melissa's first exposure to computing was twenty years ago at the age of sixteen. Herbrother was taking a BASIC programming course at university. She becameinterested in programming and went through the course on her own. Melissa tooktwo years of math and science at university feeling frustrated because she was notable to specialize in computing. She therefore enrolled in the school at which shenow teaches, where she was able to specialize.Melissa worked in programming and support in minicomputer environments forfour years before returning to her alma mater as a teacher.What Teachers Know About Programming^ 49Melissa's speech is striking in its use of physical metaphor. Her interviews werepeppered with phrases such as take a step backward, grab onto it, tie your handsbehind your back and I've got to dig down. As well, Melissa used many handmotions to illustrate her physical descriptions. The stories she told were aboutparticular students and classes she has taught or is teaching.Melissa's Knowledge about ProgrammingLike flying and motorcycle riding, programming gives Melissa a sense of masteryand control of machinery. I asked her to analyse the way she thinks aboutprogramming:Debbe: What do you think affects and build the way you thinkabout programming?Melissa: I like to be in control and master things. ... It's the samewith flying, though. I want to take this piece ofequipment and put it through its paces and do theperfect landing and the perfect turns and make it dowhat I want it to do. I'd say that would be the mostimportant concept is a sense of mastery.To her, programming is a big puzzle that you [get] to tear apart and put back togetheragain. Programming caught [her] imagination at an early age because it was notmainstream ... and [she] always liked things that you could tinker with and mindgames and mathematics and puzzles and things. She still likes the sense of being incontrol, of mastering a problem with a certain degree of finesse which was the initialthing that attracted her to programming. For Melissa, what is important is not justsolving the problem, it's how you get there.To Melissa, programming means breaking a large problem down into manageablepieces that can be solved. Programming is a very tangible activity for her. Melissalearned assembly language in her first term at school. She said, I found it horriblyWhat Teachers Know About Programming^ 50complicated and ... struggled and didn't do nearly as well as I thought I should bedoing in first term, but once that fell into place I never really found that I had thatmany problems learning another language. Melissa feels that because she learnedassembly language in her first formal course, she constantly picture[s] what's goingon in the background in any language she now uses. She actually sort of picture[s]things physically happening as a result of [a program instruction]. She sees ahoneycomb of storage boxes and what is contained in them ... and ... thinkfs] threedimensionally in [her] head. Her vision is very detailed. She sees data going intothe Arithmetic Logic Unit, the calculation being done and a result being placedsomewhere. Melissa pictures languages in different ways. With PL/I, she thinks inblocks, whereas in assembly language she thinks more in a straight line where yougo out and back and out and back. During the interview, Melissa used distinct handmotions while describing things such as getting a PL/I building block to plug intoher program.Melissa has experience programming only in the procedural paradigm. She thinksthat one procedural language for the most part is like another. They differ only onhow much detail you have to think about. Her sense is that one might thinkdifferently in another paradigm, but because of her lack of non-proceduralexperience she can't offer a knowledgeable opinion.Within the procedural paradigm, Melissa classifies languages in terms of how muchshe enjoys coding in them, which is determined by how awkward she perceiveseach language to be. Melissa most likes assembly languages because they give her ahigh degree of control over low-level machine functions. Her least favouritelanguage is RPG, which is to be avoided at all costs because it is impossible to debug.She said, You're better to pitch it out, throw it out, rip it up and rewrite it than youwere to try and debug it. COBOL and BASIC are unwieldy and awkward to debugWhat Teachers Know About Programming^ 51and code. In particular, she disliked BASIC intensely because it wasn't elegant. Iasked what she meant by elegant.You couldn't do tricky things with it .... For example, you couldn'tgo in and manipulate bits and and move bits around and ... it justseemed to tie your hands behind your back so much. Difficult togo through and do some trickier things which is what I used tolike to do.COBOL does not allowin-line logic and it forces you down to deeper levels, deeper anddeeper and deeper and it gets quite muddled when you're trying tounderstand what's going on. The language structure itself withsentences and paragraphs and there's a period at the end of thewhole thing. I find the structure itself becomes very cumbersome.PL /I and 4GLs she finds easier to work with. PL/I, in particular, has nice built instructures and functionality.When asked what image comes to mind when she hears the word 'programmer',Melissa said that she's torn between the typical nerdy student with a calculatorhanging off his belt and tape on the glasses and (pause) us! Her view of typicalprogrammers is dictated very much by the students that she sees. Overall, though,she sees them as hard-working, detailed, able to handle the job stress ..., able toconcentrate for long periods of time, ... able to ... see the overall picture and thenswitch it into being able to handle the detail.Melissa's Knowledge about Teaching ProgrammingMelissa teaches programming and flying and has in the past taught motorcycleriding. As she puts it, I teach everything I learn how to do. Melissa likes teachingbecause she likes being in control. She likes talking and having 150 people listening.She likes the feeling she gets when, after a class in which the students did notWhat Teachers Know About Programming^ 52understand what she was teaching, she goes home, thinks about it and comes backwith a different angle and sees the lights go on.Melissa feels that it is a good idea to teach programming in elementary schools inorder to demystify computing; to give students the understanding that the computeris not HAL from 2001 running amok and doing things all on its own. It still issomebody's thought processes behind it all. Whereas learning application packageswould be easy for students and would give them a degree of control and a sense ofsatisfaction, in order to demystify the process you have to actually get in and write alittle program to ... understand what the machine is doing.During our discussion, Melissa spoke extensively about students' reactions tovarious languages and her perceptions of changing reactions over the years. Severaltimes she volunteered information about student attitudes and expressed theopinion that students need to experience success and gain a sense of confidence inorder to learn programming.Melissa feels that there may be a correlation between students' feelings about aninstructor and their feelings about the language being taught. She tries hard to hideher biases against certain languages, but is eager to share her enthusiasm aboutothers. Melissa's concern for the students is made clear by her feelings that althoughshe wouldn't choose COBOL to do anything and despite the fact that teachingCOBOL wouldn't be [her] first choice, given the skills of the faculty at her school,she is probably the best person to teach COBOL.I probably do a better job of it and know it better than anyone else.So if they're going to be taught COBOL, I'd just as soon at least theybe taught it by someone who knows it and I probably dislike it lessthan anyone else here.She senses that the students have reacted positively to her enthusiasm about PL/I.What Teachers Know About Programming^ 53Melissa feels strongly that students will solve problems in the style of the languagewith which they are familiar. In particular, she sees her second year studentswriting PL/I programs the same way they would a COBOL program cuz COBOL hassome restrictions. Having students submit preliminary design work allows her tocorrect their logic -- streamline it -- so that they write their first PL/I program in avery nice PL/Iish way. They lose the old COBOL restrictions. Melissa maintainedthat programmers think of a shell of a program in their minds. Depending onwhich languages one learns first, one will have access to different shells. Havingwritten programs in several languages, she has a catalogue of shells in her mind andcan pick out, for example, a PL/I shell if she needs one. If she is forced to code in alanguage for which she does not have a shell, she will look at sample programs toget a sense of the language. Students, she claimed, go back to the most recentprogramming language they have learned.Melissa looks at programs in a very systematic sequential way. She explainedprogram code to me line by line and, when asked to describe how she would help astudent having difficulties, approached the problem in a very linear fashion:So I would go through it with them and make sure there were nocompile errors and then I'd say, well, it's interesting, notice herethe //EXEC. It started to execute, but nothing came out. So let'strace it back. Where would it first print something out? And thenI'd start going through line by line. If we still couldn't figure it outI'd say, well, it's really important that we figure out how far it got,so let's run it again with some display statements, displaycheckpoint one, checkpoint two, checkpoint three and run it againand see how far it got and that way we'll start to narrow down therange of where it didn't work.Melissa paid a lot of attention to the details of the programs. She looked first at thedata definitions and made a note on paper of the field names. She immediatelyfound a spelling mistake in some sample code.What Teachers Know About Programming^ 54The structure of Melissa's courses parallels the way she looks at programs. Shespends about one third of the term teaching data definitions in detail. She then goesthrough the logic processing constructs and spends the last part of the course dealingwith issues arising from student concerns.Melissa makes extensive use of mental models so that the students start tounderstand when things go wrong. She wants them to understand why they get adata exception. Melissa draws pictures trying to get them to visualize ... and [to be]able to see this as something they can actually see (she picks up a piece of paper) ...rather than something inside the black box that happens. She draws boxes torepresent storage locations and shows their contents in hexadecimal and binarynotation.Melissa feels that the students' first language should be assembly language. In thepast, when students learned assembly language in their first term, she found thatthey absorbed it and .... were able to use it in subsequent languages. She doesn'tthink that students who learn Pascal or C as a first language are able to picture whatis going on in the background when they are programming. Several times since wecompleted our interview sessions Melissa has reiterated her view that we should goback to teaching assembly language in term one. She called me at home to read anote from a student explaining that he finally (after three terms of programming inother languages) came to understand programming when he studied assemblylanguage. She said that this is more evidence that assembly language should belearned in term one.Melissa feels strongly that certain people do not have an aptitude for programming,just as she does not have the aptitude to draw or play a musical instrument. GoodWhat Teachers Know About Programming^ 55programmers, she feels, must have the desire to learn programming and must beable to think logically. Melissa described a friend of hers with whomyou cannot have a logical conversation .... Her mind just ... skipsaround things (she demonstrates with hand motions) and sheseems to be pulling bits and pieces out of the air. ... And it's hard toget a straight progression of thought, cause and effect, theconnections between things, but she paints beautifully and ... shecan take a canvas and put a little blob here and a little blob thereand after a while it starts to turn into something. And I'm notsure that she knows all along that that's what she's going to endup on, but she eventually turns it into that. She is a friend who Idon't think I could ever teach her how to program. I honestlydon't. ... because I don't think she'd want to and ... she couldn'tsort of force her mind into a thought process that considered causeand effect a little more. She's a hairdresser. So she cuts a bit hereand cuts a bit there, and looks at it and says, oh, maybe, OK, I'll cuta little more here and I'll change it here, rather than sort ofplotting the whole thing out.In addition to being motivated and having a strong sense of cause and effect, then,Melissa feels that programmers need to be able to plan. During the interview, shetold a story about a student who would plan her programs for only the idealscenario rather than writing a program that could handle various cases. Now thestudent is plugging all the holes in the dam. Planning, to Melissa, involves beingable to anticipate many outcomes. Melissa feels that good programmers need to bepersistent. They need to be able to handle frustration calmly without becomingirritable. As well they need to be free of a sense of intimidation.An Integration of Melissa's KnowledgeProgramming gives Melissa the sense of control and power over a machine that shelikes. To her, programming is a puzzle to be mastered and she is therefore attractedto languages that give her the power and control to solve problems with finesse.Assembly language lets her do tricky things at a low level. PL/I gives her power andflexibility. Cumbersome languages like BASIC and COBOL tie [her] hands behindWhat Teachers Know About Programming^ 56[her] back, [force her] down to deeper levels. In other words, the language, notMelissa, is in control. Melissa likes the sense of control she gets from teaching aswell. She likes lecturing and feels that a teacher's biases can strongly affect students'attitudes. Melissa checks students design work so that she can control the shape oftheir programming logic. Melissa feels that students need a sense of control in orderto be good programmers, so she attempts to give them power by buildingconfidence. She maintains that computing could be demystified by giving studentsa degree of control, by showing them that computers are not in control, but humansare. Overcoming intimidation about machinery allows a feeling of control.Melissa gains her sense of control over the machine by understanding all the detailsof what she is doing. Although she recognizes that programmers need to see boththe big picture and the details, for her the important aspect is the ability to breaklarge problems down into smaller parts. She categorizes the languages she knows interms of the level of detail accessible and pays strict attention to the details of aprogram she is examining. Because she is so concerned with detail, she advocatesthe teaching of assembly language as the first language so that students canunderstand what is going on in the machine.Melissa's understanding of what is going on in the machine, and the understandingshe attempts to share with students, is a very tangible one. She sees the storage andthe operations as she goes through a program. The mental models she employswhen teaching reflect her very physical sense of what is happening when a programis executing.For Melissa, programs operate in a linear fashion and programming is done in avery systematic way. Melissa feels that to be a good programmer one must thinklogically, have a strong grasp of cause and effect and be able to plan for anyWhat Teachers Know About Programming^ 57eventuality. She reads and explains programs line by line and when helpingstudents with problems, traces through their programs step by step. Her coursestructure echoes this linear approach to program design and execution.Results of the Pilot StudyThe pilot study gave me additional experience in interview techniques andaccentuated the need to allow the respondents adequate time to reflect upon andrespond to both individual questions and the interview as a whole. After the firstpilot interview, the protocol was separated into two sections. The secondrespondent was interviewed twice over the period of one week. Based on the pilotstudy, the interview protocol was shortened and modified. As well, I decided to askrespondents for course materials before the interviews so that questions aboutcourse structure and content could be more concrete. During the main study,respondents' language knowledge was recorded on index cards to facilitate languageclassification. Analysis of the pilot transcripts allowed me to experiment withvarious techniques and to develop a procedure with which I felt comfortable.Because the interview protocol was not altered drastically after the pilot study, andbecause the pilot study elicited information about the same themes as the mainstudy, the results of the pilot study were analysed together with the results of themain study.Based on the pilot study, the interview protocol was modified. Table 2 contains anannotated version of the protocol used in the main study. As mentionedpreviously, the protocol was used as a guide. The actual interview questions varieddepending on the respondents' replies. See Appendix B for a sample transcript.What Teachers Know About Programming^ 58Table 2Interview ProtocolIntroduction:PurposeAnonymity/Right to refuseSense of the interview "Rapport"Background:1. How did you come to be teaching at yourcurrent school?2. How long have you taught here?3. What courses are you teaching now?4. Tell me about past teaching experience.where/what/to whom/languagesProfessional Background:1. Describe how you first learned to program.why/where/what environment?2. Describe your professional/researchexperience.3. What programming languages do youknow/have you learned? (Put them oncards)In keeping with the overtnature of the study,respondents wereinformed of the purposeand atmosphere of theinterview.This section was used toelicit information aboutthe teaching experiencesthat have helped shapethe respondents' views.This section was used toelicit information aboutthe programmingexperiences that havehelped shape therespondents' views.What Teachers Know About Programming^ 59Thoughts about Programming:1.When did you last write a program?Describe it to me.2. What do you like about programming?3. What do you dislike?Thoughts about Language:1. You know the following languages:How would you categorize them?(Use cards to do this). Explain.2. What is your favourite language? Why?Can you generalize - what attributes attractyou to a language?3. How do you choose the language you use tocode specific programs?eg. a program to sort some dataa program to diagnose a problem in acircuit boardan Accounts Receivable module4. Some people claim that the language wecode in shapes the way we think. Othersfeel that we select languages based on theway we think.Please comment.5. Does it feel different to code in X than tocode in Y?With this group ofquestions I hoped to learnabout the ways in whichthe respondents thinkabout programs andabout their ideas of whatprogramming entails bylistening to the ways inwhich they describedprograms andprogramming.Here I hoped to discoversome sense of the ways inwhich the respondentsorganize their knowledgeof language. I hoped toelicit information abouthow the respondentsdifferentiate betweenlanguages and whataspects of languages areimportant to them.What Teachers Know About Programming^ 60Thoughts about Programmers:1. What image comes to mind when I say theword "Programmer"?2. What is that person doing ?physicallymentally3. So programming means ...4. Would you call yourself a programmer?5. What are the attributes of a goodprogrammer?This section was designedto find out more aboutthe respondents' views ofprogramming. By askingabout programmers, Ihoped to discover notonly the attributes thatthe respondents findimportant inprogrammers, but alsothe aspects ofprogramming that areimportant to them.Thoughts about Teaching:1. Tell me about a good teaching day2. Tell me about a bad one3. What do you like about teaching?4. What do you dislike?These general questionsabout teaching wereasked to discover therespondents' feelingsabout teaching in general.Questions three and fourwere asked only if thefirst two questions didnot elicit generalconcepts.What Teachers Know About Programming^ 61This section deals withspecific aspects of therespondents' teachingpractices. They wereasked about the purposefor which they teach, andabout why they havechosen a particular courseformat in order to get asense of theconsiderations whichshape the ways in whichthey teach. The outlineand assignment wereused to elicit informationbased on concreteexamples. The questionsabout favourite languageswere used to discover ifthere is a differencebetween favouriteprogramming languageand favourite teachinglanguage.Thoughts about Teaching Programming:1. Programming is now taught in elementaryschool. Do you think that this is a goodidea? why (not)?2. What is the purpose of teachingprogramming at such a young age?3. Do you see the same purpose to yourteaching?4. Question about course outline.5. If you had infinite resources, would thingsbe different?6. Question about assignment.7. Are you consciously trying to impart aparticular image to the students?8. Explain this code to me as if I were a studentcoming to you for help.9. What's your favourite language to teach?Why?10.What's your least favourite language to teach?Why?11.(Why) Are there differences?12.There is a lot of controversy about the bestfirst language for students. Comments?What Teachers Know About Programming^ 62Thoughts about Students:1. Can anyone learn to program? Why (not)?2. Think of 3 people you know (notprogrammers / students).Would they be good programmers?Why (not)?3. Some people claim that they can tell almostinstantly whether or not a student is goingto "make it". Can you do this? How? Areyou usually right?Conclusion:1. Anything that has puzzled/interested youthat you want to pursue?2. ThanksIn this section 1 hoped touncover informationabout the respondents'views of how to predictprogramming success. Aswell, the informationgained here could becompared to theinformation elicited fromthe section asking aboutprogrammer's attributes.By asking about peopleother than programmersor students, I hoped todiscover whether therespondents felt that theycould predict successbased on something otherthan students' behaviourin programming classes.What Teachers Know About Programming^ 63CHAPTER FOURRESPONDENTS' KNOWLEDGE ABOUT PROGRAMMINGThe six respondents in the main study each have personal interpretations ofprogramming and teaching programming. In this chapter, the results of mydiscussions with each respondent are presented. Each teacher's educational andemployment background is outlined, my relationship to the respondent is describedand a sense of the tone of the interview and the respondent's manner of speaking isgiven. I then present summaries of the respondent's articulated knowledge aboutprogramming and about teaching programming. The section for each respondentconcludes with an analysis of the ways in which knowledge about programmingintegrate with knowledge about teaching programming.What Teachers Know about Programming^ 64Rossdancing carrots on the screenRoss has taught programming at the same school for 17 years. At the beginning ofhis teaching career he taught procedural languages (assembly language, COBOL,Pascal) and he still teaches courses in procedural languages from time to time. Forthe past eight years, however, he has been the head of the expert systems area at hisschool and in recent years has taught almost exclusively in the area of artificialintelligence using LISP (a functional language) and, to a lesser degree, PROLOG (adeclarative language). Before beginning his teaching career, Ross worked in amainframe environment, doing systems programming in assembly language andworking with COBOL. He was a programmer, supervisor and manager in themainframe environment for approximately ten years.During our interview sessions, Ross and I focused primarily on the differencesbetween programming paradigms. The sessions felt very personal. In the past fewyears, Ross and I have often discussed programming paradigms and in the course ofthe interviews Ross frequently alluded to our previous conversations. This senseof shared understanding led him to sometimes reject superficial, standard responsesin a search for deeper understandings. We joked and laughed a lot during thediscussions and despite the fact that Ross felt that he had been doing all the talking,to me our conversation felt similar to our usual discussions. Ross appeared to wantto be able to help analyse the responses he gave me. Several times he answered myquestions by saying that he did not have a list to offer. He seemed to be saying thatalthough he could help with specific examples, he had not done a thorough analysisand so could not offer a complete response.What Teachers Know about Programming^ 65During the interviews Ross used very sensory language. He spoke as though hephysically inhabits the world of a programming paradigm. He said, for example,The world that I spend most of my time in these days is a sort of LISP-world. Rossused many physical metaphors. He talked about stumbling on ideas, plucking themout of the air, wallowing in a problem and, as a programmer, getting inside the box.In addition to sensory physical language, Ross used three metaphors extensively: hetalked about labels (labels of categories aren't coming to my head, for labellingpurposes let's talk about ...), patterns (the pattern matcher in me, techniques,patterns, algorithms that he's got) and lists (I don't know if I've got a list ready, makea great big list of all the utilities).Ross's Knowledge about ProgrammingRoss has a strong sense of the various paradigms extant in the programming world.He spoke about a cluster of paradigms and pseudo-paradigms with overlapping andnon-overlapping attributes and illustrated his framework by drawing a Venndiagram in the air. His language and comments suggested that he feels as thoughone actually inhabits the world of a programming paradigm. We spent the majorityof our time discussing the distinctions he sees between two worlds in particular: theworld of block structured languages and LISP-world. He seems to differentiatebetween them in terms of the amount of freedom and control they offer theprogrammer; in terms of the amount of discipline they impose.Ross used to live in the block structured world. He worked as a programmer forseveral years and then became a supervisor in that same world and then a managerin that same world and so on and so ... your fingers stop doing the programming,but you're still, you know, the world is still the same world. ... and then teachinghere, there was only the one world. Ross spoke at length about COBOL, andWhat Teachers Know about Programming^ 66explained that COBOL was his shorthand for block structured language ... old-fashioned block structured language at its worst ... generic. Block structured world,to Ross, is a world of flowcharts, design tools and desk checking, a world where theprogrammer does extensive thinking and designing before beginning to code. It is aworld of tight specifications, formal authoritarian languages and cut and driedproblems. As he put it, COBOL is always just COBOL. Any particular session withCOBOL feels like any other session with COBOL. No real surprises. A certainamount of plodding and you get where you're going. No big breakthroughs.Nothing wonderful ever happens, nothing horrible ever happens in COBOL.Ross, in a slightly mocking tone, said that I might find interesting his path toenlightenment from the block structured world. His first exposure to LISP was in acourse where the professor taught concepts of artificial intelligence, but did nolanguage teaching. Ross's early LISP looked like COBOL or something, felt likeCOBOL. No, it felt worse than COBOL. It felt very frustrating. Ross remembersusing design methodologies that had spilled over from the other paradigm,remembers physically needing to look at a hard copy of his design work. Throughreading and talking to others and just kind of stumbling on it though, gradually itdawned on Ross that LISP was an interactive language with a capital I oninteractive.Now, he said, he never [goes] anywhere near paper. He rarely goes near a manualand finds forgotten syntax by trial and error. He said,To caricature it a bit, you get the barest inkling of an idea and youtry it out right there and then on the machine .... It's, have athought, try it out, have a thought try it out .... The general notion... is sort of the machine as the scratch pad, the machine as yourcocktail napkin.What Teachers Know about Programming^ 67Ross said that aspects of LISP make programmers start thinking differently aboutwhat they are doing. This different way of thinking makes one feel much less aslave to the tool that one is using.LISP gives Ross a feeling of control at the level at which he is comfortable. That is,he is not interested in having control at the register or pointer level, as one has withassembly language, but wants to have control at the inference engine level. Hewants to know that he can get inside the box, that there is no mystery. Ross said thatSmalltalk and PROLOG have some of the same advantages as LISP. However, Rossdislikes both languages. Neither give him as much control as he has in LISP; hecan't get at their inner workings. In Smalltalk this means that he is forced to useobjects that behave in a generic way as opposed to the way he wants them to behave.In PROLOG he is unable to customize his own inference engine. He said that he isnot a PROLOG fan. PROLOG offers so much and goes through periods of deliveringbeautifully and then lets you down and lets you down big. In particular, he feelsthat when debugging or optimizing performance, one is often forced to understandwhat is going on procedurally in the background of a declarative language.Ross talked about having had the same sense or spirit with systems programming ashe has with LISP. He told a story about a problem he worked on as a systemsprogrammer where he stumbled on a phenomenon and started to experiment. Ashe said, I just kind of wallowed around in it and eventually through trial and errorand luck, ... , found something that was quite good. LISP, he said, is known as themachine language of AI and although assembly language and LISP are about as farapart as you can get ... somehow it's ... the same activity.Ross said that LISP is good for feeling your way into unknown territory, which iswhat one is doing with Al (artificial intelligence) flavoured tasks. Whereas otherWhat Teachers Know about Programming^ 68languages are what they are, Ross stressed the notion that LISP is a chameleon. Itcan be made to mimic other languages. Any features that Ross covets in anotherlanguage, he can steal and write in LISP because of its chameleon-like nature. Anytime you write a LISP program, one way to think of it is you're writing a languagethat perfectly matches the domain, the application you're working on. LISPmodules are tiny, so you can always think about any bite-sized chunk with a goodrich deep understanding .... And the granularity is just, just perfectly matches yourown need for granularity. Why? Cuz you set it up that way.Programming to Ross is a high. The high used to come from writing code, but as hemoved along the industry promotional career path he found that one could still doall the creative stuff and all you're giving up is the keying or the moving of thepencil. So all the design stuff and so on is still yours .... For him, the high movedfrom writing the code to thinking up the solutions. I asked him where the highcame from.Debbe: So that programming high comes from creativity?Ross:^I think so. It's hard to say what that means, but it'ssomething to do with discovering a pattern in the realworld or inventing one, it doesn't matter, and finding away to turn it into something in the machine. ... Well,here's one example. There was a student group lastterm. ... The application was going to be gardening based.We knew that for sure, but we didn't quite know who totarget it at so anyway [I said], "we could have a this or athis or we could have dancing carrots on the screen" andthe high came from the fact that ten weeks later we haddancing carrots on the screen. So part of the high wasthe actual pulling it off, but it was the notion that youcould make something up out of the air -- anything,anything (we laugh) -- and make it happen. You know,we talk about creating one's own reality and so on, butit's like you can!What Teachers Know about Programming^ 69Ross said that he wishes he had the talent to sculpt or draw, but thinks that perhapshe's found the medium that allows him to convert stuff from imagination to a kindof reality.Ross uses LISP for any programming he now does, even the most non-AI thing thatyou can think of. LISP is his language of choice. It seems natural to him. Herecognizes, though, that other languages seem to fit other people. For example,There are people in the world, he said, whom I respect, who love this thing,PROLOG. And build things out of the air with it with apparent ease. Of a formerfellow graduate student he said, PROLOG fit him and LISP fit me for reasons I don'tunderstand.Others seem to find a fit in the block structured language world that Ross used toinhabit.Ross:^... there are programmers around who make a really niceliving out of applying fairly standard formula kinds ofapproaches to stuff in the world ...Debbe: Could you ... say that someone who does that type ofprogramming ... is a good programmer?Ross:^Not in my world, but in worlds that I've inhabited, yes,for sure, absolutely.Ross mentioned that he sometimes makes a joke about playing off one way of lifeagainst the other.You can caricature either ... so [LISP-world programming] at itsworst is undisciplined hacking, juvenile behaviour ... and theother is mindless drudgery .... And if you want to hype them boththen the one is inspired creativity and the other is ... keeping theengines of society oiled and working as they should ... doing thedata processing tasks of society and I choose that phrasedeliberately. The people that do well in the one group I think area very different kind of critter from the people who do well in theother group.What Teachers Know about Programming^ 70Ross said that he sometimes categorizes languages as LISP and other. At the end ofthe second interview, as he looked at the half dozen index cards upon which I hadwritten the names of languages that he knows scattered on the table, he said,physically I want to push these things (other than LISP) away.Ross:^It's not so much that I'm wild about [LISP]. I'm wildabout something that doesn't exist yet. But I have atleast the illusion that I can build it out of this.Debbe: Mm-hmm. What is that thing that doesn't exist yet?Ross:^Well, it doesn't have a lot of parentheses in it for onething. (we laugh) And it's got ... a very smart interfacethat doesn't make me do the grunt work the way allthese things do. And it doesn't require compiling andwhat? It doesn't get in my way. It lets me worry aboutmy application. It lets me build dancing carrots out ofthe air one minute and something very very differentout of the air the next minute ...Ross's Knowledge about Teaching ProgrammingRoss's course outline states, "LISP is VERY different from the languages moststudents know, and the course uses it as a vehicle to introduce students to symbolicrather than numeric uses of computers." Ross said that he [drags the students]kicking and screaming away from their flowcharts and various design tools. Afterhaving learned LISP for one term, Ross's students, along with others who have notlearned LISP, study Smalltalk. I asked him about his and other students' reactions tothe course. [My students] have certainly seen how LISP can look like an object-oriented language ... and therefore when they get a Smalltalk course ... they make anice direct match of one to the other. His students tell him that they are learningSmalltalk more quickly and with much less anguish than the other students. It'scertainly how it should be because presumably the other [students] are beingWhat Teachers Know about Programming^ 71dropped rather cold into a shocking new paradigm and my guys have been dippingtheir toes into that paradigm for three months.Ross introduces his students to the new paradigm by presenting them withtempting little tasks ... where it would feel artificial to do a lot of design first. Beforeour second interview he showed me two LISP textbooks which epitomize his senseof two opposite ways of teaching programming. The one he likes introducesconcepts by giving a hint. The other teaches syntax in a step-by-step manner. Theprojects and lab assignment component of Ross's course makes up 55% of astudent's final grade and, as the outline states, there is "extensive hands-onpractice". Ross gives his students paradigm jarring assignments that will challengenot just how they code, but how they think about computers. He also offers someassignment questions that could be done in the style of either paradigm to seewhether they're changing methodology or not.Ross mentioned one of the standing jokes that he and his students share.One of them comes to me and says, "Hey, [Ross], in LISP can youdo ...", and I say, "Yes", you know, before I hear any more of thequestion and of course after a while that becomes a cliche and sothey start to ask it as "How can I do X?", but I think that's animportant switch in mindset. Because I think in COBOL, youcome along and say "[Ross], can I do X?", the answer might be no. But the thing about that question with LISP is when they comealong and say, "[Ross], can I do X?", any X, including X's that I'venever thought of before and they've never thought of before,they're dreaming it up out of the air, dancing carrots, the answer'sstill yes.Ross has fairly intimate interaction with his students. They are pretty close andspend a lot of time together. He talked about [taking] them to rather interestingplaces. Ross seems to act as a guide to his students and has the sense as they worktogether of swimming through this sea of alternatives influencing them by pullingWhat Teachers Know about Programming^ 72strings and pushing buttons. Ross cautioned that as an instructor he has agendasother than teaching programming for programming's sake. Part of what [his]students learn when they think they're learning programming is learning how to ...market themselves and their product. How to give little tempting nibbles and thenwithhold .... In a sense, he said, what he does is anything but teaching. He uses hisstudents' projects to still indulge in creativity for ... a design of [his] own althoughit's not [him] at the keyboard, which it used to be. A lot of [his] programming now isdone with their fingers. He questioned why he is teaching LISP when almost noneof them will use LISP on the job.Debbe: So by what stretch of the imagination is it worth it?Ross:^... I can use LISP to encourage them to think aboutprogramming in a fairly drastically different way fromwhat they're being told in other contexts and I am sureas I can be that the ones who catch on to it are a muchdifferent category of programmers. I think it will standthem in good stead as languages evolve more and moretowards a LISP-like model as languages are doing.Ross says that part of the high he gets comes from watching students catch on to theLISP-world phenomenon. Not all of the students do catch on. Ross described twostudents in particular, one of whom got high marks in his course, but was totallywithout creativity. She would apply the material mechanically, rather than using itas something to fly with. She would always stop at one level. The other student isprobably the best programmer Ross has seen. He learned all the syntax and thenbuilt something of his own and then with that built something of his own and withthat built something of his own. Ross said that the latter student is excellent in thecontext of the kind of programming that involves rapid prototyping of things thatare new. However, a colleague who taught the same student PL/I, described him asa nice kid, but ... not much of a programmer.What Teachers Know about Programming^ 73Ross feels that students who get the AI bugcome to [him] out of the box with a certain mindset, a certain wayof looking at the world, such that they don't need a lot ofprocessing on [his] part. They're ready to hear any messages that[he's] got ready to give.According to Ross, getting the AI bug is a process. When he mentioned a currentstudent whose head is getting the right orientation, I asked him what he wasmeasuring to see if the students were making the transition. He said that he looksfor fluency in lingo and concepts and at their choices of coding applications. As wellhe listens to the questions they ask and looks at the books they are reading in orderto get sort of a sense of general orientation.If he were to select students for his course, he would interview them looking forthose who can make leaps ... to various meta-levels. He would look for signs of life,signs that there's a mind in there. The kind of person he is looking for lives in aworld where one reads and one is attuned to intellectual issues in some sort ofabstract pattern matching kind of way and is already excited about [artificialintelligence].Ross mentioned several times that he is unsure whether the talent required forprogramming is hardwired or programmed. Whether it's some kind of innatecapacity they've got or whether they have just been preprogrammed by somebody orsomething else, who knows? Neither does he understand why some catch on andsome don't when all are getting, [he thinks], similar feedback from [him].What Teachers Know about Programming^ 74An Integration of Ross's KnowledgeIt's a big world. There's room for everybody. To Ross, the world of programming ismade up of smaller paradigm worlds which sometimes overlap and sometimes arestrikingly different. He feels that there is a major difference between LISP-world andother worlds in terms of working and learning, and in terms of creativity andcontrol. LISP-world, to him, is a place where he can experiment, where he can havean idea and try it out without a lot of pre-planning. It is a place where he can use hiscontrol over the inner workings of a language to create things out of the air. Incontrast, the world of block structured programming is a place where creativity isconstrained by specifications and language structure, where one plans extensivelybefore implementing ideas.Ross feels that different people work well in each paradigm. His sense is that certainlanguages fit certain people. Students, he said, come to him with certain mindsets,innate or learned, that predispose them to different paradigms. If he could, Rosswould use his feel for LISP-world people to screen incoming students, looking forthose that can make leaps ... to various meta-levels, that look at the world in anabstract pattern matching way. Ross sees students of both types in his classes andnotices that those that he thinks are good are not necessarily thought of in the sameway by his colleagues who teach other programming styles.Ross's sense is that the switch from one world to another is a difficult one. He had ahard time making the transition and he sees the same difficulty when students areforced to learn new paradigms. He sees that students struggle when they aredropped into a shocking new paradigm. He attempts to help them by presentingthem with tempting little tasks and by giving them paradigm-jarring assignments toWhat Teachers Know about Programming^ 75change not only the way they code, but the way they think about computing. Rossgives students the opportunity to learn in the way that he likes to learn, by doing.Ross likes to manipulate the computer at a low level, but not in a detailedconstrained way. In the same sense, he manipulates his students' world, not byprescribing rules, but by offering more subtle enticements; by pulling strings andpushing buttons, knowing that some will get the bug. He attempts to immersethem in a world where one experiments, where no step by step rules are specified,but where a guide is available to keep an eye on one's orientation and to give hintsabout new ways in which one can learn to fly into unknown territory.The creativity that Ross once expressed by writing code and then by designing it, henow finds by working with his students. Although it's not [him] at the keyboardanymore, he can still create dancing carrots on the screen.What Teachers Know about Programming^ 76Lornea chance to playLorne's educational and employment background is extremely diverse. He hasstudied Educational Psychology, holds a BSc in mathematics and plans to do anMBA in Decision Support Systems. He has credit for many undergraduate coursesin addition to those required for his BSc because, as he said, he has just taken stufffrom all over the place to kind of sample it. Lorne has no formal computereducation.Before entering the computer field, Lorne held a wide range of jobs: from sewingmachine mechanic to cardiac care orderly. Lorne has worked in the computerindustry for 14 years, doing customer support, programming and consulting. Heprogrammed in Business BASIC for eight years, but has also worked professionallywith FORTRAN, COBOL, Assembly language, Smalltalk and C.Lorne's teaching background is also varied. As an undergraduate, he did teachingpractica in elementary schools, taught calculus and linear algebra labs and worked asa computer lab proctor. Since then he has taught a variety of computer topics:classes in word processing, spreadsheets, database and operating systems; courses indatabase and decision support theory; and Smalltalk, C and assembly languagecourses. Currently, Lorne is working as a teaching assistant in a Smalltalk courseand a C course.Lorne is familiar with many computer languages. In addition to FORTRAN,COBOL, C, BASIC and Assembly language (procedural languages), and Smalltalk (anobject-oriented language), he has also used PROLOG (a logic language), and LISP (afunctional language).What Teachers Know about Programming^ 77During our interviews, Lorne told many detailed stories about his past and oftencited industry experiences to support his arguments. He frequently used examplesto illustrate the points he was making and offered such detailed explanations of theobject-oriented paradigm (including detailed diagrams to illustrate his codingexamples) that at times it felt as though he were teaching me Smalltalk. Lorne usedseveral physical metaphors in his speech, talking about taking a step in C, breaking[problems] down and playing with programming languages.Lorne's Knowledge about ProgrammingLorne likes using the computer as a tool, as opposed to studying computing for thesake of advancing knowledge about the computer. He is mainly interested indecision support systems applications. In keeping with this utilitarian view, Lornecategorized the languages he knows in terms of the applications for which they areused: business, scientific, technical and artificial intelligence programming. Thelanguages Lorne most likes are in the latter section -- languages like PROLOG andSmalltalk.Because Lorne sees the computer as a tool, he likes languages in which he canquickly and easily develop correct code. Thus he sees great power and flexibility in alanguage like Smalltalk, which has a large library of easily modified reusable code.Lorne said that as a professional programmer he spent a good 75% of [his] timeredoing something that somebody else had already done. He stressed that anadvantage of Smalltalk is that the programmer can use and modify existing coderather than having to develop it from scratch. This leads to fast development timeand less room for programmer error. Lorne told a story about an intelligentdatabase project he worked on:What Teachers Know about Programming^ 78I did the prototype myself in Smalltalk in six weeks ... theprototype was 90% of the job and then [the code had to beconverted to C] so myself and two part-time programmers spentthe next year taking what I had done in Smalltalk and convertingit into C. And we didn't get done in time. We didn't even geteverything I did in six weeks by myself.Lorne feels that part of the reason the conversion took so long was that he and theother programmers had to create in C the interfaces that are built into Smalltalk. Aswell, he encountered problems with integration of the C code that did not arise inthe Smalltalk environment.Lorne sees strong distinctions between the programming paradigms with which heis familiar. He said,When programming in the procedural paradigm the programmerlearns to organize everything, to know exactly what you're goingto do, to have the structured detailed outline, a flowchart ofexactly what you're going to build and know what you're going toput together, then write all your modules, put in stubs andeverything, link it all together and you're done.Procedural code doesn't really look anything like what's going on [in the world]it's not an exact model.Object-oriented programming involves a different approach. Object-orientedprogrammers think about real world objects, their attributes and behaviours. Theydesign interfaces by drawing pictures and keep adding pieces as [they] go along.With an object-oriented approach you're looking more at an exact model.Lorne thinks that the shift from a procedural to an object-oriented paradigmrequires a radical change of thinking. When learning Smalltalk, he had to unlearneverything [he] knew about structured thinking ... instead of doing a top-downanalysis, [he] had to start thinking of things as objects.What Teachers Know about Programming^ 79Lorne likes Smalltalk and is also strongly attracted to the logic of the declarativelanguage PROLOG, perhaps, he thinks, because of his strong math background. Hesaid, Somebody wrote that language the way I think. When coding in PROLOG,though, he still found that as soon as [he] turned [his] back, shall we say, and stoppedconcentrating really heavy, [he'd] find [himself] doing something that [he] had donein traditional programming and again [he'd] get into the procedural format ... [he]had to ... make [his] thinking change.Lorne writes object-oriented code in a mix of procedural and declarative styles. Hesaid, it's declarative in that I have an object and I'm sending it a message, ... but I'mstill going to have to ... use some kind of a procedural method.In general, Lorne finds that when he learns a new language he at first writes code inthe style of a language he already knows. As he learns the new language, though, hestarts adjusting [his] thinking. He told a story about a Smalltalk assignment that hisstudents were doing. At first, he said, the approach he took was procedural. I wasthinking like that and then I stopped and I said, "But, wait a minute now, we'redoing it in Smalltalk", click, and my brains stopped thinking. He then startedthinking about the problem in an object-oriented way. I wondered aloud about theinfluence of the language:Debbe:^... So in that sense the language shapedLorne: My thinking.Debbe: the way you were thinking.Lorne: And, and yet, that's the same way I would do it in C++,exactly the same way. Whether it was Smalltalk or C++.Debbe: Mm-hmm.Lorne: So I'm not so sure if we're thinking languages orparadigms at this point.What Teachers Know about Programming^ 80Despite his sense that going from a procedural to an object-oriented paradigm is likegetting out of a car and climbing into a jet, Lorne feels that a good understanding ofassembly language programming is important for all programmers. As he said,... if you understand how the hardware of the machine works andhow to program it at that level then [other languages are] justexpansion on [assembly language]. [Assembly language], this is thefundamentals. Everyone should know this. Cuz we should knowhow the machine works.Languages, he said, have the same general type of underlying structure, so I knowhow to grab a steering wheel on a car and I know how to grab one in a jet and I'llexperiment with it a bit.Lorne feels that the computer industry is shifting towards the object-orientedparadigm. Its power and flexibility is going to put us very quickly ... in anenvironment where programming is done more as a systems analysis. Eventuallywe should be able to stop programming and start designing systems. That should bethe end result of this object-oriented approach.To Lorne, programming is creating something. We talked about the creativityinvolved.Lorne: You cannot without imagination, just sit down andwrite good code. ... the really creative programmers ...[are] like people writing symphony orchestras ... or pieces... the violin is coming in ... and now we have the oboes... and they get excited about it ... you can just see thewhole orchestra playing ... it's an art ... like mathematicsis an art.Debbe: Yes. So programming to you isLorne: It's an art form.What Teachers Know about Programming^ 81Lorne also described programming as a thinking person's game that takes a lot ofintelligence. In addition to the analogy of the symphony, Lorne comparedprogramming to writing a research paper. He described a person writing a paper:She starts writing notes and then she looks at all the notes she'sput together with the outline and then she starts fleshing it out,rearranging things and she prints it off, reads it, goes through andchanges everything, goes back, keeps modifying it, and keepsiterating until she's done. ... it sounds awfully familiar, doesn't it?Good programmers, Lorne feels, must most importantly be motivated to want toprogram. The person he described in the above quotation, although she wouldmake a darn good programmer in terms of skill, would make a lousy programmerbecause she is disinterested. Programmers can organize their thoughts into anoverview of an entire system, ... break it down into all the component pieces, solvethe pieces and put the pieces back together until [they] have a solution to the entireproblem. Programmers think logically. Lorne mentioned an artist he knows whowould not make a good programmer because she is not really aware of cause andeffect. Although he does feel that programming requires creativity, the kind ofcreativity it takes to draw or paint is alien to what [he] does.Lorne pictures programmers as slightly eccentric people, who like to do esotericprogramming, but who know that they have to do the grunt work in order to get achance to play with things. He distinguishes two kinds of programmers, thebrilliant ones, who have innate skill, who just sit down at the keyboard and all of asudden, boom, it becomes part of them, and those who plod along relying onpatience and determination. He said that he is of the latter type, although he addedthat he is what they used to call a hacker.Lorne entered the programming field by accident. He had no programmingknowledge and was working as a data entry clerk when his company's programmerWhat Teachers Know about Programming^ 82quit and he was asked to take over. He struggled on his own for several weeksbefore the company hired someone else. Lorne continued programming, stilllearning on his own, reading program listings and manuals, this time withsomeone to guide him:I'd start writing stuff and I'd get stuck and I'd say, ... "what do Ido?" And [the boss would say], "Read the manual." And thenhe'd say, ... "if you look at this ... you might find somethinginteresting". And I'd go look in the manuals, and it would guideme right into the area that I should be moving in. So in the nextyear and a half I learned by writing their system.The lessons learned in his first job epitomize Lorne's approach to programming. Helearned that he was smart enough to solve programming problems and thatsupporting information was available if he knew where to look. Lorne feels that themost important thing his boss taught him was, I can program anything, anywhere.Any computer language you want to name, I can learn.Lorne is very confident about his ability to learn programming languages. He saidthat he has played with virtually every computer language that's around. He seemsto learn languages best when he can, in fact, play with the code. He learnedSmalltalk by going through the tutorial examples in the manual, [ripping] themapart step by step until [he] knew what was happening. He likes the fact thatBusiness BASIC in interpreted mode allowed you to go through, examine variablesand step through a program and actually see what was happening while themachine was changing states. As well, supporting documentation is important.Lorne mentioned several times the amount of time spent looking in manuals whencoding in various languages and stressed the importance of knowing the routinesavailable in code libraries.What Teachers Know about Programming^ 83Lorne's Knowledge about Teaching ProgrammingLorne enjoys teaching. After having some difficult experiences with elementaryschool administrations, he realized that he wanted to teach at the post-secondarylevel, where [he] would have the freedom to be as weird as [he] wanted to be, still beable to teach people and have a lot more time available for things like research.Lorne said that quite a few of his computer students have a natural talent forprogramming. Those people you don't even really teach, you just show themwhere the ideas are and say OK, go at it. In order to learn to program, he feels thatstudents need to [sit] down in front of a computer and [play] with it and [try] thingsand [experiment]. He sees himself as a resource person for the students, someonewith whom they can discuss solutions. He also stressed the importance of otherresources. Several times he mentioned that students really have to know [the]libraries in order to code in Smalltalk.Lorne explained how in a Smalltalk course he would implement his thoughts aboutlearning. He suggested that rather than teaching them some basic fundamentalsand then getting them to do projects like we would do in another language, which isthey way in which the course is now being taught, he would have students gothrough the Smalltalk manual, doing the tutorials and having someone explain theexamples to them. He said that now the students don't take time out to sit downand play with all these different things and find out. They don't experiment with it.Because that's how you gotta learn this system, is experimentation.When explaining Smalltalk code, Lorne drew pictures like the one in Figure 3,which incorporates circles and arrows to illustrate objects and classes, as well asdetailed code segments which are contained in methods. As Lorne explained theWhat Teachers Know about Programming^ 84code, he gave very detailed information about the syntax and meaning of eachsymbol.CollectionsDictionarysort"(self values) asSortedCollection:[:a :b I a getDept < b getDept]DeptgetDeptAdeptFigure 3. Lorne's Conceptual ModelLorne feels that students' first language should be assembly language.Lorne: ... it comes down to a case of understanding the machineand how the machine works. And if ... a person really,really understands the inside of that machine and what'sgoing on inside of it and then starts looking at a higherlevel language and thinking of all the statements in thatlanguage as just ... groups of machine-level code, ... thenone starts to understand how a programming languageworks. And then you start looking at ... a new language... you will recognize that it has to do certain things in acertain fashion regardless. ...Debbe: So you would say that ... if they have that understandingof that architecture then they will find other languagesLorne:^I think easier.Lorne thinks that he might be able to predict whether a person will be a goodprogrammer, although he has never tried.Debbe: If you think that you could perhaps, what kinds ofthings would you be looking at?85What Teachers Know about ProgrammingLorne:^Well, I'd be looking at ability to define the problem.Debbe: Mm-hmmLorne: The ability to figure out some kind of an approach, somekind of means of solving that problem. Whether it wasright or wrong, as long as they tried to solve it. If theytried to break it down in any way whatsoever, isolate apart, portion of the problem and resolve that, then Iwould think they would probably have a darn goodchance.Lorne was surprised to find that a student who he felt, because of poor Englishlanguage skills, would have great difficulty in a C programming course, is doingvery well. He feels that the student is succeeding because of hard work; because hehas spent time playing and experimenting. Lorne feels that students can, withpatience and determination, succeed at programming whether or not they have anatural innate skill.Lorne's students, he said, are having a lot of difficulty learning Smalltalk.We've taught them this top-down structured analysis approachfor a couple of years and we've actually, I think, in some waysrequired them not to think, but rather to follow a program that wehave instilled in them and then they come into something likeSmalltalk, where traditional thinking will mess them up reallybadly. The more structured they are, the bigger problems they'regoing to have cuz they have to stop thinking of programs asmodules of code linked together that manipulates data whereasthey have to start thinking of real world objects.Students, he said, have particular difficulty with the concepts of inheritance andpolymorphism and with the idea that objects exist in the Smalltalk space. Learningthe language is causing them a lot of difficulty because it is a brand new paradigm, atotal different way of thinking.Lorne and I discussed the possibility of using C++ rather than Smalltalk to teachobject-oriented programming. Smalltalk, he said, is the purist's object-orientedprogramming language because it forces the programmer to use the paradigm. C++,What Teachers Know about Programming^ 86an object-oriented extension of C, allows the programmer to use the procedural orthe object-oriented paradigm. Lorne suggested that although Smalltalk is nicebecause it forces them to program in that object-oriented paradigm, learning C++might be a better way to introduce the students to a new paradigm. Because C isfamiliar to them, the switch would be gradual and he, as a teacher, would be able tobe subtle about the changeover. He said that some of the professional programmershe has seen working in C++ were doing a lot of sloppy things, cuz they were doingtraditional C programming. He felt, though, that programmers would become goodobject-oriented programmers in the same amount of time using either C++ orSmalltalk, but that those using C++ would experience less frustration.An Integration of Lorne's KnowledgeLorne uses the computer as a tool. As such, he organizes language categories interms of application and is attracted to languages that make it easy for him to writeapplications quickly and correctly. His sense is that the computer industry ismoving in the direction of the object-oriented paradigm, which offers programmersa large library of existing code that is easily modified. He therefore feels that it isimportant to teach students the object-oriented paradigm because if [they] don'tknow how to program in OOPS (object-oriented programming systems), they'regoing to be having a hard time finding work.Lorne likes to use the computer as a tool to model problems in Decision SupportSystems. The idea that it is important for him to be able to model the real world isevident in his choice of examples and illustrative anecdotes. Lorne's background incomputing is totally experience-based. Thus his sense of computing comes fromindustry examples and requirements. His fascination with the object-orientedWhat Teachers Know about Programming^ 87paradigm stems partially from his perception that it allows the programmer to moreaccurately model the world than does the procedural paradigm.As well as a need to model the world, Lorne demonstrates a strong attraction todetails. During our interviews he described in extensive detail his industry andteaching experiences. When explaining the differences between paradigms, heinvariably offered specific examples and explained them in detail. He seems tounderstand and learn topics best when he can, as he did with Smalitalk, takeexamples and [rip] them apart step by step. His feeling that students should learnassembly language as a first language appears to be a manifestation of his feeling thatknowledge of details is crucial to understanding.The conceptual model that Lorne uses incorporates both his sense that a computerlanguage can be used to model the world and his preoccupation with details. Whenexplaining code, he at first drew circle and arrow diagrams to illustrate his models ofobjects and classes. Then he added to them perfectly detailed code. The modelseems to parallel Lorne's sense that statements in a high-level language are just ...groups of machine-level code, regardless of the paradigm of the high-level language.As well, it graphically illustrates Lorne's sense that when doing object-orientedprogramming, he is using a mixture of procedural and declarative styles.Lorne sees major differences between coding in the declarative style and in theprocedural style. In the former, he is telling the computer what is to be done and inthe latter he is telling it how to do it step by step. The object-oriented style for him isa mixture of the declarative and procedural styles, and is primarily concerned withmodeling objects, their attributes and behaviours. Whereas the procedural style isepitomized by structure and planning in a top-down way, the object-oriented style isbottom-up, involving the addition of pieces as you go along. It also allows theWhat Teachers Know about Programming^ 88programmer to plug in black boxes of already existing code. Lorne feels that the shiftfrom one paradigm to another is very difficult and his thoughts about teachingshow his desire to make the transition as easy as possible. His sense that C++ wouldbe a better vehicle than Smalltalk reflects his feeling that the switch should be madein as subtle a way as possible so that the students experience little frustration.Lorne finds that when switching from one paradigm to another his first tendency isto code in the style of the paradigm which he knows. Thus he feels that theparadigm has shaped the way he thinks when programming. He sees the samesymptom in his students when they are learning a new paradigm. However, he alsorecognizes that certain languages fit certain people. PROLOG, as he said, is writtenin the way [he] likes to think.To Lorne, programmers have a certain creativity and are often eccentric. He seesboth brilliant programmers, those with an innate talent for programming, andplodders, those who get by with hard work and determination, in his classes.Although both procedural programmers and object-oriented programmers need theability to break a problem down into components, solve the components and putthe solution back together, Lorne contends that highly structured thinking andtraditional procedural approaches will be a hindrance to object-orientedprogrammers.For Lorne, programming is learned by experimentation. He has no formalcomputer education, but was immersed in a programming environment where hewas forced to learn on his own. He suggested that students learn best in the sameway. He also stressed the importance of support. Programmers, he feels, spend a lotof time using manuals and resource people. As well, they should have available tothem extensive libraries of code. Thus, Lorne would prefer to teach Smalltalk byWhat Teachers Know about Programming^ 89explaining to students in detail the tutorial examples in the manual and by givingthem a chance to play.What Teachers Know about Programming^ 90Isaactying all the pieces togetherIsaac and I have sat at neighbouring desks since he began his current jobapproximately four years ago. We have taught the same courses and are familiarwith the same students. That we previously had discussed teaching methods andapproaches was evident in the tone of our conversations. Because of our sharedexperience, as we examined the teaching of programming we were able toconcentrate on underlying conceptions rather than on superficial details. Isaacwanted very much to discuss teaching, and said that he liked the second interview(in which we concentrated on teaching) much better than he like the first (in whichwe concentrated on his background). Near the end of the first interview, thefollowing exchange took place:Debbe:^All right, let's talk a bit aboutIsaac:^We haven't talked about teaching yet.Debbe: I know. Shall we talk about that?Several times during the interviews Isaac prompted me in this manner, seeming tosignal me that he had nothing more to say about a particular topic or that he wantedto move on to a new topic.At times Isaac cautioned me that we were dealing with issues about which he hadonly surface knowledge and commented on his lack of preparation for some of thequestions. After the first interview, Isaac sent me a lengthy electronic mail messageoutlining the details of his past experiences (about which he said his "recollections[during the interview] were flawed") and stating his views about teachingprogramming. The contents of that message have been included in this section.What Teachers Know about Programming^ 91Isaac learned to program in the trenches, through night school and correspondencecourses, and on his own. His first exposure to programming was in an electronicscourse. Then he bought and learned to program a personal computer and aprogrammable calculator and began taking language courses: in FORTRAN, Pascaland assembly language. His work experience includes assembly languagemaintenance of FORTRAN programs and industrial automation programming. Aswell, he taught himself C, Modula-2, and some Ada and FORTH. As Isaac said, hehas taken courses in everything under the sun and is about to begin a post-graduatedegree in computer science. Isaac has written several articles for computer tradejournals.Before starting his current job, Isaac delivered industry training courses and taughtelectronics (computer architecture and some assembly language programming) forfive years at a community college. Isaac initiated the two C language courses at hispresent school and the bulk of his teaching has been in that area. He also has taughtPascal and computer architecture and established a data communications specialty.Currently Isaac is the head of the microcomputer area and teaches C, OS/2 andnetwork programming.The languages with which Isaac has worked have been procedural. However, hehas had some exposure to LISP (a functional language) and PROLOG (a logiclanguage) and is currently learning C++ and Smalltalk (both object-orientedlanguages). He plans to spend more time learning Smalltalk in the coming months.Isaac incorporated a large number of quantitative details in his conversations withme. He told me that 60 to 70% of his teaching has been in C, that he could probablypredict with 85% accuracy whether a student would make a good programmer, andthat to be a good programmer a person probably should have a minimumWhat Teachers Know about Programming^ 92intelligence quotient of somewhere around 110. Isaac rarely used acronyms in hisspeech. He expanded words like Presentation Manager and ApplicationsProgramming Interface rather than calling them 'PM' and 'API'. During ourdiscussions, Isaac used physical metaphors -- saying things like tripping me up, onmy feet, and get my hands on -- as well as many cliches, such as neither fish norfowl, part and parcel and from ground zero.Isaac's Knowledge about ProgrammingTo Isaac, programming is a large highly technical subject area which requires veryspecialized skills. As he said, ... there's a fairly large body of knowledge that youhave to assimilate ... you have to be able to remember all the keywords in thelanguage. If it's a library that you're working with, you have to be able to rememberwhat all the function calls are. Programming projects in the real world involvemany people and each program is so huge ... you couldn't possibly remember all of itat once. Isaac is currently working with the Applications Programming Interface inOS/2, a complex system, containing many data types, variables, messages, andfunctions, in which a lot of the parts of the systems interact. Isaac said that despitenearly two years of steady work, [he is] only now beginning to feel that [he has]command of most parts of OS/2. Programming, for Isaac, means tying all the piecestogether. Long debugging sessions, which Isaac said are part of even the most wellplanned and well designed project, often mean, for him, spending hours and hoursand hours poring through thousands of pages of documentation to try and find onelittle fact. Isaac appears to need to understand each little fact in order to understandentire systems. He liked dealing with bits and bytes in his industry jobs and, whenexplaining a C program to me, made no assumptions about code behaviour withoutchecking every detail.What Teachers Know about Programming^ 93Isaac sees programming as an interesting intellectual pursuit that gives him afeeling of accomplishment. He likened it to carpentry.Debbe: Do you have the same feeling about carpentry?Isaac: Yes. Yeah, you bash a bunch of things together.Debbe: M m m .Isaac:^If the nails don't fall out, you feel pretty proud of itafterwards. So, yeah, it's a feeling of accomplishment.Programming also involves creativity. The mental activity involved is creation ofsome sort ... it's like painting. The creativity must be tempered, however.Debbe: So programming to you meansIsaac:^It's a creative pursuit. To work well, it also has to be adisciplined pursuit ...Isaac often stressed the need for discipline. He said programmers need to bedisciplined in order to plan programs and go through the ... long debugging sessions.Isaac likes languages that impose discipline on the programmer. Thus Modula-2 ishis favourite language because its modularity is enforced, because its explicit blocksyntax means there's less likelihood of ... using shortcuts that end up with sloppycoding techniques, and because it is type safe (that is, an attempt to convert avariable of one data type to a disparate type will cause a compiler error). Isaac saidthat although C does not enforce discipline in the same way that Modula-2 does, theculture of Modula-2 has infected [his] C programming. He thinks that good C codeshould look like good Modula-2 code.Isaac categorizes languages into somewhat overlapping paradigms. Smalltalk andC++ are object-oriented, but have a significant procedural characteristic to them.Modula-2 and Ada, although classified as procedural, have some object-orientationavailable to them. PROLOG and LISP are in a category by themselves, as is FORTH,What Teachers Know about Programming^ 94which Isaac feels is kind of a unique paradigm. Procedural languages are, for Isaac,much easier to categorize. He further categorized the procedural languages heknows in two ways. Pascal, C, Modula-2 and Ada are structured, whereas COBOL,FORTRAN and assembly language are unstructured. (Isaac said that he knows atleast four distinct assembly languages and itemized them.) Within the structuredclass, he further specified that Modula-2 and Ada are suitable for big projects becausemuch of the discipline is imposed by the language rather than having to be imposedby the programmer whereas Pascal and C are not.Isaac took one course in artificial intelligence in which he wrote a PROLOGinterpreter in LISP. About the two languages he said,I didn't like either one of them very much. I actually wrote a littlePROLOG interpreter which was not very good and not verysuccessful and I didn't really understand what I was doing ... so ofall the languages that I've had contact with, those are the two thatI feel least comfortable with.The discomfort was caused, he said, partly because the paradigm was so completelydifferent. ... partly it wasn't the language. Partly it was I was trying to do somethingwith the language that was unfamiliar to me. Isaac pointed out that the fact that hedoes not want to pursue use of PROLOG and LISP is not a weakness of the language,rather it is a weakness in [his] understanding and appreciation of the language.Isaac does appreciate the object-oriented paradigm and said, we're going to requireprobably fewer and fewer programmers ... now that development systems are gettingmore intelligent -- object-oriented systems, ... where you can put together anapplication in ... weeks instead of years. He sees great potential for the object-oriented paradigm and particularly for a language like C++ which supports bothprocedural and object-oriented programming. Although when coding in C++ he[finds himself] constantly falling back into the ... structured, procedural paradigm ...What Teachers Know about Programming^ 95[he sees] potential for the mix of the two paradigms. He thinks that both paradigmsare necessary because one paradigm is not sufficient to solve all problems. Certainproblems, before you even try to take them apart and figure out how they're gonnabe solved, the problems themselves fall more into a procedural type of solution.Others, like those he deals with when using OS/2 and Windows, would work verywell with an object-oriented paradigm. He said that the object-oriented supportwhich allows him to build a new capability by taking an existing class and adding toit, so you don't have to kind of ... bailing wire methodology to build it, ... [is] a bigadvantage.We discussed the influence of language on the way in which a programmer thinks.Debbe: Some people claim that the language that we code inshapes the way we think. Other people say that wechoose languages that we like based on the way wethink. Do you have any comment about either of those?Isaac:^I think both are true. I think that oftentimes peopledon't choose their language -- that their language ismandated by their job.Debbe: Yes.Isaac:^And once it's mandated by their job, they start to thinkthat way. I think that people who do have the freedomto choose their language probably do choose thelanguage that best matches the way they think. I think alot of it has to do with, what language were they firstexposed to? And if you were first exposed to, let's say, afunctional paradigm, you'd probably have a harder timewith an object-oriented paradigm or vice versa.Debbe: ... Do you think that that has any bearing on thediscomfort we both felt when going to PROLOG?Isaac:^Yes, oh, for sure, for sure. We and hundreds of otherslike us have trained our minds to think of problemsolutions based in a certain way of doing things, sosuddenly having to solve a problem in a way that'sforeign to us is going to be very difficult. WhichWhat Teachers Know about Programming^ 96obviously lends strength to 'we think in the way thatour languages deal with problems'.Isaac feels that the only way one can choose a language that fits one's way ofthinking is to become good at many different languages. He thinks that it is possibleto become proficient in many different paradigms, but not all at the same time andsaid that it takes about two years to become proficient in a language.To Isaac, programmers exist along a continuum from the scruffies to the neats. Thescruffies are the hard core, quintessential programmers -- they have long hair, areunkempt, wear blue jeans and sneakers, and spend most of their time writingprogram code. The neats, on the other hand, wear three-piece suits and project acorporate image. The latter are maybe the [guys who are] doing some of the ...higher level thought work, but, as Isaac said, the dress is ... kind of irrelevant in away ... it's more indicative of ... an image that you have to project ... or that youchoose to project. More significant, Isaac feels, is the measure of quality that he usesto distinguish among programmers. Those with whom he is impressed have broadtechnical knowledge, apply a scientific method to their thoughts, and produce manylines of good, well documented, zero-defect code a month. Others have putthemselves in kind of a narrow box where they [are not] learning new things ... [theyare] plodders who bring down that average ... line of code per month figure.Isaac's Knowledge about Teaching ProgrammingTeaching, to Isaac, is performing. He feels that in order to teach well, one must bewell prepared and interested in the material. That is, one must feel comfortablewith the material, have the facts straight, and also feel enthusiasm and excitement.A good lecture, he said, is when [he gets] a flow going, when ... the words that [hesays] seem to lead from one point to another. Isaac said that he often cannot predictwhen a lecture will go well:What Teachers Know about Programming^ 97As much as I plan my ... lectures -- and I have fairly elaborateoverheads that I follow -- ... I still talk more or less off the cuff andjust use the ... lecture notes as ... guideposts and when things flowfrom one topic into the other, well, then the lecture feels to me tobe right. ... I consciously try to cultivate that flow, but it doesn'talways work and sometimes it seems like the more I try tocultivate it, the less it works.Isaac mentioned several times that it is possible that the students do not share hisperceptions about lectures that have bombed. That a lecture feels right from [his]end of it ... obviously ... doesn't mean much to the students.Isaac feels most enthusiastic when he is teaching something for the first time. Hesaid, I've often felt that the first time I ever give a lecture is better than any othertime I give it. Because I've just spent ten hours preparing for that lecture and I'mreally up for it and really keen about it. He enjoys teaching topics new to him andhas initiated the teaching of several new courses at his school. The thing he likesmost about teaching is learning. In his note to me he said, "the main reason that Iam here is to learn -- if along the way I can show a few other people what I havelearned, so much the better."Isaac feels that programming is taught to prepare students for jobs. Although hethinks that students in elementary and high school levels should learn to becomputer literate, that is, that they should learn applications, he said that theyshould not learn to program because we don't need a whole population whereeverybody can program. His teaching is geared toward job training. He teachesmethodologies that, he feels, the students will require in the real world. As well, hesaid, he attempts to project an image to the students of what the corporateprogrammer looks like.What Teachers Know about Programming^ 98Although he attempts to influence the students to see a certain image, Isaac feelsthat we're not teachers, we're just guides, and [the students] have to learn[programming] on their own. As he said,I think that programming is mainly something that people teachthemselves. I think that as much as we can point out the syntax tothem, point out the semantics of the language, try and explain tothem what's important, try and get them to understand existingalgorithms so they can then build on them, I think in the finalanalysis that people teach themselves how to program based on amodel that we show them. I think a carpenter can teachsomebody how to hammer in a nail, but in the final analysis,learning how to hammer in that nail is the person with thehammer in their hand trying it, and I don't think it's any differentin programming. ... learning programming isn't learning a bunchof facts. You can learn history by learning a bunch of facts. And assoon as you can mimic the facts you know history. Right? And assoon as you can mimic the syntax of the C language, you don'tknow C.People learn programming through practice, practice, practice. The practice,however, must be accompanied by applied discipline. Practice without disciplinelimits how far [the students] can go. Isaac's note to me read, in part,As to my views on teaching programming: more and more I amtrying to emphasize "professional practices" above all else -- i.e.,good style, good structure, maintainable code, efficiency, andelegance. I feel the syntax and semantics will be easily absorbed bythe students with little effort on our part — the "style" aspect mustbe hammered repeatedly lest they develop bad habits that they willcarry with them forever.Isaac talked about forcing students to write C in a modular style and about studentshaving an indoctrination with their biweekly exercises. He includes detailedprogram implementation specifications with his major project to help [the students]and partly ... constrain them a little bit too. One of his major concerns aboutstudents learning programming in elementary and high schools is that the studentslearn a very undisciplined approach to programming. He said that the studentssometimes get the idea that the only thing of any value is the eventual code andWhat Teachers Know about Programming^ 99that he is always struck how consistently the students seem not to believe us whenwe tell them how important it is that [structured] approaches be followed.The content of Isaac's C course quite closely matches the sequence of the standard Creference guide, written by the authors of the C language. Isaac changes thesequence of topics if the students need certain facts in order to complete a project.As well, he reviews topics, such as precedence rules, that he thinks are particularlyimportant.Isaac feels that the first language a student learns should be something small,something very type safe, something that enforces structure to some extent. Hewould rather teach a first course in a very very constrained environment where thelanguage has the capabilities that are needed to teach those structured concepts andno more. Because most of the real work in programming is still done in procedurallanguages or in languages that are at least partially procedural, the first languageshould be the best -- whatever that means -- procedural language you can find,which is probably some offshoot of Pascal.Isaac feels that programmers need above average intelligence so that they can graspand remember the facts in the large body of knowledge that makes up the discipline.They should enjoy problem solving. Isaac mentioned someone who he thoughtwould be a good programmer who is an inveterate tinkerer. As well, programmersneed the temperament to apply discipline to the process. Discipline, however, is notsufficient; the best programmers are able to blend creativity and discipline. Isaac saidthat someone who was all creativity would be a better programmer than someonewho was all methodology, because creative programmers can have disciplineimposed on them. Isaac feels that he can predict which students will be goodprogrammers by listening to their speech patterns. Those that do not pay anyWhat Teachers Know about Programming^ 100attention to [the] grammar and syntax of their language, who speak in slang and askill-formed questions, he feels will not make good programmers.An Integration of Isaac's KnowledgeIsaac's programming background is strongly procedural and he has worked withmany assembly languages. His view of programming and programs as anintegration of a large number of details is consistent with this experience. Hisattention to detail is apparent in his speech, and in his need to get the facts straight,not only in order to teach them and to integrate them into programs, but also inorder to respond to interview questions. Isaac's sense of programming is wellillustrated by his carpentry analogy: programming is building things from smallerparts and hoping that the nails don't fall out. The way in which Isaac categorizeslanguages also offers a clue to his view of the programming world. His view of theprocedural paradigm and the ways in which other paradigms integrate with it has ahigh degree of granularity. His descriptions of paradigms with which he has littleexperience are much less precise.Isaac teaches programming so that his students can get jobs in the programmingfield and consciously attempts to impart to them his image of a corporateprogrammer. Programmers are intelligent people who like to solve problems. Theyare creative, but have the temperament to apply a scientific method to theirthoughts. For Isaac, the best programmers combine a disciplined thought processwith a broad range of technical knowledge.Isaac believes that teachers do not teach programming, rather that students learn iton their own through much practice. However, he feels it is imperative thatstudents apply disciplined methodologies that will allow them to cope with theintegration of the many small details they will be expected to deal with on the job.What Teachers Know about Programming^ 101Thus he very much takes the expert approach to teaching programming, attemptingto indoctrinate students into the stepwise refinement disciplined kind of approachby managing the way in which they do their lab assignments and projects. Isaac'sstyle is also very structured. His lectures are supported by elaborate preparedoverheads and course notes and he pays strict attention to language details.Because most industry programming is done in the procedural paradigm andbecause the first course should be taught in a very very constrained environment inorder to impose the necessary discipline and allow him to teach structured conceptsand nothing more, Isaac feels that the students' first language should be a Pascalderivative.Isaac maintains that working in a specific language or paradigm shapes the way inwhich a programmer will approach problem solving. His preference for the highlystructured procedural paradigm is evident in his selection of Modula-2 as afavourite language. It is possible that Isaac's views will change after more exposureto the object-oriented paradigm. However, at this point, his teaching stronglyechoes his desire to impose the discipline that will help his students in tying all thepieces together.What Teachers Know about Programming^ 102Kylethe power of modeling the real worldKyle was first exposed to programming 14 years ago in a computer scienceundergraduate co-op program. The first language he learned was PL/I and his workexperience involved PL/I and APL programming at a large company. After workingfor some time and living abroad for several years, Kyle, while investigatingcontinuing his education, was introduced to the concept of expert systems whichimmediately caught [his] interest. He completed a college diploma program with aspecialization in expert systems and worked for a short time building expert systemsin PROLOG. He then began his current job working as a systems analyst, a positionhe has held for approximately six years. His work during that time has been variedand has included the use of FOCUS, 4GLs, SPSS, REXX, high-level tools forWindows, and Oracle. Kyle also does consulting work using Smalltalk andPROLOG. He is presently working on a PROLOG based knowledge systeminvolving genetics research.Over the past several years, Kyle has taught various computer courses in topics suchas object-oriented programming, knowledge systems, Pascal, LISP, APL, PROLOGand Smalltalk. He is currently teaching Smalltalk.Kyle knows many programming languages. He said that it would be easier to listlanguages that he doesn't know than to list languages that he does. We discussedsome of the languages with which he is familiar: Pascal, PL/I, C, assembly language,APL (procedural languages), Smalltalk (object-oriented), LISP and Scheme(functional) and PROLOG (logic).Kyle seemed very calm and thoughtful during the interviews. Several times duringthe course of the interview he appeared to reconsider and darify his opinions. HeWhat Teachers Know about Programming^ 103used several analogies and referred often to eastern philosophies, with which he isvery familiar. As well, he used physical and visual metaphor in his speech: talkingabout things which are naturally reflected in the object-oriented paradigm, aboutproducts which support a certain view and about writing a system to captureknowledge.Kyle's Knowledge about ProgrammingTo Kyle, programming is a discipline that gives him an outlet for creativeexpression; that allows him to construct things and to manipulate the world. Thecreative process is, to him, similar to the process of composing music. However,Kyle likes the fact that programming is more practical than composing and allowshim to solve real problems. His current interest is in socially relevant applicationsof knowledge systems and AI (artificial intelligence).Kyle said that programming involves disciplined and logical thinking and forces theprogrammer to think abstractly in order to make conceptual mappings of a problemdomain. He enjoys the intellectual stimulation he gets from programming; he saidthat programming gives him a gee whiz effect and that he finds the rapidlychanging discipline challenging.As well, Kyle sees an aesthetic beauty in programming. He gets a sense of pleasurefrom this beauty in the same way that he gets a sense of pleasure from a beautifulmathematical proof. There is a correlation, he said, between the pleasure he getsand the aesthetic qualities of a language. Languages which are consistent to sometype of theoretical basis are aesthetically pleasing to him. Thus Smalltalk, which iscompletely consistent to the object paradigm and PROLOG, consistent to the logicprogramming paradigm, are his favourite languages. He is intrigued by APL, in partbecause of its consistency to the ... paradigm of ... manipulating matrices. OtherWhat Teachers Know about Programming^ 104languages, which are more murky, which just are built to get the job done, heresponds to less positively.Kyle likes programming, but does not like it to outweigh other aspects of his life. Hesaid that what he dislikes is that programming can create too much mental activity[so that he does not feel] completely integrated emotionally, mentally, spiritually.He also dislikes programming work which is trivially easy for him. The only areain which he now finds difficult and challenging and interesting problems is artificialintelligence.Kyle pointed out that he feels that working as a programmer alters aspects of yourpersonality and mental characteristics. He finds that because it is easy to quicklychange the malleable objects in the world of software, the transition from the worldof the mind to the world of physical things and people is jarring. During thetransition, when he is becoming grounded, he is impatient and frustrated with theslowness of manipulating objects in the physical world or the amount of effortrequired to make a change. With people he is more short, less sensitive and lesscompassionate than he would normally be. If someone is not doing somethingright, he wants to just sort of push that button and make [them] ... do it the rightway. While he recognizes that, in the real world, the analytical approach is not theonly way, he finds sometimes that attempting to resolve conflict with non-analyticalpeople is like a clashing of ... two universes.Kyle knows many languages, which he categorized by paradigm. He distinguishedfour classical paradigms: procedural, logic, functional and object-oriented. As well,he mentioned two others, which he said perhaps could be classified as paradigms: adata modeling paradigm and a rule-based paradigm.What Teachers Know about Programming^ 105The procedural paradigm is one in which you ... are specifying a series of actions ....A program is made up of a series of statements which are executed in sequence andthe actions are carried out in the order in which functions and procedures are called.The logic paradigm is based on the predicate calculus and involves the specificationof relationships or constraints. Kyle said that PROLOG is an example of a languagewhich uses the predicate calculus with extensions, such as backtracking and the factthat clauses are chosen in the order in which they have been entered.The functional paradigm is based on the mathematical concept of functions. Kylesaid that although LISP is not a functional language, because it contains constructssuch as the go statement, loops and macros that fall outside of the functionalprogramming paradigm, one could program in LISP as though it were functional bylimiting the programming to a subset of pure functional programming.In the object-oriented paradigm, data and ... procedures are bound together intosingle entities called objects which are organized into a hierarchy of [classes] ... whichhave the properties of inheritance. Object-oriented programs involve the sendingof messages. Kyle stressed that the object-oriented paradigm reflects a very commonway that people think about a lot of the world. If you were to look into ways peoplethink about the world in terms of generalization, specialization or whole/partcategories, these are things which are fairly naturally reflected in the object-orientedmodel.The data modeling paradigm is almost an active data dictionary approach, which, hesaid, is the de facto standard paradigm for a lot of ... business development toolsthese days and rightly so because it's an extremely effective and quick way to developsimple business applications. When programming in this paradigm, one defines arelational model and attaches validation routines to database fields. ScreenWhat Teachers Know about Programming^ 106generation and transaction processing are done automatically. This is almost aparadigm in itself, being only vaguely procedural and having sort of a flavour of theobject-oriented paradigm, but not quite.The rule-based paradigm has some analogies to the logic paradigm, but is notnecessarily based on the predicate calculus. It involves the definition of discreteindependent rules or constraints which are then processed through some type of aninference engine, be it backward (chaining), forward (chaining), or a constraint-basedengine.Although he sees similarities among languages in various paradigms, in the sensethat they employ some of the same control structures and data objects, Kyle spoke atlength about the advantages of the object-oriented model, which he said gives onethe power of modeling the real world. He said,with an object-oriented language or with various AI (artificialintelligence) knowledge representation tools and languages ... youcan get a very high-level abstract symbolic representation of theworld which has a relatively close mapping to the classical waysthat we ... model the world internally.Other languages, such as C and Pascal, do not allow such a [close] conceptualmapping. As Kyle said, part of the difference [between coding in the object-orientedparadigm and coding in another paradigm] has to do with thinking at a differentlevel of abstraction .... When you do good object-oriented programming or design,you can think at the level of abstraction that models the problem domain moreclosely.Languages like C and Pascal do not scale up well in the way that object-orientedlanguages do. By this he means that these languagesmay appear to solve [a] problem adequately without too muchprogramming effort for a small case or a small problem. ButWhat Teachers Know about Programming^ 107when you try to scale up the problem or extend the specifications,... it starts to be very unwieldly [sic] to develop the code and do thedesign.Kyle dislikes languages which make it difficult for him to achieve a specific goal.The object-oriented paradigm's modeling capabilities are supportive ofdevelopment. As well, object-oriented languages come with a tremendous amountof built in code. The object-oriented programmer can focus on just what's new in[an] application -- what's original -- and use existing components to supporteverything else. The paradigm provides a way for organizing literally hundreds ofthousands of ... software components in a way that you can browse through ... anduse them and manage that level of complexity and size.Kyle often spoke about object-oriented programming and artificial intelligenceprogramming in the same breath. He said that a lot of the concepts in object-oriented programming are also found in frame-based artificial intelligenceprogramming and that both are concerned with looking at the problem ofrepresenting knowledge.Kyle's favourite languages are PROLOG and Smalltalk for different reasons. He hasa lot of experience in Smalltalk and likes it for solving general purposeprogramming problems. It's extremely flexible and versatile and it doesn't get in theway. It scales up well to big problems because of its adherence to the object-orientedstyle, with its modeling capabilities and its support of large libraries of code. As well,Kyle likes Smalltalk's development environment and gets a sense of pleasure fromthe aesthetic beauty of the language because of its consistency to the paradigm.Kyle likes PROLOG for artificial intelligence programming, which, he said, ofteninvolves very sophisticated algorithms that involve pattern-matching or ideallybacktracking, or in which you're developing very rich complex data structures.What Teachers Know about Programming^ 108PROLOG ... supports the creation of algorithms and complex data structures andtheir manipulation really easily and elegantly. Kyle said that he has sometimessolved the same problem in several different languages and that in his experience,the PROLOG solution is profoundly smaller in terms of lines of source code and hasan elegance or a clarity to the design that is greater than any other language that [hehas] worked with.Kyle feels very strongly that one's thinking about computer problem solving anddesign is influenced by the language that you've learned, rather than ... by yourinherent mental proclivities; that one's previous conditioning and knowledge affectone's understanding of a new language. He gave an example of his first attempt tocode in Smalltalk:I'll give you a good example. The first problem I ever gave myselfto do in an object-oriented language was to draw a graphical tree ofa class hierarchy on the screen. And when I first implemented it, Idid it using one big array, in which I populated -- it was like asparse matrix -- ... I populated it with the nodes in this tree.Because that was the type of data structures and algorithms that Iunderstood. That's a horrible way to implement a tree. And notat all in the object-oriented paradigm although I did it, like I forcedthat into the object-oriented language.Now that he has learned to model in an abstract data type way, he finds that heapplies that approach to coding in languages like C or Pascal. It is not that he ismaking Pascal look like Smalltalk, but rather that he is applying more sophisticatedcomputer design knowledge to ... 3GL (third generation language) programming.When I asked him to describe to me his image of a programmer, Kyle replied thathe doesn't have one, that, to him, programmers are simply people with anoccupation. He said that people are like histograms, with many different facets ofattributes. I wondered about the histogram analogy:What Teachers Know about Programming^ 109Debbe: So people that are programmers, do they have a certaindifferent kind of uhKyle:^Yeah, well peo...Debbe: What word am I looking for?Kyle:^Yeah, yeah, certain patternsDebbe: YeahKyle:^of histograms (he laughs)Debbe: But, do their histograms match? If you could take likeall the histograms in [this office]?Kyle said that although not all programmers would share common personality typehistograms, some of their intellectual skills show similar patterns. They havestrong analytical and deductive reasoning skills. They are good abstract thinkers andare systematic and methodical in planning and in following sets of instructions.The latter skill, Kyle said, is one which programmers have learned through ...painful experience.Kyle feels that application areas are becoming increasingly abstract and sophisticatedand that programming tools now offer extremely abstract levels of usage. He saidthatthe future of software engineering is going to more and moreinvolve development by browsing existing libraries of code,reusing software components and gluing together existingsoftware components, rather than building systems from theground up.Kyle sees obvious labour saving advantages to the browsing approach and said thatthe object-oriented paradigm is an attempt to address the way in whichprogramming will be done in the future.What Teachers Know about Programming^ 110Kyle's Knowledge about Teaching ProgrammingKyle feels that education takes place ... through dialogue. When he is a student, hesaid, he will sit right in front of the teacher and draw everything [he] can out of thatteacher and interact with them. He said that the cultural conditioning that causessome students to be inhibited about learning in that way is not healthy and shouldideally be broken. Kyle feels that one of the attributes of a very good teacher is thatthey're capable of motivating the students to want to learn. He, however, is morecomfortable with students who are already highly motivated and has no interest intrying to motivate students who don't want to learn. He said, I can't see what thepoint of their lives is. ... In my opinion we should be ... focused and motivated abouteverything we choose to do. Otherwise don't bother. Kyle feels that motivationshould be central in elementary and high schools, but that by the time people reachthe post-secondary level they've made a conscious choice about what they're doingwith their lives and they understand the power of their actions and the implicationsof their actions.Kyle said that it is important for teachers to remember what students can and cannotchange. He said that students may show lack of skill due to not being veryintelligent inherently, due to lack of effort or due to lack of good learningexperiences. Whereas one can change amount of effort and one's learningenvironment and learning strategies, Kyle pointed out, one cannot change one'sinherent intellectual capacity, so most simply it would be very unskillful to tell astudent, 'you're stupid, you should try harder'. According to Kyle, the students inhis current class appear to be not very skillful. Because of pressures on their time,though, he realizes that they don't apply themselves to the course like they couldpotentially, which probably has an impact on [his] perception of their skillfulness.What Teachers Know about Programming^ 111Kyle thinks that programming could be taught in high school for the sake of forcingadolescents to strengthen their mental skills at logical reasoning, abstract reasoning,disciplined reasoning and going through a design ... in a structured fashion, -- skillsthat are general and useful in many categories. In his courses, though, he isteaching students so that they can use, in a job, the skills and knowledge theyacquire.I asked Kyle about the image he imparts to his students:Debbe: When you're teaching these students, are youconsciously trying to impart a particular image aboutprogramming to them?Kyle:^Yes, definitely.Debbe: What image is it?Kyle:^Um, there's probably more than one. One of them is areflection of my feeling that ... things like knowledgerepresentation and artificial intelligence -- and the typesof modeling of the world that they imply -- are richintellectually exciting and subtle topics that arestimulating and that represent ... a more sophisticateduse of a computer that is possible. ... I'm trying to expandtheir horizons.Kyle is also attempting to present an image of object-oriented programming to thestudents, a view that complies with his notion that in the future softwaredevelopment will involve browsing ... libraries of code ... and gluing togetherexisting ... components. A third image that Kyle is trying to convey is that there isan aesthetic beauty in ... a good modeling object-oriented or classical knowledgerepresentation approach to some problem. He is not sure, he said, how well heconveys this last image, finding that it is more or less inherent in the students --either they have sort of the type of mind that is stimulated or finds pleasure in theabstract aesthetic beauty, or they don't.What Teachers Know about Programming^ 112Kyle teaches his current course in a transitional way, changing the course somewhatin response to the students' needs. In their lab assignments, for example, he hasstudents work through chapters in the book, then assigns small problems. The firstproblem instructions are very detailed, giving instructions like "Click the Acceptbutton", but later instructions are more general, because Kyle expects the students bythat time to have understood the pattern of what things to do. The students'tutorial exercises are not graded. I asked about their response to the exercises:Debbe: So when you ask questions ... it's just a question forthem to think about, not to answer for you?Kyle:^Yeah. Yeah. I would like to think that the studentswould actually take the time to consider that question.Debbe: Do you think they do?Kyle:^... because ... they would be inherently interested intrying to master or learn the subject.Debbe: Yes.Kyle:^And some of them do, but some of them don't.Debbe: Yes.Kyle:^I have very little patience with students who aren'tinherently interested in learning and mastering a skill.Kyle assigns major programs to the students in addition to their lab tutorials. Hisfirst assignment contains the following note:This problem is more suitably handled by a DBMS (databasemanagement system) or 4GL (fourth generation language) andreport writer, than by Smalltalk. However, for the purpose ofeducation, this problem is being given first because it is 'familiarterritory' while illustrating many design and development issuescommon to most object-oriented development.Kyle said that the students have so many new concepts to learn that if on top of that,you gave them a problem that was more suitable ... to the object-oriented paradigm,What Teachers Know about Programming^ 113they would probably have to learn yet something else. In doing the first assignmentthen, Kyle expects that the students focus more on basics like ... 'how do I use thedevelopment environment?', 'what's a valid syntactical statement?', ... 'whatmethods can I use?' The second assignment involves something that is more in theflavour of the object-oriented paradigm.Kyle's outline contains useful stuff that the students want to know: the majorthemes to be covered and how they will be evaluated. As well, he includes courseobjectives because, although they don't usually think about that, he wants them toget a sense ultimately of what [he is] trying to do with them and how far [they are]going to go, what level of skillfulness they will achieve.Kyle has very strong feelings that the students' first language should be a languagewhich can do a lot instead of a language which can do a little; that it would be betterto start students off with the best instead of the worst. He said,When the students' first language is a very limited, crude, ...narrow language like Pascal or C, ... for a long time afterwardstheir view of what you can do with a programming language,their view of what you can do in computing science, is tainted bythat limitation. ... If you started off a computer science studentwith the most powerful, advanced, representation languages --things like Smalltalk or various AI (artificial intelligence) toolsthat ... model the world in a closer conceptual mapping than youget with a low-level language like Pascal, I think they'd have quitea different ... creative view about what you could do with aprogramming language.Scheme as a first language, he said, is no better than C or Pascal although because itis flexible one could build an object-oriented system in it. PL/I was a good firstlanguage in the context of the world of the late 1970's, but like any language like ...PROLOG or LISP or Pascal or C or what have you, ... none of them have a close ...mapping or modeling directly built into them for representing problems in theproblem domain the way we often think about them symbolically in our minds. IWhat Teachers Know about Programming^ 114asked if Kyle thought that learning Smalltalk first might be detrimental in the sensethat students would not understand what is happening inside the machine, the waythey would if they learned assembly language as a first language. He replied, Whydoes a student need to understand what's going on? If what you want them to do ismodel problems in the real world, why should you have to understand what aregister is? There is a decreasing need, he said, for students with bit twiddling skills,and an increasing need for students who can think and model at the abstract level.Kyle feels that some people have inclinations or behavioural skills that will allowthem to be good programmers and that others do not. Maybe after five years ofintensive training ... you could turn them into something good, but [they are] notnatural programmers. Natural programmers have strong planning and analysisskills. They think analytically and apply systematic methods to problem solving.Kyle gave an example of someone who would not be a good programmer becauseshe doesn't exhibit skillful analytical thinking. Nor does she exhibit the type ofsystematic application of method to problem solving or analysis in other problemsof her life that you would ... want to find in a natural programmer. The person hewas speaking about is an excellent painter. Kyle says that he himself can't draw astick man. ... We've all got our talents.An Integration of Kyle's KnowledgeKyle appears to look at the world from a very broad perspective. He sees many facetsof people and programming, which he is able to analyse and compare. Kyle has avery thorough understanding of the different classical programming paradigms andfurther distinguishes programming styles by adding his own paradigms (datamodeling and rule-based) to the others. Kyle's ability to integrate many perspectivesis apparent in the aspects of programming that he enjoys. Programming is aWhat Teachers Know about Programming^ 115creative outlet that allows him to solve practical socially relevant problems, butwhich also affords intellectual stimulation (if he can find a challenging enoughproblem) and a sense of pleasure from aesthetic beauty. The languages he most likesreflect his feelings. Both Smalltalk and PROLOG are pleasing to Kyle because oftheir consistency. Smalltalk also offers practicality due to its ability to doselyconceptually map the world and reusability of code and PROLOG offers elegance andclarity.The images that Kyle presents to his students echo his broad view of programming.He hopes to share with them an appreciation for the aesthetics of programming. Aswell, he wishes to give them a sense of the practicality of the object-orientedparadigm in modeling and solving real world problems. That programming offersKyle intellectual stimulation is clear from his feeling that teaching programming ata young age might [force] adolescents to strengthen their mental skills.Kyle also recognizes that people have many facets. He has no particular image of aprogrammer because programming is just one aspect of life. He does, however, seecommon intellectual skills among programmers: strong analytical and deductivereasoning, abstract thinking and planning and the ability to methodically carry outinstructions. The sense he has that people have many varying qualities is alsoevident in Kyle's comments about predicting programming success. Althoughcertain people lack the natural intellectual skills he sees in programmers, he said, itis because they have not needed to develop those skills, but have developed skills inother areas. Furthermore, he recognizes that analytical skills, while they have acertain power and advantage, are not the whole story.Kyle seems to feel that others should share his desire to take a broad perspective. Hethinks that students should want to learn and that people should be motivatedWhat Teachers Know about Programming^ 116about everything we choose to do. Thus he attempts to broaden his students'horizons; to change things so that they see the bigger picture.Kyle recognizes that there are some things, such as inherent intelligence levels, thatcannot be changed. However, other things, like cultural conditioning can andshould be altered. There exist, he feels, strong influences that can shape the ways inwhich we interact with and perceive the world. Conditioning from culture, pastlearning experiences, previous programming languages and even the act ofprogramming itself strongly shapes behaviours.Behaviours should be changed, Kyle seems to feel, so that people can attain balancein their lives. Thus he dislikes the lack of integration he feels when programmingcauses too much mental activity. As well, he feels that it is a psychological defectthat he feels frustration and impatience with people and physical things while he isbecoming grounded after spending a day programming. In terms of teaching, Kylefeels that students have a very limiting view of programming that could be changedto a different ... creative view if they were taught different languages. He wishes toexpand their horizons by showing them that you can use a computer for muchmore than counting beans and by showing them the practicalities of using alanguage that, through support of reusable code, represents the way in which hebelieves software development is moving.Kyle recognizes that it can be difficult to make transitions from one way of thinkingto another. Thus, for example, he finds it jarring to enter the physical and inter-personal world after having spent time in the mental world of programming. Hesees that students, accustomed to the world of procedural programming, find theshift to the object-oriented world a difficult one. In order to assist his students inmaking the shift to Smalitalk, he gives them specific detailed instructions until theyWhat Teachers Know about Programming^ 117are able to see the pattern of how things work. His first assignment is transitional inthat he expects them to work on the basics of the language without having toimmediately make the shift to a totally object-oriented way of thinking. Hismethods for smoothing the transition echo his sense of the way in which peoplemodel the world internally. That is, they see patterns and model the world in termsof generalizations and specializations. Not only does Kyle wish to make students'transition to the object-oriented world easier, but he also believes that their firstlanguage should be in this paradigm, because it gives them a broad view of whatprogramming is about by introducing them to sophisticated applications andutilizations of computers and by giving them the power of modeling the real world.What Teachers Know about Programming^ 118Mariowanting to push something to the limitsMario has taught computing at the post-secondary and secondary level forapproximately 15 years. He became interested in computers when he was in highschool and, after a year as a physics undergraduate, eventually graduated with a BScin computer science and mathematics, working at various programming jobs whilegoing to school. Mario's Master's degree studies involved the implementation ofLOGO. Through this work he become interested in the use of LOGO in theclassroom and decided that he would rather make a career of teaching thanprogramming. He completed a one year teacher training program and beganteaching high school math and computer science. Finding that he did not enjoyteaching at the high school level, he returned to university to do further post-graduate work and to eventually accept a full-time teaching position at hisuniversity.Mario has taught a variety of languages: Assembly languages, BASIC, BCPL, C, PL/I,Pascal, Modula-2 and FORTRAN (all procedural languages), LOGO, Scheme(functional languages), Smalltalk and C++ (object-oriented languages). He hasworked with many other languages such as COBOL (procedural), LISP (functional)and PROLOG (logic). He primarily teaches programming languages and operatingsystems and is currently teaching artificial intelligence and logic programming usingScheme.Mario and I have met many times over the past five years at meetings of a province-wide post-secondary computer educators' committee. We have discussed methodsof teaching programming and of predicting programmer success on severalWhat Teachers Know about Programming^ 119occasions and continued our investigation of these topics during our interviewsessions.The transcripts from Mario's interviews are twice as long as those of the otherrespondents. He spoke quickly and at the end of the second interview I let the taperun as we discussed pedagogical issues he had introduced that are somewhat outsidethe scope of this study. Mario's conversation was punctuated by many anecdotes,examples and jokes, by means of which he described his experiences and hisknowledge of computing research and current teaching practices. He used severalpersonal physical metaphors when describing programming: mentioning studentsthat just get paralyzed when programming, talking about having a visceral sense ofwhat the computer is doing, and suggesting that he feels a little bit nauseous whenreading PL/I code.Mario's Knowledge about ProgrammingMario finds a personal joy in programming. That joy comes from the sense ofachievement he feels when he solves a problem so hard that, on first examination,he was unsure how to solve it. He gets a thrill, he said, from working throughsolutions and often finds that by the time he actually writes code he has thought itthrough and modeled it and simulated it in [his] head so much that he has a verystrong sense of what the program is doing. He talked about having a visceral feel forwhat the computer and the program are doing. When he first began programming,he said, it was very much a sense of the whole machine. The book that changed hislife was DEC's Small Computer Handbook,  which allowed him to completelyunderstand the machine even down to the hardware level. At that time, he said, Itwas very easy to write a program that would take over the whole machine and heliked the element of risk involved in [pushing] things beyond what you're supposedWhat Teachers Know about Programming^ 120to. Nowadays, programming is less about knowing the machine than about havinga very intuitive level understanding of programs and programming tools.The desire to understand and learn the peculiarities of various tools sometimesmakes Mario feel frustrated with the tools' limitations and often leads to the dangerof going off on a tangent. There exists a tension, he said, between stopping to buildor better a tool (e.g., an editor or a library) and getting on with his task. On the otherhand, Mario does not find program bugs particularly frustrating. He expects to havebugs and finds that he can back off, switch off the judgmental part of [his] mind andstart gathering some data in order to track down their causes.Mario said that the more [he] looks at languages, the more similarities [he tends] tosee. He feels that the same semantics underlie all languages; that they are the samein the sense that ... we can achieve the same result with any of them. However,Mario does find that some languages allow him to solve problems more easily thanothers. A good language maps the ... domain that you're trying to deal with; it [fits]the kinds of problems that you can reasonably do with [it] reasonably well.Sometimes Mario has the sense that he is fighting a language rather than using it asa tool. Languages like FORTRAN, BASIC and Pascal have limitations that forcehim to put energy into things that don't have anything to do with the problem athand. He is forced to deal with bugs that have nothing to do with the problemspace, but rather with paradigms of the language. He cited PROLOG as aninteresting example: PROLOG is a kind of a funny language because if you're doingthings that PROLOG is designed for, it works amazingly well. If ... you want to dosomething that isn't really logic oriented, you end up ... saying, "oh, this is reallyhorrible".What Teachers Know about Programming^ 121As well as seeing differences in the applicability of languages to particular domains,Mario sees differences in the ways in which languages allow him to express ideas.He said that although the thrill of programming is to some extent languageindependent, what makes certain languages pleasant and others not, has a lot moreto do with the sort of mental fit of the languages. In other words, not ... is it Turingcomplete -- every language is -- but rather whether or not ... you feel like thislanguage expresses your ideas clearly. To Mario, a well-designed language is one inwhich the rules make sense. Hisnotion of how you design programs has to ... do with ...information hiding, encapsulation, object-oriented programmingand so on .... A language which supports that in a clean way isgoing to be much more comfortable than a language that doesn't.Now adding to that, a language in which I can type in expressionsand evaluate them, ... [that] will allow me to build a program upinteractively, is a more comfortable language than one thatrequires me to write a huge program and then try it out and see ifit works.Although some languages fit better than others, Mario feels that programmersshape the languages in which they work in that the way one attacks problems with aparticular language differs from person to person. You are really using a dialect ofthat language that is your personal dialect, or corporate dialect or something likethat. Thus Mario works in C as if it were Scheme, compiling very incrementallyand writing code that classical C programmers would question because that's thedialect of C [he likes] to program in.Mario categorized the languages he knows in terms of the ways in which he usesthem. The OOP languages, PROLOG, Smalltalk, Scheme, LISP and C++, he woulduse to write serious [applications]. C, assembly language and Modula-2, he said, arenot very elegant, but are practical. They are necessities in that often he will usethem when speed or system access is an issue. He often mixes C and Scheme, forWhat Teachers Know about Programming^ 122example, when it's just not suitable to use Scheme alone. In general, Mario feelsthat it makes some degree of sense, where you have a language that says you mustthink of the problem this way, to write programs in mixtures of languages. If theproblem isn't really suitable to that decomposition or that paradigm, thensometimes you're better off to simply put pieces of your program in ... differentlanguages and interface them together. Mario's favourite languages are Scheme andSmalltalk, for different reasons. He likes Scheme because it is small, clean andorthogonal. However it does not have the elaborate library that Smalltalk offers.Smalltalk, although the environment is very powerful, is not as clean as Scheme.Mario also likes C++'s libraries, which allow him to leverage off other people'swork, although he does not want to look inside the libraries because he will be toosickened.Mario would select a language for a particular project based on the requirements ofthe people to whom he was delivering the project: the platforms the programshould run on and the features and efficiency level required. He said that theperson who wants to choose their favourite language for everything ... often doesn'tget things done, just because they're so busy trying to force their favourite languageto do things that it doesn't do.Mario's image of a programmer is the kind of droid who works in the large projectin the large enterprise and very rarely does anything creative. However, he said thatthe kind of environment they find themselves in tends to be one of ... fairly limitedkinds of options. So you're not really seeing them, you're seeing theirenvironment.Environment aside, Mario sees a tension between two distinct kinds ofprogrammers. Neither end of the spectrum seems quite right if you're actuallyWhat Teachers Know about Programming^ 123talking about ... being able to do something that is useful and practical. One type ofprogrammer is the kind that wants to push things to the limits, that wants toexplore the boundaries of the system. These programmers are clever, and want tounderstand the rules and the causes of program malfunctions. Because of theirneed to understand and because they are confident that they can work throughproblems, clever programmers spend a lot of time learning, exploring and findingbetter ways of doing things. An inability to make strategic plans or to evaluatesuccess or failure, however, means that these programmers often do not produce afinal product. Mario feels that their productivity can't be measured in terms of linesof code produced. He said that although to him they are good programmers, largeprogramming shops tend not to want to hire them because once they've solved theproblem they want to go on to something else and may become resentful if asked torepeat tasks. They have more fun, though, Mario said, than goal-orientedprogrammers who will subordinate everything in order to achieve a goal. To theseprogrammers, the less known about the system the better. Rather than spendingtime finding better and easier ways of doing things, they tend to configure a workingenvironment and then leave it alone. By doing so, they get more work done thanthe clever programmers. Mario feels that it requires exceptional ability to interacteffectively with [the] complicated [programming] environment. Programmers mustbe able to rise to the challenge of being in this flexible environment and still get thetask at hand done. As well, they must be able to communicate. What distinguishesmy notion of a good programmer from a classic sort of 60's hacker ... is that I believeprogrammers should produce something that other people can read andunderstand.What Teachers Know about Programming^ 124Mario's Knowledge about Teaching ProgrammingMario enjoys teaching and appears to take a strong interest in his students' success,not just in terms of skills acquisition, but in terms of how his course interacts withthe rest of what makes them competent. To him, programming is a liberal art,learned not necessarily in preparation for the job market, but in order to acquiregeneral principles about problem solving. As he said,there's a problem solving component there that really has nothingto do with computer science that learning to program can helpyou deal with -- to do with setting objectives for yourself, decidingwhether or not they have been met, learning to cope with failure.... Those kinds of skills ... are skills that an educated citizen in oursociety ought to have.Although he is aware that there is no conclusive data to support his claim, he saidthat it's possible that learning how to program at a young age would actuallyinculcate those skills. Mario feels that it is easier to teach young children how toprogram than it is to teach teenagers, because children haven't yet learned thatthey're stupid and doomed to failure and they should only do what they're told.That really comes in high school, by which time students have developed attitudes,like math aversion, that hinder their ability to learn programming. Althoughteaching programming at a young age would allow a teacher to address attitudinalissues, Mario questions the validity of doing so, given that students in elementaryschools face serious problems such as alcoholism and hunger.In keeping with his view that programming is a means of teaching generalprinciples of problem solving, Mario stresses analysis over production of endresults. His Scheme course is taught as a science course, not as a computerprogramming course and includes a lab component during which the students carryout formal exercises which involve analysis and explanation of results. The endresult, said Mario, is mostly what's going on [in the student's mind] rather than theWhat Teachers Know about Programming^ 125program. Thus Mario concentrates on design and semantics issues rather than onsyntax. Students, he said, are syntax driven ... therefore it's really important to pullthem off that and say, "That isn't important. I don't care if what you say issyntactically correct. The compiler will, but I don't." ... I want to know whether itcommunicates ... effectively. He expects students to understand in general whatprogram code is doing even if it contains minor bugs.A good teaching day, for Mario, is one during which he is able to communicatethings; during which he has managed to synthesize a bunch of different things atdifferent levels in students' heads, ... not only the language issues, but also designissues, theoretical issues and analytical issues. If classes [go] wrong, that is, ifstudents don't understand how to apply the concepts that Mario has taught, he feelsthat he has done something wrong; that he has not managed ... to do anything morethan give them a bunch of words they could memorize.Mario feels that pedagogically [it is] nonsense to teach subjects such as physics,computer science and english as if they were dead things that one learns so that onecan admire them. Thus in his Scheme course he presents computer science as anevolving organic topic by presenting various paradigmatic models for discussion,evaluation and improvement. Moreover, he feels that it is important for studentsto know that he, as a programming teacher, does not write perfect code and praisesstudents for finding his bugs.When teaching a new language, Mario relates it to languages that the studentsalready know. In his C course, students translate a project they wrote in Smalltalkinto C. In a sense, he said, he is teaching the studentshow to write C as if it were Smalltalk, which is a strange thing towant to do, but what I'm trying to do is give them a really solidbasis in things like ... abstract data types and so on and saying thatWhat Teachers Know about Programming^ 126that comes from the object-oriented programming [they have]already done.Mario's extensive Scheme course outline highlights the sense he has that teachingprogramming is about much more than skills acquisition. The outline includes astatement that harassment is a threat to the principles of "academic freedom, respectfor each other, and equality of opportunity" and "will not be tolerated". Much of thecourse outline deals with study skills issues and Mario said that he spends a fairamount of time discussing study skills (and cheating and plagiarism) and managesthe course so that students are forced to acquire good work habits. For example, todetect people who [are] off track and force them into it, Mario has his students handin preliminary design work, which they must then follow. Laboratory preparationand follow-up force students to preview and review concepts. As well, students areallowed to bring one sheet of paper to exams, which avoids the memorizationMario said occurs with dosed book exams, but forces students to study andsynthesize ideas, which he feels they do not do when preparing for open bookexams.Mario feels that the controversy over the choice of best first programming languageis a tempest in a teapot issue. To him, languages should be chosen in terms of howwell they can be used to illustrate the concepts of a course. He drew an analogybetween teaching programming and teaching physics:If I were asking how I would teach a physics course, my firstquestion would not be, "What type of oscilloscope should I use inthe labs?" I probably wouldn't even say, "Should I use dotnotation or prime notation or d notation to describe thederivatives?" I'd probably say, "What kinds of problems should Ibe investigating? What kinds of analysis should I be showing?"and then the rest of that comes out.He said that one can make arguments either way in a comparison between Pascaland Modula-2, but that people who argue at that level often are teaching theWhat Teachers Know about Programming^ 127language rules rather than teaching people how to use this language effectively toget things going. He uses Scheme in a first course because it has a simple grammar,is highly orthogonal, supports encapsulation and is easy to evaluate. The coursecould have been taught using PROLOG or Smalltalk or ML (afunctional language) or half a dozen languages. ... it probablycouldn't have been taught using Pascal or BASIC or ... C. Thereason for that is that those languages don't treat procedures asdata objects. That's quite necessary to the entire approach thatwe've taken.Although he feels that anybody can learn to use tools like Hypercard, Toolbook andso on, Mario feels that not everyone can go beyond that. He cited Alan Kay'sanalogy of the difference between building a wall and building a Gothic arch. Awall, he said, is easy to build because one can just keep extending it. With a Gothicarch, however, one must plan the whole structure ahead of time and must have agood understanding of the forces involved. To go beyond wall programming, onemust be able to create mental models ... to be able to see things at multiple levels ofabstraction ... and be able to move quickly from one level to another. Programmersmust have certain basic intellectual skills: the ability to solve problems usinganalytical and synthetic thinking. They must be able to make plans and evaluatetheir success.These skills alone will not suffice, however. Mario feels that successfulprogrammers have confidence that they will be able to solve problems and have anattitude that means that they are bothered if something doesn't work. Mariomentioned Seymour Papert's idea of the mathematical way of thinking:Somehow there are people who look at a problem and don'timmediately say "I can't do it." They don't immediately say, "Idon't know where to start." They start somewhere and they worktheir way through until they've got some kind of handle on it andthen they go back and try to introspect what's wrong with it.What Teachers Know about Programming^ 128Mario sees many students in his classes who do not exhibit the traits he feels arenecessary for good programmers. These students have such weak problem analysisskills that they are unable to evaluate the requirements of assignments. Hewondered at the students who come to him shortly before an assignment is due toask, What if we didn't do the project? What if we did something else? He isamazed that students ascribe different meanings to words whose meanings he hasstressed in class. He is surprised that weak students tend not to talk to one anotherand feels that part of the difficulties that students like that suffer ... come from thefact that they're not communicating anything about ... what's going on in their head.Weak students, Mario said, have no feeling that the system should beunderstandable. When something goes wrong, they are concerned not with why itwent wrong, but with what they need to do to fix it and will often try random thingsin an attempt to make bugs disappear. Because these students do not have a well-formed conceptual model and because of lack of confidence, they are afraid to pushtheir model and often become paralyzed when programming.Mario feels that he can get a pretty good sense for who will be a successfulprogrammer in about 15 minutes. In order to do so he would look at the way that[people talk] about their problem solving skills,... whether or not they've got a real conception of what it means toabstract things out and whether or not they've got a conception ofhow to diagnose the difference between expected results and ...attained results and to determine what to do with it. [He wouldalso look at] the way that they describe how they set objectives forthemselves.An Integration of Mario's KnowledgeMario seems to have a strong sense of wanting to understand ... things completelyon an intuitive level. This quest for understanding is echoed in the joy he gets fromWhat Teachers Know about Programming^ 129solving hard problems, in the visceral feel he has for programs and tools and in thetemptation he feels to push things beyond what you're supposed to. In the past,Mario was able to have control of the whole machine. Now, he has a sense ofcontrol of whole programs.Mario's attempts to understand things completely have given him a broad base ofknowledge. He knows many languages and is cognizant of the computer scienceand education literature. His interest in education as well as computer science isdisplayed by the fact that he holds a teaching degree and by his interest in the B.C.Computers in Education Committee. He seems able to see many perspectives, tointegrate various aspects of an issue and to view issues in a broad context. Thus, forexample, he recognizes the fact that professional programmers are strongly shapedby their work environment. He sees students not just as members of a class, but inthe broader context of their lives. He recognizes that while teaching programmingin elementary school may inculcate traits necessary to educated citizens, the need toteach programming may be subordinate to the need to solve deep social problems.In terms of his own class, he recognizes that some students who seem ill-preparedfor his course are in fact not prepared for post-secondary education in general.Mario attempts to situate his own classes within the broad context of students' lives.He sets standards of acceptable behaviour. He teaches not just programming, butstudy skills and analysis techniques. He manages his students' work habits byhaving them hand in preliminary design work, by setting up lab requirements thatrequire preview and review and by using exam mechanisms that encouragestudents to synthesize concepts.Not only does Mario view teaching programming in a broad context, but he alsoattempts to integrate salient issues for his students. He teaches computer science asWhat Teachers Know about Programming^ 130an organic evolving domain and feels that his teaching is successful when he is ableto synthesize for students language, design and analytical issues.Mario categorized the programming languages he knows in terms of usage. To him,languages are tools with which he can meet various ends depending on hisrequirements. They can allow him to feel the thrill and personal joy ofprogramming, they can be used to solve problems and they can be the means bywhich he teaches principles and concepts. Always the underlying principles or usesare more important than implementation details. Thus, when programming,Mario is not frustrated by program bugs. Neither is he concerned with teaching orevaluating program syntax.When selecting a programming language for a project, Mario will choose one whichclosely maps the domain of the problem which he is attempting to solve. Because toMario the solution of the problem is paramount, he is willing to mix languages toachieve the ends he desires.When teaching programming, Mario is also concerned not with the language itself,but with the ways in which he can apply it. He feels that programming can be usedto teach problem solving skills and coping strategies. In his courses, language issecondary to the teaching of object-oriented programming concepts. Thus Mario isnot as concerned with the students' understanding of syntax as he is with theirunderstanding of the underlying principles of the style of programming he isteaching.Mario's comments about the discussion of best first language reiterate his idea thatunderlying principles are more important than surface details. To him, the firstlanguage should be chosen based on the principles of problem solving one isattempting to teach rather than on the syntactical details of specific languages.What Teachers Know about Programming^ 131Although the use to which a language will be put is important, Mario alsorecognizes that it is more pleasant to program in a language which fits one's way ofthinking. It appears that to him there is an integrated relationship betweenprogrammer, language and program. The language structure must have a certainminimum degree of fit, both mentally and to the domain. Given that fit,programmers can shape languages to match their personal styles. The languagesthat Mario likes and uses most often (Scheme, Smalltalk and C++) fit his way ofthinking, allow him to solve the problems he needs to solve and allow him to teachthe concepts he wishes to teach.Mario sees serious tensions in the programming world which seem to emerge fromthe different needs he has when programming. On one hand, programming giveshim a thrill which is increased by the ability to explore the programmingenvironment; to push things. On the other hand, programming is a means ofreaching a goal. These two requirements mean that Mario always feels a tensionbetween wanting to explore and better his environment and wanting to get on withthe job. This tension is seen in the two types of programmers he identifies: thosewho want to explore and push the system and those who are intent on reaching agoal. Mario recognizes that the best programmers are those who can combine thetwo types of personality. Because he thinks that the clever, exploring programmersare the better programmers, though, he seems more apt to bring a sense of disciplineto the clever students he sees than to attempt to help the goal-oriented students tobecome more clever.Communication skills are important to Mario, both in terms of professionalprogrammers and in terms of students. Programmers must be able to communicatetheir solutions to others. Thus part of the lab component of his course involves theexplication of results. On a broader scale, Mario is concerned about weak students'What Teachers Know about Programming^ 132inability to understand course requirements and language and about their ability tobe understood. He feels that these students may be suffering because of theirtendency to not talk to others about what is going on in their head.The means by which Mario predicts success in programming highlight the traits thathe feels good programmers should have: the ability to communicate, to thinkabstractly, to set objectives and to evaluate them. Most importantly, he doesn'tthink that people will be good programmers unless they have that real sense ofwanting to push something to the limits.What Teachers Know about Programming^ 133Clairean instructor, not a programmerClaire and I have been colleagues for a year and a half. Last year, she conducted labsin the Pascal course I was teaching and last term taught the course herself. Clairehas been working at community colleges for approximately six years, primarilyteaching introductory programming courses using Pascal. As well, she has taughtintroductory computing to students who are not specializing in computing andsome second level courses in COBOL, data structures and file structures. Currently,she is teaching BASIC programming to engineering students and is assisting in labsin computer architecture and operating systems concepts courses.Claire began studying programming because she thought it sounded interesting andnew. Growing up in Mauritius she had no exposure to computing, but had heardabout computers and had several friends who had decided to enter the field. Claireobtained a BSc in statistics and computer science in England. Before graduating, shespent a year doing industry research, working in BCPL and FORTRAN. Shereceived her Master's degree in computer science in Calgary and then began teachingin the college system. As Claire told me, she has never worked as a programmer toearn money.Claire has used and taught only procedural languages: PL/I, FORTRAN, COBOL, C,ALGOL, BCPL, assembly language and BASIC. She has had some exposure toModula-2 (a procedural language) and LISP (a functional language), but, as she said,has never had a chance to teach them so does not know them very well.Several times during the course of our interviews Claire asked my opinion aboutquestions I had asked her and often said, That's what I think. I don't know. HerWhat Teachers Know about Programming^ 134responses often ended with the phrase, isn't it? and often began with a restatementof my question. For example:Debbe: If you had infinite resources, ... would you teach itdifferently?Claire: The same course?Debbe: Yeah. Yeah.Claire:^Would I teach it differently? Mmm ...Claire's Knowledge about ProgrammingClaire decided to study computing because it seemed to her to be interesting andbecause friends were studying it, but she did not know what [she] was doing; she didnot understand what programming entailed. Her decision to enter the field wasmade in a way different from most people's, she feels. In Canada today, she said,people have exposure to computing and may have relatives working in the field.They therefore base their decisions on an understanding of computing that she didnot have when she began her studies. At first Claire found her courses somewhatdifficult because she didn't know what to expect and because she was making anadjustment to life in England, but things became easier as she made friends andreceived instructors' help. She said that her interest in computing just grew. Shedecided to concentrate on computing because it was more interesting thanmathematics. She was thinking in terms of jobs ... and also, it was the thing to do.Many of her friends were working in computing and there was more interest in thatfield.To Claire, programming means writing code. It is separate from problem solvingand designing solutions. Claire said that she likes problem solving, but that shedoesn't like programming. She likes the stages ... you go through when solving aWhat Teachers Know about Programming^ 135problem. The languages -- well, yeah, of course, you know, sometimes you like thislanguage, you like the other one, but I think [what is] more interesting is theproblem solving part, don't you think? Debugging is also part of the programmingprocess. When we discussed the possibility of teaching programming to elementaryschool students, Claire revealed some of her thinking about programming. Itappears that to her programming requires the ability to read and spell. Whilepondering the benefits of teaching programming to kindergarten students she said,Can they be taught to write a simple program? To add two numbers or somethinglike that?When she mentioned programs she had written or projects she had worked on,Claire invariably outlined implementation details, rather than programfunctionality. I asked about the topic of her Master's thesis and she replied that itdealt with graphics and database and linking between the two databases. Theindustry research she did involved [looking] at some modules and ... [making] somechanges and [adding] on ... some modules. The last program she wrote -- one thatshe had assigned to students -- was about pointers and used linked lists and queuesand stacks.Claire categorized languages primarily in terms of language structure and syntax.Although she mentioned that COBOL is used for business applications, she also seessimilarities between it and PL/I in terms of data declaration syntax. PL/I is also likePascal: when you program, it's a little bit like Pascal as well, you know the langua --the syntax of the language? Pascal, to Claire, is similar to both ALGOL and C. Shefound Pascal easy to learn once she had learned ALGOL, because the languages arevery similar ... structure-wise. Pascal is like C because what you can do in Pascal, ...you can do that in C^... loops, ... pointers, ... if statements, ... selection, branchingand all, ... you can still do that in C^I think of C as just being another language.What Teachers Know about Programming 136Although Pascal and C are similar, Claire also grouped C with assembly languageand BCPL, because all three languages allow the programmer to get close to thesystem.To Claire, LISP is very different from the other languages with which she is familiar.Claire:^When I look at LISP, ... it's a language ... for listprocessing more and ... it looks, when I look at it I say,oh, that's LISP ... it's so different from the other ones.Debbe: Yeah.Claire:^You know, all these brackets.Debbe: OK. So the way it looks is different.Claire:^Yeah -- the syntax.Claire placed both BASIC and FORTRAN in categories of their own: FORTRANbecause it is a scientific language and BASIC because it is easy to learn.Claire's favourite languages are Pascal and C. She likes C because you can get a littlebit closer to the system. ... it allows you to do new things. Pascal is good ... as a firstlanguage in an educational environment. COBOL is Claire's least favouritelanguage, although she found it easy to learn. Its syntax is very different fromPascal's in that it consists of a lot of words. The structure is different, isn't it?, shesaid. The sections, paragraphs and wordiness of COBOL, she thinks, make itdifferent from other langUages.Claire said that when she is programming she tends to think in terms of [Pascal]structure, perhaps because of her extensive experience teaching Pascal. To her itdoes not feel different to code in different languages. When I asked her to tell mehow she would code in C a process to find the length of a string, her response wasvery procedural: In a loop you would check ... until you find ... you test for that nullWhat Teachers Know about Programming^ 137character, so if you haven't found it, you increment, keep going. Claire finds theBASIC that she is teaching limited because it has no while, else or nested ifconstructs. She said that she is not judging BASIC based on the capabilities of Pascalhowever, but based on previous versions of BASIC that she has learned.To Claire, a good programmer is somebody who can think and write code; somebodywho ... has some methodology, ... knows ... how to go about doing things in asystematic order, who can actually translate ... the ideas into code. ... and somebodywho knows how to communicate with people as well. ... it's not just writing code. Aprogrammer sits in front of a computer all day surrounded by computer printouts.She said, his job is to write programs to get something to work. Am I right? I don'tknow.Claire feels that there are two distinct types of programmers: systems programmersand applications programmers. One of her brothers is a systems programmer andone an applications programmer. To her, systems programmers have the moreinteresting job. She said that being a systems programmer would be like being agrad student in that one would be constantly learning new things. The systemsprogrammer makes sure that everything is running smoothly and is like a doctorwho must diagnose the system. Application programmers, on the other hand, aremore concerned with programming languages and what code they are going towrite. They get specifications and instructions from higher ups, they domaintenance, fix bugs and test code using languages like COBOL to writeapplications like accounts receivable and accounts payable. Their code deals withprinting reports, updating files and prices of products. Although she says that herbrother likes applications programming, she also mentioned that that's the job thathe gets ... because he can't get any better.What Teachers Know about Programming^ 138Claire's Knowledge about Teaching ProgrammingClaire has wanted to teach since she was in university. She laughed as she said, Iremember after graduation I told everybody, "I'm going to become a teacher". Nowshe says that when people ask, I don't say I'm a computer programmer. I say I'm aninstructor. Claire likes teaching. I don't know why I teach, she said, but I liketeaching. She likes being with people and seeing students make progress. Shereceives satisfaction from seeing them succeed in understanding an idea or finding abug with her help. She likes to hear them say, oh, thank you [Claire] ... this is easy.She also likes seeing students after they have finished her classes. She said, Now Iget to see students from last year. You know, the ones that were doing Pascal ...? andnamed several students who were in our class last year. Claire feels that she has thepatience necessary to be a good teacher. I can teach the same thing many manytimes to the same person, she said.Claire likes preparing for classes, particularly for ones which she has not taughtbefore. Although it's very challenging and could also be scary, she likes thepreparation because it gives her an opportunity to learn new things or things thatshe has forgotten. Despite the fact that Claire does not like the volume of markingthat she does, she feels that it is good feedback for her and for the students. Seeinghow they are doing, she said, is how they will learn. Claire also does not like havingto put up with a student like A, a student who has, she said, a complaining attitudeand who makes her feel stupid in front of the whole class. She feels that if she wereolder, she would be better able to deal with this student, who is many years olderthan she is.Claire appears to be very concerned about students. When I asked her to explainsome code to me as though I were a student, she spent a long time asking about theWhat Teachers Know about Programming^ 139'student's' background and understanding before she explained the code. She saidthat the explanation would depend on what the student was comfortable with: So,if it's the language that's a problem, so then maybe I would explain ... the language.If it's not, it's just ... what the program does ... overall. Claire is also aware ofstudents' concerns. She said that it would be better if the students' workload werenot so heavy so that they would have more time to devote to programming.Claire's outline for the Pascal course is the same one that I used, with very minorchanges. If more time were allotted for the course, she said, she would introduceadditional topics, like graphics, because people ... tend to like ... pictures on thescreen and they like to know how to [create them].Although she is unsure, Claire feels that it may be a good idea to teachprogramming to elementary school students in order to expose them to thetechnology and its applications and to the idea that programs are required to makecomputers work. Young children are interested in computers, she said, and many ofthem could learn how to program. Because the people that she teaches have alreadybeen exposed to computers and have some programming experience though, shefeels that the purpose for which she teaches is different.Claire:^... the purpose would be ... to still teach them how towrite good programs ... how to solve a problem and howto ... from there write a good program.Debbe: And for what purpose? Why would you be teachingthem to write programs?Claire: I don't know. If they want to solve a problem ... usingthe computer, OK, so to show them ... the way to do it.Claire mentioned that she is not sure why her engineering students are learningBASIC on their hand-held computers: well, maybe because in case they have to ...What Teachers Know about Programming^ 140solve a problem in BASIC so you can just do it right away. Claire agreed with mysuggestion that perhaps the students would need to use programs on the job.Claire appears to see programs in terms of their modular structure. Whenexplaining code to me she first explained the modular structure, drawing a diagramto illustrate the program hierarchy, and then explained each function and procedurecall in detail. As she described the workings of each line of code, she also explainedthe theory behind it. For example, when explaining a particular function she saidshe would step through this and explain what this is doing ... and how it relates ... tothe complete rest of the program. ... that's a function ... now at this point [I would]explain again what's the difference between a function and a procedure. As shewent through the program, she also stressed the importance of internaldocumentation and meaningful variable names.When I asked if she tries to impart a particular image to her students, Claire repliedthat she reminds them that they have to become good programmers; that they haveto have this attitude. In particular, programmers must have patience when solvinga problem or finding a bug. Claire feels that students have particular problems withspecific structured data types. Pointers are difficult, she said, and the students getlost. Claire draws diagrams to help the students understand pointers and datastructures such as trees that are based on them. As well, a lot of students find[arrays] difficult to understand at first ... it is too abstract to them or something.Pascal is Claire's favourite language to teach and she thinks it is the best language toteach first to students. Pascal is easy to learn and is a good introduction to structuresand modular programs. It is a good tool for teaching programming techniques andconcepts. Although she likes Pascal, Claire would like to have an opportunity toteach C as the first language at the college level, particularly because many of herWhat Teachers Know about Programming^ 141students already know BASIC or Pascal. She does not know whether C would bebetter, but said, maybe we should try and teach C and see and compare.Claire feels that programming is like any other subject in the sense that somestudents succeed at it and some do not. Anybody with motivation and interest canlearn how to program, but some are better at it than others. Some are be able to ...think ... more quickly or have better ideas when it comes to designing programs.Success in programming does not depend on age or computer exposure. However,Claire feels that very young children, because they cannot read or spell or add,cannot learn to program. Claire thinks that other factors, such as being away fromhome or returning to school after many years away, will affect how well studentssucceed in post-secondary courses. She does not feel that she can predict students'success, but judges how well they are doing based on feedback she receives in thefirst two or three weeks of class. She measures their progress by marking theirassignments, by looking at the work they do in labs and by listening to the questionsthey ask to see whether those questions ... should have answers that they shouldalready know.An Integration of Claire's KnowledgeClaire has never worked as a professional programmer. Her educational experienceseems to shape the way she thinks about programming. Claire likes learning. Shesaid that she enjoys preparing for new courses because it allows her to learn newthings. As well, she is drawn to systems programming in part because it is like beinga grad student. Systems programming also involves problem solving, which iswhat Claire likes about programming. She dislikes writing program code, which, inher perception, is what an applications programmer is most concerned with.What Teachers Know about Programming^ 142To Claire, programming is like any other subject in that anyone can learn how to doit. Some students will be quicker and able to think of better program design, butClaire's sense of programming as a subject to be learned appears to be echoed in herimpression that anyone who is motivated can learn it. Claire's ability to predict whowill be a good programmer is based solely on their performance in her classes. Hersense of programming as a subject is further evidenced by her feelings about why itshould be taught. She does not have a strong sense of the purposes to whichstudents might put their programming knowledge. Rather she sees programmingbeing taught in case [students] have to solve a problem ... using the computer.Neither does Claire explain her own programming experience in terms of itspurpose, but rather in terms of language implementation details.Claire concentrates on the syntax and structure of programming languages. She hasprimarily taught Pascal and all the languages with which she is familiar areprocedural. Claire's coding and teaching make evident this background. She saidthat she tends to code in a Pascal style and during our interview her explanationsand descriptions were strongly procedural. Claire categorizes languages by theirstructure and syntax and judges them based on these attributes. Her sense ofprogramming as a very syntax-based activity is echoed in her feeling that youngchildren cannot be taught to program because they cannot read or spell.Furthermore, her idea of a simple program that they might be asked to code appearsto reflect her sense of what programming is about: Can they be taught to write asimple program? To add two numbers or something like that?Claire sees programs in terms of their modular structure -- she describes programsby drawing Module Hierarchy Diagrams and explains them in a top-down fashion,moving from main logic to details of subroutines and then to specific lines of code.Good documentation is also important to Claire. Thus she takes an expert approachWhat Teachers Know about Programming^ 143to teaching programming. Pascal is a good first language because it allows Claire toteach the aspects of programming that are important to her: structure andmodularity. Typical student problems that Claire cites relate to data structures or tooverall program hierarchy. Her musings about teaching C seem to highlight acuriosity based on the sense she has that C is just another language.To Claire, programming is writing code. Thus a good programmer is one who cantranslate ideas into code. As well, a good programmer does things in a systematicorder. Claire feels that both good programmers and good teachers need patience andthat an important trait of a good programmer is the ability to communicate wellwith others.Interaction with other people seems important to Claire. She learned programmingbecause others had done so. She found it hard to adjust to university, but otherstudents and teachers made the transition easier. Her decision to concentrate oncomputing rather than on math was made partly because of the influence of herfriends. Claire said that she might think differently about programming if she wereexposed to different groups of students. The influence that others have on Claire isevident in her language, which is filled with you know and isn't it? and in the factthat despite having taught Pascal many times in the past, she did not make changesin the course outline which had been used the year before.Claire likes teaching because she likes being with people. She enjoys seeing studentsfrom previous classes and is affected by student attitudes. Students' needs anddesires are important to Claire. She feels satisfaction when she sees them succeedand recognizes that outside factors influence that success. She is concerned aboutdetermining what students' background and levels of understanding are. SheWhat Teachers Know about Programming^ 144dislikes marking, but recognizes that it is useful to students. As well, she wouldchange her course, if she could, to add topics, such as graphics, that students enjoy.Claire's perception of programming appears to be strongly affected by hereducational experience and by the fact that she teaches mainly first term courses.She seems to judge programming and programming languages based on therequirements of first term students. Her perspectives make it clear that Claire is aninstructor, not a programmer.What Teachers Know about Programming^ 145CHAPTER FIVEDISCUSSION OF THE RESEARCH RESULTSIntroductionThat qualitative research involves hypothesis generation rather than hypothesistesting (Spector, 1984; Jacob, 1988; Lincoln and Guba, 1985; Glaser and Strauss, 1967)became apparent as this study unfolded. At the outset, the goal of the study was toinvestigate two questions: How do teachers organize their knowledge aboutprogramming? and How do teachers' constructions about programming integratewith their constructions about teaching programming? As the data was collectedand the analysis began, though, it became clear that it was impossible to investigatethe second question, which deals with integration, without also investigating theways in which teachers organize their knowledge about teaching programming.Thus a third research question: How do teachers organize their knowledge aboutteaching programming? was generated and the results of the interviews werereported in the form of responses to three research questions.As the results of the interviews were described, however, it became difficult toseparate the respondents' perceptions of programming from their perceptions ofteaching programming. Issues described under the heading "Knowledge aboutProgramming" (programmers' attributes, for example) reappeared under theheading "Knowledge about Teaching Programming". The two knowledge domainsseem to be intertwined and it appears that they are constructed within the sameconceptual frameworks. Furthermore, although in some instances it was temptingto infer causality in the relationships among emerging themes, for the most part thethemes were interconnected; the links of influence among them multi-directional.What Teachers Know about Programming^ 146When it came time to analyse patterns across respondents, I had a strong sense thatto separate the analysis into two sections -- one an investigation of knowledge aboutprogramming and the other an investigation of knowledge about teachingprogramming -- would be artificial and detrimental. As Stake (1978) says, "truth inthe fields of human affairs" (p. 6) is approximated by using "statements that are richwith the sense of human encounter" (p. 6). The results of this study indicate that inorder to arrive at an approximation of "truth" in the field of computer education,teachers' constructions about programming and about teaching programming mustbe examined within the same frameworks. It appears that the question is not Howdo teachers' constructions about programming integrate with their constructionsabout teaching programming?, but rather, Within what frameworks do teachersconstruct their knowledge about programming and teaching programming?This chapter examines the data from this more integrated perspective by means of adiscussion of five conceptual frameworks within which the respondents appear toconstruct their knowledge about programming and teaching programming:1. life experience,2. social context,3. desire for control,4. paradigm experience, and5. mental programming models.Conclusions drawn from the discussion are then summarized and the limitationsand implications of the study are outlined.What Teachers Know about Programming^ 147Conceptual FrameworksLife ExperienceThe respondents' academic and industry backgrounds are varied. Table 3 displaystheir life experience and their ideas about the reasons for which programming istaught.Table 3Respondents' Life ExperienceWhyProgrammingis TaughtRespondentWorkExperienceAcademicTrainingTeachingExperienceHowProgrammingwas LearnedMelissa < 5 years college,university> 10 years academic,self-taughtClaire none post-graduatecomputing6 years academicIsaac > 5 years part-timecollege> 10 years self-taughtJames > 5 years post-graduate > 10 years self-taughtLorne > 5 years no computing,some teachertraining> 10 years,part-timeself-taughtKyle > 5 years college,university> 10 years,part-timeacademicMario < 5 years post-graduatecomputing,teachertraining> 10 years academicRoss > 5 years post-graduatecomputing> 10 yearsas a subjectjob trainingjob trainingjob trainingjob trainingliberal artWhat Teachers Know about Programming^ 148Two of the respondents, James and Lorne, learned programming solely in theworkplace. Isaac too has a strong industry background, but has also taken manycomputing courses on a part-time basis. The other respondents have formalcomputer training, either at university or college. Melissa and Kyle studied at bothcollege and university and Claire, Mario and Ross have done post-graduate work.Claire alone has no industry experience. She also has the least amount of teachingexperience of the respondents. Claire has been teaching for six years, whereas eachof the others has been teaching for over ten years. All of the respondents but Kyleand Lorne are full-time teachers. Mario, Melissa, Lorne and Claire appear to have astrong interest in teaching as a profession. Claire said that she has always wanted toteach and Melissa reminded me that she teaches everything [she learns] how to do.Both Mario and Lorne have professional teacher training and Mario taught forsome time in the elementary school system.The respondents' experiences form a framework within which they construct theirknowledge about programming languages and the ways in which students learnthem. Claire's strong academic background is evident in her perception of herself asan instructor, not a programmer. She views programming and languages withinthe context of students' requirements. To her, programming is a subject. James' andLorne's extensive industry experience contributes strongly to their perceptions.Both categorize languages in terms of the applications for which they are used andboth feel that students learn by experience. As teachers, they act as colleagues totheir students, preferring the discovery mode of learning to the lecture mode.Furthermore, Lorne's emphasis on students' need for human, computer-based andprint-based resources when learning computing echoes the way in which he learnedto program. Isaac, who learned programming in the trenches, feels strongly thatstudents learn programming through practice, practice, practice. Nonetheless, Isaac,What Teachers Know about Programming^ 149along with Melissa, Claire, Kyle and Mario, uses lecture mode when teaching. Sincethis is the standard mode of instruction at their schools, though, it is not possible tojudge whether or not this is a personal preference.Industry and academic background appears to have contributed greatly to therespondents' views about the purpose of teaching programming. Claire, whoseexposure to programming is purely academic, and who learned programmingbecause it was the thing to do, seems to feel that programming should be taughtsolely in the event that students have to solve a problem ... using the computer.She did not offer examples of ways in which they might apply their programmingknowledge. Isaac, Lorne and Kyle, who have extensive industry experience, allsuggested that they teach programming for industry training. James, who learnedprogramming in order to solve problems on the job, teaches programming as ameans to an end -- not for the training of programmers per se, but in order to helpanalysts solve problems. Mario's teaching education and experience appear to shapehis view that programming should be taught as a liberal art.The recency of the respondents' experiences also contributes to their perceptions oflanguages. Those that programmed some time ago in a language with which theyno longer work seem to have what Mario called a mental model of the languagethat may not match its current implementation. Thus Lorne's and Melissa's viewsof BASIC, Mario's view of FORTRAN and Ross's view of COBOL are based on theirviews of the languages as they were implemented in the past and may be whatMario called emotional reactions to languages based on dated perceptions.Several of the respondents expressed views about the future of the computerindustry which appear to be shaped by their experiences with that industry.Although Isaac sees the need for fewer programmers in the future becauseWhat Teachers Know about Programming^ 150development systems are becoming more intelligent, he feels that most industryprogramming is still done in the procedural style. Both Lorne and Kyle feel that theindustry is shifting toward an object-oriented paradigm whereas Ross feels thatlanguages are [evolving] more and more towards a LISP-like model. These differingviews of the industry are reflected in the respondents' views about choice ofteaching language. Isaac teaches procedural languages, Lorne and Kyle teachSmalltalk, an object-oriented language, and Ross teaches LISP. Each of the fourexpressed the opinion that students' professional careers would benefit fromknowledge of the language he teaches.Thus the respondents' academic and industry experiences help shape their viewsabout the programming industry, programming languages, the ways in whichstudents learn programming and the reasons for which it should be taught.Social ContextThe respondents differ in terms of the social contexts within which they framedtheir interview responses. The views of Kyle, Mario and Claire, in particular,appear to be strongly linked to personal, interpersonal and societal concerns. Theother respondents did not express strong views in these areas.Much of Kyle's discussion was framed in the context of the importance of achievinga balance emotionally, mentally, and spiritually in life. This quest for balanceappears to contribute to his view that programming is just one aspect of life, whichsometimes threatens to outweigh other aspects. It informs his description ofprogramming as an engenderment of creativity, practicality, intellectual stimulationand aesthetic beauty, an image which he attempts to convey to his students. Aswell, the broad context within which he views people's lives shapes his sense thatWhat Teachers Know about Programming^ 151programmers' attributes are just one aspect of their characters and that his course isjust one aspect of students' workload.Mario also appears to view programming and teaching within a broad context,although his perspective appears to be more societal than Kyle's. He teaches notprogramming, but general principles about problem solving that an educated citizenin our society ought to have. His course [interacts] with the rest of what makes[students] competent and is presented in such a way as to establish social andeducational behavioural expectations. He views people within a broad socialcontext: recognizing that professional programmers are shaped by the environmentin which they work; realizing that students who have trouble in his class may be ill-prepared for university in general; and questioning the importance of teachingprogramming in elementary schools when students have serious social problemswith which to contend. As well, the reasons for which Mario selects languages withwhich to perform specific tasks are framed within the context of the environment inwhich programs will be used and maintained.Claire's views appear to be framed within the context of personal interaction. She isaware of the broad context of students' concerns, attitudes and desires. As well, herimpressions of different kinds of programmers are shaped by her perception of herbrothers' jobs. Claire's concentration on teaching first year courses and the fact thatshe has never programmed professionally seem to have strongly shaped herperceptions about programming in general. She said that she might thinkdifferently about programming if she were exposed to different groups of students.As it is, she categorizes programs as a first year student might: in terms of syntaxand structure.What Teachers Know about Programming^ 152Thus it appears that for some programming teachers, discussions of programmingand teaching programming are firmly situated within a social context.Desire for ControlThe ways in which the respondents deal with control appear to shape the ways inwhich they view programming and the teaching of programming. Of all therespondents, Melissa seems to have the strongest desire for control. She likesprogramming, as she likes flying and motorcycle riding, because it gives her controlof machinery. Her favourite language is assembly language because it gives her afeeling of control over low-level machine functions. That to Melissa programmingis a means of controlling is further demonstrated by her sense that computing can bedemystified by giving students a degree of control through programming. Teachingalso gives her a sense of control; She enjoys having people listen to her. As well,Melissa's desire for control shapes the way in which she teaches. She feels thatteachers have a strong influence over students. Melissa's students submitpreliminary design work so that she can streamline their logic. She feels thatteachers can influence students' feelings about programming languages bydisplaying their personal biases about particular languages.To a lesser degree, Mario, Ross, Kyle and James are also concerned with control.Mario said that when he first began programming it was very easy to write aprogram that would take over the whole machine. He liked the sense of control hehad when he could push things to their limits. Now he likes to feel that he hascontrol over his programming environment. Furthermore, he feels that goodprogrammers are those who want to explore the boundaries of the system andcontrol their working environment. In his courses, Mario goes beyond the teachingof programming by attempting to give his students not only educational, but alsoWhat Teachers Know about Programming^ 153ethical guidelines. His course outline dearly delineates the boundaries withinwhich he expects his students to behave.Ross also spoke about the sense of control programming gives him. He said thatwhereas he used to enjoy having control at the assembly language level, he nowwants to exert control by changing the behaviour of the inference engine. Whenusing LISP, he said, he is not a slave to the tool, as he was when using COBOL andother block-structured languages. He dislikes Smalltalk and PROLOG in partbecause he cannot control them to the extent that he would like. In the classroom,Ross exerts a subtle kind of control. He guides students into LISP-world by pullingstrings and pushing buttons and teaches students his techniques by showing themhow to give prospective employers little tempting nibbles and then withhold.Through programming Kyle feels that he can manipulate the world. This sense ofcontrol over malleable software objects, Kyle said, sometimes spills over into theworld of physical objects and interpersonal relationships. Kyle contends thatattempts to control people in the way that he controls software objects represent apsychological defect which he tries to rise above. Nonetheless, Kyle has strongopinions about students' motivations and the ways in which learning takes placeand appears to feel that in some cases he should be able to influence others to dothings the right way. For example, he says that the conditioning that causes somestudents to be inhibited about learning in an active way should ideally be broken.James categorizes languages partially in terms of their power and likes C and C++because they are powerful languages. When programming, James enjoys a feelingof power over [the] machine, but also says that programming allows him to tap intothe power of the computer. Thus there is a sense of a sharing of power. ThisWhat Teachers Know about Programming^ 154complementary relationship is echoed in the classroom as James works together inthe lab with his students, trying out new things depending on what happens.Isaac is very concerned with discipline. Programmers need to be disciplined, hefeels, and his favourite languages are those that impose discipline on theprogrammer. Although he says that programming teachers are just guides, Isaacimposes strict discipline on his students. He forces students to write code in aparticular style and attempts to constrain them through his project specifications.As well, in his note to me he expressed the feeling that structured programmingstyle "must be hammered repeatedly". It appears that for Isaac, programming is bestdone when the programmer does not have control over every aspect of theprogramming environment, but rather when the programmer is constrained by theenvironment. In the same way, learning happens best when students areconstrained by the teacher.The ways in which the respondents exert control and are controlled, then, appear toplay important roles in shaping their programming and teaching styles.Paradigm ExperienceAlthough each of the respondents' first language was procedural, they varymarkedly in terms of the breadth of their experience with other programmingparadigms. Figure 4 displays the language paradigms with which each respondent isfamiliar in a form that gives some sense of the breadth of their knowledge.What Teachers Know about Programming^ 155ParadigmObject-Logic^Functional Procedural OrientedRespondentMelissaClaireIsaacJamesLorneKyleMarioRossFigure 4. Breadth of Respondents' Paradigm ExperienceAs Isaac pointed out when I asked him about the languages he knows, there is'know' and there is 'know'. In Figure 4, solid rectangles mean that the respondents'know' a paradigm in the sense that they have worked with it and feel that theyunderstand its attributes. Shaded rectangles mean that the respondents have hadsome exposure to a paradigm, but do not claim a strong understanding of it.Melissa's and Claire's experience has been procedural, although Claire has had someexposure to LISP. Isaac too has programmed extensively in the proceduralparadigm, with a brief introduction to Logic and Functional programming withPROLOG and LISP and some exposure to the object-oriented languages Smalltalkand C++. James, with a procedural background and some exposure to PROLOG,now uses C++, in the object-oriented paradigm, extensively. The remainingrespondents, Lorne, Kyle, Mario and Ross, have experience in all four paradigms.What Teachers Know about Programming^ 156The breadth of the respondents' paradigm experience appears to contribute stronglyto the perspective from which they view programming. Melissa, who knows onlyprocedural languages, said that one procedural language is ... like another. To her,programs are linear and sequential in nature and she differentiates between them interms of level of detail. Similarly, Claire's discussion of language categories wasnotable for the similarities rather than for the differences she perceived betweenlanguages. To her, LISP is different from other languages not because it is based in adifferent paradigm, but because of its syntax. Isaac, who has limited experience withnon-procedural languages, differentiates between paradigms, but his discussion ofprocedural languages was much more specific and detailed than his discussion ofthe other paradigms. James, who has recently shifted to the object-orientedparadigm, did not categorize languages on the basis of paradigm. However, he sees astrong difference between object-oriented programming and proceduralprogramming. Lorne, Kyle, Mario and Ross, in contrast to the other respondents,were able to categorize languages within the broad context of the paradigms withwhich they are familiar. All of them compared and contrasted the various languageparadigms and Kyle even added two paradigms of his own definition.All respondents but Melissa and Claire feel that programmers favour languages thatfit the way they think. As Isaac mentioned, one is able to choose a language that fitsone's way of thinking only if one is good at many different languages. Lorne, Kyle,Mario and Ross seem to be able to choose their languages, each preferring toprogram in and teach a paradigm with which he is comfortable. It appears thatbecause of their broad base of experience each is able to select particular languages forparticular tasks. Furthermore, Lorne and Mario described the ways in which theysometimes mix languages from disparate paradigms. Ross, Kyle and Mariomentioned not liking to work with certain languages that they have to fight; that getWhat Teachers Know about Programming^ 157in the way. The other respondents are more restricted in their choices. Melissa,Claire and Isaac teach the procedural paradigm, with which they are familiar, andJames encourages his students to use C++, although they are free to use either C++,an object-oriented language, or C, a procedural language, in his courses.Almost all of the respondents use an expert approach to teaching programming, inthe sense that they expect their students to solve programs in the way that expertsdo. Because they are teaching various paradigms, though, the expert approach thatthey are using may differ from the classic definition, which involves the use of the'stepwise refinement' model. Melissa, Claire and Isaac, strong proceduralprogrammers, do expect their students to use top-down structured programmingmethods. Kyle, James and Ross, on the other hand, expect students to use themethods that an expert object-oriented programmer or an expert functionalprogrammer would use.All of the respondents feel that programming in a particular language shapes one'sway of thinking. Melissa, Lorne, Kyle and Ross each gave examples of situations inwhich they or their students wrote code based on the style of another language. Kyledescribed forcing a procedural solution into an object-oriented language and Rossremembered how design methodologies [spilled] over from the [procedural]paradigm to LISP. Melissa stressed that, although both are procedural languages, toprogram in PL/I students must lose the old COBOL restrictions and Lorne describedhaving to make his thinking change to fit a new language. Isaac might have beenspeaking for all the respondents when he described the sense he has about the wayin which languages shape our thoughts:We and hundreds of others like us have trained our minds tothink of problem solutions based in a certain way of doing things,so suddenly having to solve a problem in a way that's foreign toWhat Teachers Know about Programming^ 158us is going to be very difficult. Which obviously lends strength to'we think in the way that our languages deal with problems'.Because of their strong sense that languages shape the way in which programmersthink, the respondents were very adamant about the importance of a student's firstlanguage. In particular, the respondents that have extensive experience in morethan one paradigm pointed out the difficulty involved in shifting from oneparadigm to another. They see the paradigms as very different and feel that the shiftrequires a radical change of thinking, as Lorne said.The respondents themselves found the shift hard. Several of them spoke abouttheir tendency to drop out of the new paradigm back to the procedural way ofthinking. They feel that students find the shift difficult also. Ross said that he seesstudents being dropped rather cold into a shocking new paradigm. Kyle spoke aboutstudents being tainted by the limitations of procedural languages and James said thatteaching procedural languages first puts blinkers on the students. Both Ross andKyle stated that when teaching students they try to expand their horizons in termsof language and uses of computers in general.The respondents use various techniques to make the shift easier for their students.Kyle tries to avoid overwhelming students with too many new concepts by makinghis first assignment a familiar procedural problem that the students solve in anobject-oriented way. Lorne suggested the use of C++, an object-oriented extension ofa procedural language, as a gradual way to introduce the paradigm shift, whichwould allow the teacher to be subtle about the changeover. Ross gives his studentstempting little tasks ... where it would feel artificial to program in the style of theprocedural paradigm. Although the respondents feel that programming in theprocedural paradigm is vastly different from programming in other paradigms, Rossalone expressed the opinion that different students do well in different styles ofWhat Teachers Know about Programming^ 159programming. As he said, the students who catch on to LISP are a much differentcategory of programmers from those who do not.It appears, then, that the breadth of the respondents' paradigm experience shapes theways in which they perceive and teach languages. Those with broader experiencechoose and teach languages that fit their thinking styles. The importance of the firstlanguage, recognized by all respondents, is felt keenly by those with broaderexperience, who are attempting to educe from students a shift to a new paradigm.Level of Mental ModelDuring our discussions, Kyle and Mario alluded to the mental or conceptual modelsof programming being used by programmers. Melissa, James, Mario and Lornepointed out that programmers need to be able to think at varying levels ofabstraction. As James put it, programming requires a strange mix ... of someonewho thinks broadly and at the same time can implement those broad thoughtsthrough the details of a program. Although it appears that programmers, as Mariosaid, must be able to see things at multiple levels of abstraction, each respondenttends to concentrate on a particular level. It is possible to place the respondents on ascale that represents the level of abstraction of their mental models ofprogramming.The scale in Figure 5 ranks programmers' mental models from the concrete to theabstract. At the concrete end of the scale is a model based on the machine itself. Atthe abstract end is a model based on the programmer's imagination. Between themlie models based on the structure of programs, the programming environment (i.e.,the tools and systems that interact to form the programmer's 'workbench'), thephysical world and a model based on a mental conceptualization of the physicalworld. A model of the physical world differs from a model based on aWhat Teachers Know about Programming^ 160conceptualization of the physical world in the following sense: respondents placedon the scale at the Physical World position stated that when programming they areconstructing models of the world. Those respondents placed on the scale at theConceptual World position talked about modeling people's conceptual models ofthe physical world.RespondentMelissaClaireIsaacJamesLorne ^KyleMarioRossMachine^Program^Programming^Physical^Conceptual ImaginationStructure^Environment^World WorldConcrete AbstractLevel of ModelFigure 5. Respondents' mental modelsRespondents' locations on the scale are represented by dark rectangles. Theserectangles position the respondents in terms of the entity they appear to bemodeling when they are writing a program. This position represents a tendencyonly since most of the respondents appear able to create models at different levels.A black line represents the range of models that each respondent tends to use.II 161What TeachersTeachers Know about ProgrammingRespondents were placed on the scale based on the way in which they talked aboutprogramming. The metaphors they used when describing programming oftenoffered useful insights into their conceptualizations. Melissa, for example, said thatwhen programming, she picture[s] things physically happening as a result ofprogram instructions. Her metaphors were very physical and were accompanied bydistinct hand motions. Although Melissa seems typically to create mentalrepresentations of the physical machine when she is programming, she also appearsto have a mental model of program structure. For example, she talked about gettinga building block of code to plug into her program.Thus Figure 5 illustrates that Melissa typically models the physical machine, but alsocreates mental representations of program structure. It appears that Claire typicallymodels the structure of the program that she is writing. To her, programming iswriting code. Her descriptions of the programs on which she has worked weredescriptions not of function, but of implementation details. Isaac seems toconcentrate on the level of the programming environment. To him, programminginvolves working with complex systems in which many of the parts interact,assimilating a large number of details and tying all the pieces together. AlthoughIsaac typically concentrates on the programming environment, he also at timesshowed evidence of thinking about both real world problems and the more concreteaspects of programming -- the program structure and the physical machine.James and Lorne, it seems, tend to concentrate on modeling the physical world. ToJames, physical world models are important, not code. He appears as well to havestrong models of programming environments and program structure as evidencedby the way in which he explained code to me first in terms of its broad structure andthen in terms of specific details. Lorne said that using the object-oriented approachallows him to think about real world objects, their attributes and behaviours. HeWhat Teachers Know about Programming^ 162also appears concerned, however, with more concrete aspects of programming. Thepicture he drew to illustrate a Smalltalk program shows his ability to representprogram structure and the programming environment. As well, he feels stronglythat programmers need an understanding of low-level machine details.Kyle and Mario appear to model not just the physical world, but humanconceptualizations of the physical world. Kyle said that the object-orientedparadigm reflects the ways in which people think about the world. Mario modelsthe principles or concepts that he wishes to teach or investigate. He also talkedabout modeling the problem space. Whereas Kyle is not interested in models of amore concrete nature, Mario appears to use many levels of model, from thestructure of a program to the physical world. He talked about having a visceral feelfor programs and the programming environment.Ross also seems to be modeling a mental construction, but where Kyle and Marioare modeling conceptions based on the physical world, Ross is modelingconceptions that come out of the air; out of his imagination. He models at moreconcrete levels as well. Although he used to be interested in low-level machinedetails, he is now more interested in modeling the LISP environment.Table 4 compares the respondents' preferred mental models to their views regardingaspects of programming and teaching programming.What Teachers Know about Programming^ 163Table 4The Relationship of Mental Model to Respondents' ViewsHow^ BestMental^Preferred^Teaching^Languages are Programmer FirstModel Paradigm Models^Categorized Attributes^LanguageRespondentMelissaClairemachineprogramstructureprocedural machineprocedural programstructureease ofmanipulationstructure andsyntaxlogical,^assemblypatient, cansee detailsgood coder, Pascalpatient,systematicIsaac^programming procedural details and paradigm^can grasp^Pascalenvironment^patterns^detail,creativeuseJamesLornephysicalworldphysicalworldobject-^varyingoriented^levelsindependent,can see bigpicturecan break^assemblysystem down,can seemulti-levels,creativeobject-^physical^useoriented^worldand programdetailsKyle^conceptual^object-^paradigm^analytical, Smalltalkworld^oriented, abstract,AI systematic,creativeMario^conceptual^object-^use^analytical,world^oriented, abstract,AI can seemulti-levelsRoss^imagination functional,^LISP vs other abstractAI^ patternmatching,creativeWhat Teachers Know about Programming^ 164It is striking that the respondents' mental models appear to correspond, with someoverlap, to the programming paradigms that they prefer. Melissa, Claire and Isaac,who tend to model at more concrete levels, are all procedural programmers. Lorne,Kyle, Mario and Ross, at the abstract end of the scale, like languages like LISP,Scheme and PROLOG, used in the field of artificial intelligence. Those in themiddle, overlapping the previous grouping — Mario, Kyle, Lorne and James -- likethe object-oriented languages Smalltalk and C++. Isaac too is beginning to shifttoward that paradigm. This analysis of the respondents' mental models leads to are-examination of the role of programming paradigms. Did the respondents choosethe language paradigms they prefer because of innate mental models, or has the useof a particular paradigm shaped the ways in which they conceptualize the act ofprogramming? As mentioned in the discussion of programming paradigm, most ofthe respondents feel that both principles are true. All of them feel thatprogramming in a particular language or paradigm shapes one's way of thinking.However a wide breadth of experience allows programmers to choose languages thatfit the way they think.It appears that the respondents' preferred mental models shape many aspects oftheir thinking about programming and teaching programming. The models thatthe respondents use when teaching naturally tend to match the level at which theyare modeling programming. Thus Melissa draws pictures of storage locations inorder to help her students understand programming. Claire, when explaining aprogram to me, drew a module hierarchy diagram, which shows the relationshipsbetween modules in a program's structure. Isaac models programming by describingthe detailed syntax and semantics of languages, and by helping students understandexisting algorithms so they can build on them. James presents various mentalmodels to his students: beginning with the most conceptual level, the function of aWhat Teachers Know about Programming^ 165program, and becoming more concrete as necessary to discuss specific aspects ofprogram structure. Lorne's programming model incorporates both pictures ofphysical world objects and program details. As well, he stressed the importance ofthinking of statements in high-level languages as groups of machine- level code.Neither Kyle, Mario, nor Ross drew pictures when discussing program code.Neither did they discuss models used when teaching, but rather talked about ideasand problem domains.The ways in which the respondents categorize languages appear to be stronglyshaped by their mental models. Melissa categorized languages based onawkwardness. That is, she judges them based on the ease with which she canmanipulate them. Her favourite language is assembly language because it allowsher to get as close as possible to the physical machine. Claire categorizes languagesin terms of their structure and syntax. She likes Pascal, a modular, highly structuredlanguage that allows her to teach the concepts of structured programming. Isaaccategorizes languages in terms of paradigm. The amount of overlap he sees betweenparadigms and the fact that his description of the procedural paradigm is so highlydifferentiated points to his sense of programming as an integration of variouscomplex detailed systems. Isaac's favourite language is Modula-2 because it providesdiscipline in the complex programming environment. However, he sees greatpotential for C++, which supports both procedural and object-orientedprogramming, because, as he said, some problems fit a procedural solution whilesome fit an object-oriented one. James and Lorne categorize languages in terms ofuse and both like the object-oriented paradigm because it allows them to closelymodel the real world. James favourite language is C++ because it seems to be likethe real world. One of Lorne's favourite languages is Smalltalk because it allowshim to think about an exact model of the world. Lorne mixes languages based onWhat Teachers Know about Programming^ 166the requirements of the problems he is trying to solve and appears to move withgreat ease from one level to another. Kyle categorizes languages in terms ofparadigm. In particular, he likes Smalltalk and PROLOG, because with them he candevelopa very high-level abstract symbolic representation of the worldwhich has a relatively close mapping to the classical ways that we... model the world internally.Mario categorizes languages in terms of the ways in which he uses them toimplement solutions and teach various principles. To him, good languages mapthe problem domain. He finds that Smalltalk, Scheme and C++ allow him to easilyimplement solutions for the problem domains with which he deals. Like Lorne,Mario seems to move easily from one level to another and said that the ability tomove quickly from one level to another is one of the attributes of a goodprogrammer. Ross sometimes categorizes language as LISP and other. LISP to himis different from other languages because it allows him to implement ideas that are[dreamed] ... up out of the air; because it gives him a sense of inspired creativity. Hesaid, however, that he is really wild about a language that doesn't exist yet. Thatother language doesn't have a lot of parentheses, has a very smart interface, doesn'trequire compiling and doesn't get in Ross's way. It lets him build whatever hewants out of the air.The respondents' ideas about the best first programming language reflect the mentalmodels they have of programming. Melissa suggests that students should learnassembly language first so that they can better picture what is going on inside themachine when coding in other languages. Claire favours Pascal because it is a goodintroduction to structures and modular programs. Isaac also would teach Pascal firstbecause of the structure and limitations it imposes on the programming process.What Teachers Know about Programming^ 167Lorne would teach assembly language first. Although his mental model is abstract,he feels that an understanding of the way in which high-level languages can bebroken down into lower level instructions is vital because high-level languages arejust expansion on assembly language. Kyle feels that Smalltalk or an AI tool shouldbe taught first in order to give students the ability to model the world and to showthem a creative view of what can be done with a programming language. Marioridiculed the heated discussion about best first language. He feels that decisionsabout language should be grounded in the principles which one is trying to teach.The mental models that the respondents use when programming seem to shapetheir ideas about the attributes of good programmers. All of the respondents saidthat programmers require intelligence or the ability to think well. Upon closeanalysis, however, it appears that the meaning of the term intelligence and thereason for its importance differs from respondent to respondent. Melissa feels thatprogrammers need to be able to think logically, and need a strong sense of cause andeffect, reflecting her model of physical linear programs. Claire, for whomprogramming means coding and who concentrates on the level of program code,said that programmers must be able to think well, by which she means be able totranslate ... the ideas into code. Isaac thinks that programmers need above averageintelligence so that they can grasp and remember a vast quantity of facts and details.James, who is most concerned with modeling the world, maintains thatprogrammers need to be able to think well independently, using their knowledge tomodel application areas. Lorne described programming as a thinking person'sgame. His description of the necessity for programmers' to have the ability toorganize their thoughts into an overview of an entire system and break it down intoall the component pieces mirrors his tendency to move from one level of model toanother.What Teachers Know about Programming^ 168Kyle, Mario and Ross appear to have more abstract interpretations of the termintelligence than the other respondents. Kyle feels that programmers have stronganalytical and deductive reasoning skills, and Mario's interpretation of theintellectual skills required by programmers is that they need to be able to thinkanalytically and synthetically. Ross's sense is that good LISP programmers areattuned to intellectual issues in some sort of abstract pattern matching kind of way.The two respondents who, like Ross, tend to use more abstract models whenprogramming, are the only ones who echoed his feeling that programmers need tobe able to think abstractly. Kyle said that programmers are good abstract thinkersand Mario feels that not only must programmers be able to create mental models,but they must also be able to see things at multiple levels of abstraction. Asmentioned previously, however, only Ross differentiated between the skillsrequired by those who program in one paradigm and the skills required by thosewho program in another.The respondents who tend to use more concrete models mentioned many morepersonality traits required for programming than did the other respondents. Claireand Melissa agreed that programmers need to be patient. Melissa also feels thatprogrammers need to be hard workers who are persistent and can concentrate wellon details. Isaac feels that programmers need the kind of temperament that allowsthem to apply discipline to programming. Claire agrees that programmers need tobe systematic and [have] methodology. Although Kyle, at the abstract end of thescale, echoed Claire's opinion that programmers need to be systematic andmethodical, he was the only one of the other respondents to mention these traits.Several of the respondents said that programmers need to be able to see the bigpicture as well as the details when programming. Lorne and Mario, who tend to useWhat Teachers Know about Programming^ 169various levels of mental model when programming, feel that this ability to movebetween levels is an important attribute of good programmers. James and Melissaalso feel that programmers need to be able to solve problems at various levels.James draws a strong distinction between analysis and coding. He said that bothactivities are necessary, but feels that the former is by far the more important.Melissa, although she too recognizes the need for multi-level thinking, feels that itis more important that programmers are able to concentrate on details.Respondents from Melissa, who models at the most concrete model level, to thosewho model conceptualizations of the world, mentioned the need for programmersto have good planning skills. Mario mentioned Alan Kay's analogy, relatingprogramming to building a Gothic arch. Anybody can build a wall, Mario said. Togo beyond that, though, -- to build a Gothic arch -- one must plan the wholestructure ahead of time. Ross alone, who prefers to model the world of theimagination, feels that the kind of programming he does is not about planning, butabout experimentation and creativity.Isaac, Lorne and Kyle echoed Ross's sentiment that creativity is a part ofprogramming. Isaac compared programming to painting a picture. Lorne comparedit to composing a symphony. All four, however, volunteered the information thatthey themselves cannot draw or paint. It appears that to them the creativityinvolved in programming is different from the creativity involved in drawing orpainting. As Ross said, he does not have the talent to sculpt or draw, but thinks thatin programming he has perhaps found his artistic medium. When I asked them toevaluate whether or not people they know would make good programmers, three ofthe respondents used artists as examples of people who would not make goodprogrammers.What Teachers Know about Programming^ 170Melissa is the only respondent who said that she herself is not creative. It isinteresting to compare Melissa's description of a person who would not make agood programmer with Ross's description of how he feels when programming.Melissa's description of her friend, an artist:She can take a canvas and put a little blob here and a little blobthere and after a while it starts to turn into something. And I'mnot sure that she knows all along that that's what she's going toend up on .... She's a hairdresser. So she cuts a bit here and cuts abit there and looks at it and says, "Oh, maybe, OK, I'll cut a littlemore here and I'll change it here," rather than sort of plotting thewhole thing out.Ross's description of programming:To caricature it a bit you get the barest inkling of an idea and youtry it out right there and then on the machine and that actionleads to a sense that it's a dead end or an improvement or maybeyou're quite satisfied with it, but the process is very immediate.It's have a thought, try it out, have a thought, try it out.Melissa, who when programming models the physical reality of the machine,appears to have a very different notion about programming than does Ross, who,when programming, models ideas that he dreams up in his imagination. ToMelissa, planning and method are important, whereas to Ross, programming iscreative and interactive with a capital I. This difference in thinking aboutprogramming is echoed in Melissa's and Ross's very different teaching styles.Whereas Melissa shapes and structures her students' programs and uses physicalmodels so that they understand what is happening in the machine, Ross [swims]through this sea of alternatives with his students discovering and inventingpatterns that can be modeled on the computer.The respondents mentioned three other attributes of good programmers. Lorne,Melissa and Claire said that people must, above all, be motivated to learnprogramming. Each of them mentioned people who, although they might have theWhat Teachers Know about Programming^ 171ability to learn to program, were not interested in doing so, and would thereforemake poor programmers. Mario, Melissa and Claire feel that programmers need tohave good communications skills. Mario and Melissa also mentioned thatprogrammers need to have confidence that they will be able to solve a problem orfind a bug.It appears that the only quality felt to be important by all the respondents is a certainlevel of intelligence, which seems to mean different things to different respondents.Additionally, those at the abstract end of the scale feel that programmers need to begood abstract thinkers, whereas those at the more concrete end are concerned withpersonality traits such as patience and persistence. There is a feeling among some ofthe respondents that programmers need the ability to see problems at various levelsof abstraction. As well, the ability to plan was felt by many to be an importantattribute.The respondents had various opinions about predicting programmer success. Clairefeels that anyone can learn to program. Isaac, Mario and Melissa disagree. Mariosaid that whereas anyone could learn to use Hypercard or Toolbook, not everyonewould be able to go beyond that. Both Lorne and Kyle think that while some peoplehave natural programming abilities, with hard work and much training otherscould learn how to program as well. Ross is unsure whether programming ability isinnate or programmed. Most of the respondents feel that they can predict in amatter of minutes whether a person will be a good programmer and most, whenasked to tell me whether people they know would make good programmers, wereable to do so easily. Isaac, concerned with the complex interaction of programmingsystems details, said that he feels that he can predict which students will be goodprogrammers by listening to their speech. Those who do not pay attention togrammar and syntax, he feels, will not be good programmers. Both Lorne andWhat Teachers Know about Programming^ 172Mario, who tend to model real world problems when programming, evaluatepeople on the basis of their problem solving skills. Both feel that people who arewilling to try a problem-solving approach, whether ... right or wrong, as long as they[try] to solve the problem, have a good chance of becoming successful programmers.When listening to people talk about problem solving, Lorne evaluates whether theyare able to break a problem down into sub-problems. Mario said that he is lookingto see whether people are able to set goals for themselves and evaluate their successat reaching those goals.Interestingly, when talking about programmers and their traits, six of therespondents mentioned that they separate programmers into two distinct types.Although each respondent labeled the groups differently, it appears that they may betalking about the same groups of people. Those in one group are goal-oriented and,as Ross said, keep the engines of society oiled and working as they should. Clairecalls them applications programmers; James calls them business programmers. ForRoss they are the programmers who work in the block structured world. Isaac callsthem the neats because they tend to wear business suits and work in a corporateenvironment. The programmers in the other group, the ones that Mario says wantto push things to the limits and explore the boundaries of the system, seem to bemore interested in programming for the fun of it; for the opportunity to learn andexplore that it affords them. These programmers Claire calls systems programmersand James calls scientific programmers. For Ross they are the programmers whoinhabit LISP-world. Melissa calls them nerds. Although the respondents haveslightly different definitions of the two types of programmers, they seem to betalking about the same differentiation. As Mario said, tension exists between thedesire to explore and enhance programming tools and the need to focus on a goal. ItWhat Teachers Know about Programming^ 173requires exceptional ability, he said, to be able to marry the two aspects ofprogrammers' personalities in order to get the task at hand done.Thus it appears that the mental models the respondents use when programmingstrongly shape many aspects of their thinking about programming and teachingprogramming. In particular, the models they use when teaching, their views aboutlanguage and their estimation of programmers' attributes appear to be shaped by themental models they tend to use.ConclusionsThis study set out to investigate the answers to the following research questions:How do teachers organize their knowledge about programming?How do teachers organize their knowledge about teaching programming?How do teachers' constructions about programming integrate with theirconstructions about teaching programming?The following conclusions may be drawn from the analysis of discussions with eightprogramming teachers.1. The respondents' knowledge about programming and their knowledge aboutteaching programming appear to be constructed within the same conceptualframeworks. The two knowledge domains seem so inextricably intertwined thatthe relevant research question seems to be: Within what frameworks doteachers construct their knowledge about programming and the teaching ofprogramming?2. The respondents appear to construct their knowledge about programming andthe teaching of programming within conceptual frameworks, five of which are:What Teachers Know about Programming^ 1741. life experience,2. social context,3. desire for control,4. paradigm experience, and5. mental programming model.The conceptual frameworks which emerged from this study appear to beinterlinked. Particular frameworks appear to have more importance in shapingsome respondents' knowledge than others.3. The respondents appear to use mental models of the programming process. Themodels used by the respondents range from the concrete to the abstract.Particular respondents tend to use particular models. Most also at times employmodels at varying levels of abstraction.4. The mental models that the respondents use appear to relate to the paradigms inwhich they prefer to program. It is unclear whether the respondents choose theirparadigms based on an existing mental model or choose a model based on theparadigm in which they work.5. The respondents feel strongly that it is very difficult for programmers to shiftfrom one paradigm to another. They feel that the paradigms are very differentfrom one another and that programming in a particular paradigm shapes theway a programmer thinks.What Teachers Know about Programming^ 1756. Because of the difficulty of shifting between paradigms and languages, therespondents feel that the decision about which language students learn first iscritical.LimitationsThe study's conclusions are based on the respondents' articulated perceptions only.No triangulation was done to see if the teachers' perceptions of what happens intheir classrooms fits others' perceptions.Many of the respondents teach at the same school, know one another and know thesame students. Thus similarities among their views may be a function of sharedlocal knowledge. Interviews with teachers at different schools may uncoverdifferent perspectives.Because the study was exploratory in nature, the interviews had a very broad focus.There are therefore many areas which it would be useful to investigate in moredetail.ImplicationsThe results of the current study have implications for several areas: furtherresearch, the evaluation of existing literature and teaching practices.As this study progressed, the research questions changed shape. It appears now,because of the interlinking of the respondents' knowledge about programming andtheir knowledge about teaching programming, that a better research question to askwould be Within what conceptual frameworks do teachers construct theirknowledge about programming and teaching programming? A study designed toWhat Teachers Know about Programming^ 176investigate this question might be more apt to uncover frameworks which haveshaped teachers' knowledge.Furthermore, each of the frameworks uncovered in this study appears to offer a richarea of additional research. Studies investigating the ways in which each of theframeworks (life experience, social context, desire for control, paradigm experienceand mental programming model) relate to teachers' knowledge would likely lead todeeper understandings. Caution must be taken, however, not to concentrate on onearea to the exclusion of others. The purpose behind focusing on one frameworkwould be to increase depth of understanding so that the overall picture can be betterinformed.Researchers often do not make explicit their views about programming or theperspective from which they are approaching issues such as prediction, teachingmethods, and choice of language. It appears that there exist well-developedframeworks within which the respondents construct their knowledge aboutprogramming and teaching programming. It may be informative to evaluateexisting research studies with attention to the frameworks and perspectives withinwhich the researchers are conducting and presenting them. In particular, theemerging literature regarding the paradigm shift and the need for an alteration ofteaching practice based on a change in paradigm should be judged in light of thediffering perspectives that researchers schooled in non-procedural paradigms arelikely to have.The respondents have strong opinions about the differences involved inprogramming in different paradigms and about the difficulty of switching from oneparadigm to another. It may be valuable to examine the current practice of teachingthe procedural paradigm extensively, and the arguments against this practice, inWhat Teachers Know about Programming^ 177light of these strong opinions and with an understanding of the purpose for whichprogramming is being taught. Furthermore, if, as the respondents feel, the choice oflanguage is critical, the standard practice of teaching procedural paradigm initiallymust be re-examined.The respondents have strong mental models of programming that are reflected intheir teaching practices. Students too use mental programming models. Aninvestigation of the differences and similarities between teachers' and students'models may lead to a better understanding of the ways in which teaching practicescan be altered in order to be of most benefit to students.Four additional issues arising from this study appear to be worthy of furtherinvestigation:1) The relationship between mental model and paradigm.Some research has been done regarding programmers' use of mental models(Pennington, 1985). It appears that a relationship exists between programmers'mental models and the paradigms in which they work. Further investigation ofthis area may prove fruitful.2) First language.Several schools now teach a non-procedural language as students' first language(Abelson and Sussman, 1985; Reid, 1992). A study of these students' programmingsuccess compared to those learning procedural programming may expand ourunderstanding of the influence of students' first language. In particular, anexamination of students making the shift from one paradigm to another may proveenlightening.What Teachers Know about Programming^ 1783) Programmer attributes.The respondents had mixed opinions about the attributes required by goodprogrammers. A study of the attributes of expert programmers in variousparadigms may help differentiate the area. Furthermore, an examination ofpredictor variables related to students' success in various paradigms may uncoveruseful information about the ways in which success can be predicted.4) The two types of programmer.Almost all of the respondents differentiated between two distinct groups ofprofessional programmers. Further investigation of the qualities of each of thesegroups may lead to a better understanding of the attributes that programmersrequire.What Teachers Know about Programming^ 179REFERENCESAbelson, Harold and Sussman, Gerald Jay. (1985). Structure and interpretation ofcomputer programs. Cambridge: The MIT Press.Appleby, Doris. (1991). Programming languages: Paradigm and practice. New York:McGraw-Hill, Inc.Becker, Henry Jay. (1986). Instructional uses of school computers. ComputerSurvey Newsletters, Center for Social Organization of Schools, Johns HopkinsUniversity, 2, 1-12.Bitter, Gary G. and Lu, Mei-Yan. (1988). Factors influencing success in a junior highcomputer programming course. Journal of Educational Computing Research,4(1), 71-78.Bork, Alfred M. (1971). Learning to program for the science student. Journal ofEducational Data Processing, 8(5), 1-5.Borne, Isabelle and Girardot, Colette. (1990). Object-oriented programming in theprimary classroom. Computers in Education, 16(1), 93-98.Bracey, Gerald W. (1989). Conceptual models help students program better.Electronic Learning, 8(4), 24-25.Brady, Michael P., O'Donoghue, John, and Bajpai, Avi C. (1989). Top downprogramming for schools. The Computing Teacher, 16(6), 29-34.Brown, David E. and Clement, John. (1987). Overcoming misconceptions inmechanics: A comparison of two example-based teaching strategies. Paperpresented at AERA, Washington, D.C., April 20-24, 1987.Cafolla, Ralph. (1988). Piagetian formal operations and other cognitive correlates ofachievement in computer programming. Journal of Educational TechnologySystems, 16(1), 45-55.Cardwell, S. (1988). A study to determine the nature of science teachers' functionalparadigms using qualitative research methods. Unpublished master's thesis.University of British Columbia, British Columbia.Carey, T.T. and Shepherd, M.M. (1988). Towards empirical studies of programmingin new paradigms. Proceedings CSC '88. February 23-25, 1988. Atlanta,Georgia.What Teachers Know About Programming^ 180Chase, W.G. and Simon, H.A. (1973). Perception in chess. Cognitive Psychology, 4,55-81.Cheney, Paul. (1980). Cognitive style and student programming ability: Aninvestigation. AEDS Journal, 13(4), 285-291.Clarke, Anthony and Donn, Stuart. Novice programmers perceptions of twoinstructional methods; the first teacher centred, the second student centred.Unpublished manuscript.Clarke, Anthony. (1989). Instructional methods for novice programmers.Unpublished master's thesis. University of British Columbia, BritishColumbia.Connelly, F. M. and Clandinin, D. J. (1985). Conceptual understanding of teachers'thinking. NSSE Yearbook, 84(2), 174-198.Corman, Larry S. (1986). Cognitive style, personality type, and learning ability asfactors in predicting the success of the beginning programming student. ACMSIGCSE Bulletin, 18(4), 80-83.Dalbey, J. and Linn, M.C. (1985). The demands and requirements of computerprogramming: A review of the literature. Journal of Educational ComputingResearch, 1(3), 253-274.Dalbey, J., Tournaire, F., and Linn, M. (1985). Making programming instructioncognitively demanding: An intervention study (ACCCEL Report). Berkeley:University of California, Lawrence Hall of Science.Denning, P.J. (1989). A debate on teaching computer science. Communications ofthe ACM, 32(12), 1397-1414.Denning Peter J., Comer, Douglas E., Gries, David, Mulder, Michael, Tucker, Allen,Turner, A. Joe and Young, Paul R. (1989). Computing as a discipline.Communications of the ACM, 32(1), 9-23.Dijkstra, Edsger W. (1989). On the cruelty of really teaching computer science.Communications of the ACM, 32(12), 1398-1404.DiNitto, Samuel A. (1988). Future directions in programming languages.Proceedings 1988 IEEE International Conference on Computer Languages.October 9-13, 1988. Washington, D.C.: IEEE Computer Society Press.What Teachers Know About Programming^ 181Driver, Rosalind and Erickson, Gaalen. (1983). Theories-in-action: Sometheoretical and empirical issues in the study of students' conceptualframeworks in science. Studies in Science Education, 10, 37-60.Driver, Rosalind. (1989). Changing conceptions. In P. Adey (Ed.), Adolescentdevelopment and school science. Lewes: Falmer Press.Du Boulay, Benedict. (1989). Some difficulties of learning to program. In ElliotSoloway and James C. Spohrer (Eds.), Studying the novice programmer.Hillsdale, New Jersey: Lawrence Erlbaum Associates, Inc.Eisner, E.W. (1985). The educational imagination. New York: MacmillanPublishing Company.Elbaz, F.M. (1983). Teacher thinking. London: Groom Hall.Ellis, D. (1989). An evaluation of BASIC computer language as a prerequisite touniversity computer science. Unpublished master's thesis. University ofBritish Columbia, British Columbia.Erickson, Frederick. (1986). Qualitative methods in research on teaching. In MerlinC. Wittrock (Ed.), Handbook of research on teaching (3rd ed.). New York:Macmillan.Ezell, C.L. (1990). Creating pedagogical programming environments. ACM SIGCSEBulletin, 22(2), 42-46.Feiman-Nemser, Sharon and Floden, Robert E. (1986). The cultures of teaching. InMerlin C. Wittrock (Ed.), Handbook of research on teaching (3rd ed.). NewYork: Macmillan.Ferchichi, Ahmed and Jaoua, Ali. (1987). Teaching first year programming: Aproposal. ACM SIGCSE Bulletin, 19(3), 48-52.Feurzeig, Wallace. (1988). Apprentice tools: Students as practitioners. In RaymondS. Nickerson & Philip P. Zodhiates (Eds.), Technology in education: Lookingtoward 2020. Hillsdale, NJ: Lawrence Erlbaum Associates.Finlay, Janet. (1988). Academic background: A predictor of computing aptitude?Computer Bulletin, 4, 36-37+.Ghezzi, Carlo and Jazayeri, Mehdi. (1987). Programming language concepts 2/e.New York: John Wiley and Sons, Inc.Glaser, Barney G. and Strauss, Anselm L. (1970). Discovery of substantive theory: Abasic strategy underlying qualitative research. In William J. Filstead (Ed.),What Teachers Know About Programming^ 182Qualitative methodology: Firsthand involvement with the social world.Chicago: Markham Publishing Company.Glaser, B.G. and Strauss, A.L. (1967). The discovery of grounded theory. Chicago:Aldine-Atherton.Glasersfeld, Ernst von. (1989). Cognition, construction of knowledge, and teaching.Synthese, 80, 121-140.Greer, Jim. (1986). High school experience and university achievement incomputer science. AEDS Journal, 19(2&3), 216-225.Grogono, Peter. (1989). Meaning and process in mathematics and programming.For the Learning of Mathematics, 9(1), 14-19.Guinan, Tricia and Stephens, Larry. (1988). Factors affecting the achievement ofhigh school students in beginning computer science courses. Journal ofComputers in Mathematics and Science Teaching, 8(1), 61-64.Hancock, Chris. (1988). Context and creation in the learning of computerprogramming. For the Learning of Mathematics, 8(1), 18-24.Hirshfield, Stuart H. (1985). Programs as symbolic representations of solutions toproblems. In R. Jernigan, B.W. Hamill and D.M. Weintraub (Eds.), The roleof language in problem solving - 1. Amsterdam: Elsevier Science PublishersB. V.Howe, K. and Eisenhart, M. (1990). Standards for qualitative research: aprolegomenon. Educational Researcher, 19(4), 2-9.Jacob, Evelyn. (1988). Clarifying qualitative research: A focus on traditions.Educational Researcher, 17(1), 16-24.Johanson, Roger P. (1988). Computers, cognition and curriculum: Retrospect andprospect. Journal of Educational Computing Research, 4(1), 1-30.Joni, Saj-Nicole A. and Soloway, Elliot. (1986). But my program runs! Discourserules for novice programmers. Journal of Educational Computing Research,2(1), 95-125.Kahney, Hank. (1989). What do novice programmers know about recursion? InElliot Soloway and James C. Spohrer (Eds.), Studying the novice programmer.Hillsdale, New Jersey: Lawrence Erlbaum Associates, Inc.Karp, Richard M. (1989). A debate on teaching computing science. Communicationsof the ACM, 32(12), 1410-1412.What Teachers Know About Programming^ 183Kay, Robin H. (1989). Bringing computer literacy into perspective. Journal ofResearch on Computing in Education, 22(1), 35-43.Koffman, Elliot B., Miller, Philip L., and Wardle, Caroline E. (1984). Recommendedcurriculum for CS1, 1984. Communications of the ACM, 27(10), 998-1001.Kuhn, T.S. (1962). The structure of scientific revolutions. Chicago: University ofChicago Press.Kurland, D. Midian, Pea, Roy D., Clement, Catherine and Mawby, Ronald. (1989).The study of the development of programming ability and thinking skills inhigh school students. In Elliot Soloway and James C. Spohrer (Eds.), Studyingthe novice programmer. Hillsdale, New Jersey: Lawrence ErlbaumAssociates, Inc.Lee, Okhwa and Lehrer, Richard. (1988). Conjectures concerning the origins ofmisconceptions in LOGO. Journal of Educational Computing Research, 4(1),87-105.Leeper, R.R. and Silver, J.L. (1982). Predicting success in a first programming course.ACM SIGCSE Bulletin, 14(1), 147-150.Lemos, R. (1975). Fortran Programming: An analysis of pedagogical alternatives.Journal of Educational Data Processing, 12(3), 21-29.Liao, Yuen-Kuang Cliff and Bright, George W. (1991). Effects of computerprogramming on cognitive outcomes: A meta-analysis. Journal ofEducational Computing Research, 7(3), 251-268.Lincoln, Y.S. and Guba, E.G. (1985). Naturalistic inquiry. Beverly Hills: Sage.Linn, Marcia C. (1985). The cognitive consequences of programming instruction.Educational Researcher, 14(4), 14-16, 25-29.Lortie, D. (1975). Schoolteacher. Chicago: University of Chicago Press.Luker, Paul A. (1989). Never mind the language, what about the paradigm? ACMSIGCSE Bulletin, 21(3), 252-256.MacGregor, S. Kim. (1988). Computer programming instruction: Effects ofcollaboration and structured design mileposts. Journal of Research onComputing in Education, 21(2), 155-164.McIntyre, Pat. (1991). Teaching structured programming in the secondary schools.Malabar, Florida: Krieger Publishing Company.What Teachers Know About Programming^ 184McKeithen, Katherine B., Reitman, Judith S., Rueter, Henry H. and Hirtle, StephenC. (1981). Knowledge organization and skill differences in computerprogrammers. Cognitive Psychology, 13, 307-325.Magoon, A. Jon. (1977). Constructivist approaches in educational research. Reviewof Educational Research, 47(4), 651-693.March, Richard. (1989). Coping with the PC slowdown. PC Week, 6(38), 119-120.Marchionini, Gary. (1985). Teaching programming: A developmental approach.The Computing Teacher, 12(8), 12-15.Massarik, F. (1981). The interviewing process re-examined. In P. Reason and R.Rowan (Eds.), Human inquiry: A sourcebook of new paradigm research.New York: John Wiley and Sons.Mawhinney, Charles H. and Saraswat, Satya Prakash. (1991). Personality type,computer anxiety and student performance: An empirical investigation.Journal of Computer Information Systems, 31(3), 101-103.Mayer, Richard E. (1975). Different problem-solving competencies established inlearning computer programming with and without meaningful models.Journal of Educational Psychology, 67(6), 725-734.Mayer, Richard E. (1989a). Models for understanding. Review of EducationalResearch, 59(1), 43-64.Mayer, Richard E. (1989b). The psychology of how novices learn computerprogramming. In Elliot Soloway and James C. Spohrer (Eds.), Studying thenovice programmer. Hillsdale, New Jersey: Lawrence Erlbaum Associates,Inc.Mishler, Elliot G. (1986). Research interviewing: Context and narrative.Cambridge, Massachusetts: Harvard University Press.Morecroft, Josephine F. and Ameen, David A. (1987). Development of criteria topredict student success as an information systems major. Interface: TheComputer Education Quarterly, 8(4), 44-47.Nussbaum, Joseph and Novick, Shimshon. (1982). Alternative frameworks,conceptual conflict and accommodation: Toward a principled teachingstrategy. Instructional Science, 11, 183-208.What Teachers Know About Programming^ 185Oliver, Ron and Malone, John. (1991). The influence of instruction and activity onthe development of semantic programming knowledge. Submitted forpublication.Oman, Paul W. (1986). Identifying student characteristics influencing success inintroductory computer science courses. AEDS Journal, 19(2-3), 226-233.Palumbo, David B. (1990). Programming language/problem-solving research: Areview of relevant issues. Review of Educational Research, 60(1), 65-89.Pandey, Rajeev. (1990). Getting the languages for a programming languages course.ACM SIGCSE Bulletin, 22(4), 11-14.Papert, Seymour. (1987). Computer criticism vs. technocentric thinking.Educational Researcher, 16(1), 22-30.Parnas, David Lorge. (1985). Software aspects of strategic defense systems.Communications of the ACM, 28(12), 1326-1335.Pea, Roy D. (1986). Language-independent conceptual "bugs" in noviceprogramming. Journal of Educational Computing Research, 2(1), 25-35.Pennington, Nancy. (1985). Stimulus structures and mental representations inexpert comprehension of computer programs. Office of Naval Research,Arlington, Va. ERIC ED263219.Petersen, Charles G. and Howe, Trevor G. (1979). Predicting academic success inintroduction to computers. AEDS Journal, 4(12), 182-191.Petre, Marian and Winder, R. (1990). On languages, models and programmingstyles. The Computer Journal, 33(2), 173-180.Posner, George J., Strike, Kenneth A., Hewson, Peter W. and Gertzog, William A.(1982). Accommodation of a scientific conception: Toward a theory ofconceptual change. Science Education, 66(2), 211-227.Postma, S. and Laing, D. (1981). Programmers, programmarians andprogrammaticasters: On the training of. AEDS Monitor, 20(3), 28-31.Province of British Columbia, Ministry of Education, Curriculum DevelopmentBranch. (1985). Computer Studies 11 Curriculum Guide and Resource Book1984. Victoria, B.C.: Queen's Printer for British Columbia.Putnam, Ralph T., Sleeman, D., Baxter, Juliet A., and Kuspa, Laiani K. (1989). Asummary of misconceptions of high-school BASIC programmers. In ElliotWhat Teachers Know About Programming^ 186Soloway and James C. Spohrer (Eds.), Studying the novice programmer.Hillsdale, New Jersey: Lawrence Erlbaum Associates, Inc.Ralston, Anthony and Shaw, Mary. (1980). Curriculum '78 -- is computer sciencereally that unmathematical? Communications of the ACM, 23(2), 67-70.Reid, Richard J. (1992). 6th Edition of CS1 Languages (electronic mail posting, April9, 1992, 17:33:51 GMT), Michigan State University.Rich, Robert. (1985). Influence of language on its user. In R. Jernigan, B.W. Hamilland D.M. Weintraub (Eds.), The role of language in problem solving - 1.Amsterdam: Elsevier Science Publishers B.V.Rifkin, Glenn. (1989). Facing up to hire stakes. ComputerWorld, 2(10), 16-18.Sall, M.S. (1989). Variables predicting achievement in introductory computerscience courses. Unpublished master's thesis. University of BritishColumbia, British Columbia.Salomon, Gavriel and Perkins, D.N. (1987). Transfer of cognitive skills fromprogramming: When and how? Journal of Educational Computing Research,3(2), 149-169.Sammet, Jean E. (1991). Some approaches to, and illustrations of, programminglanguage history. Annals of the History of Computing, 13(1), 33-50.Scherz, Z., Goldberg, D., and Fund, Z. (1990). Cognitive implications of learningProlog - mistakes and misconceptions. Journal of Educational ComputingResearch, 6(1), 89-110.Schulz, Charles E. (1984). A survey of colleges and universities regarding entrancerequirements in computer-related areas. Mathematics Teacher, 77(7), 519-521.Schwartz, J.T. (1975). What programmers should know. Computer Languages, 2,21-25.Sebesta, Robert W. (1989). Concepts of programming languages. Redwood City, CA:Benjamin/Cummings Publishing Co. Inc.Sharma, Sarla. (1987). Learners' cognitive styles and psychological types asintervening variables influencing performance in computer science courses.Journal of Educational Technology Systems, 15(4), 391-399.Sheil, B.A. (1981). The psychological study of programming. ACM ComputingSurveys, 13(1), 101-120.What Teachers Know About Programming^ 187Shneiderman, Ben and Mayer, Richard. (1979). Syntactic/semantic interactions inprogrammer behavior: A model and experimental results. InternationalJournal of Computer and Information Sciences, 8(3), 219-238.Shneiderman, Ben. (1977). Teaching programming: A spiral approach to syntax andsemantics. Computers and Education, 1(4), 193-197.Shneiderman, Ben. (1985). When children learn programming: Antecedents,concepts and outcomes. The Computing Teacher, 12(5), 14-17.Shneiderman, Ben. (1988). A nonanthropomorphic style guide: Overcoming theHumpty Dumpty syndrome. The Computing Teacher, 16(20), 9-10.Skublics, Suzanne and White, Paul. (1991). Teaching Smalltalk as a firstprogramming language. ACM SIGCSE Bulletin, 23(1), 231-234.Sleeman, D., Putnam, Ralph T., Baxter, Juliet and Kuspa, Laiani. (1986). Pascal andhigh school students: A study of errors. Journal of Educational ComputingResearch, 2(1), 5-23.Soloway, Elliot, Ehrlich, Kate, Bonar, Jeffrey and Greenspan, Judith. (1982). Whatdo novices know about programming? In A. Badre and B. Shneiderman(Eds.), Directions in human-computer interactions. Norwood, New Jersey:Ablex Publishing Corp.Soloway, Elliot. (1988). It's 2020: Do you know what your children are learning inprogramming class? In Raymond S. Nickerson & Philip P. Zodhiates (Eds.),Technology in education: Looking toward 2020. Hillsdale, NJ: LawrenceErlbaum Associates.Sorge, Dennis H. and Wark, Lois K. (1984). Factors for success as a computer sciencemajor. AEDS Journal, 17(4), 36-45.Spector, Barbara S. (1984). Qualitative research: Data analysis frameworkgenerating grounded theory applicable to the crisis in science education.Journal of Research in Science Teaching, 21(5), 459-467.Spohrer, James C. and Soloway, Elliot. (1989). Novice mistakes: Are the folkwisdoms correct? In Elliot Soloway and James C. Spohrer (Eds.), Studying thenovice programmer. Hillsdale, New Jersey: Lawrence Erlbaum Associates,Inc.Spradley, J. (1979). The ethnographic interview. New York: Holt, Rinehart andWinston.What Teachers Know About Programming^ 188Stake, Robert E. (1978). The case study method in social inquiry. EducationalResearcher, 7, 5-8.Stevens, D.J. (1983). Cognitive processes and success of students in instructionalcomputer courses. AEDS Journal, 16(4), 228-233.Temte, Mark C. (1991). Let's begin introducing the object-oriented paradigm. ACMSIGCSE Bulletin, 23(1), 73-77.Trow, Martin. (1970). Comment on "Participant observation and interviewing: Acomparison". In William J. Filstead (Ed.), Qualitative methodology:Firsthand involvement with the social world. Chicago: MarkhamPublishing Company.Van Merrienboer, Jeroen J.G. and Krammer, Hein P.M. (1987). Instructionalstrategies and tactics for the design of introductory computer programmingcourses in high school. Instructional Science, 16, 251-285.Watson, Warren E. and Behnke, Ralph R. (1991). Application of expectancy theoryand user observations in identifying factors which affect human performanceon computer projects. Journal of Educational Computing Research, 7(3), 363-376.Webb N.M., Ender P., and Lewis, S. (1986). Problem solving strategies and groupprocesses in small groups learning computer programming. AmericanEducational Research Journal, 23, 243-262.Weinberg, Gerald M. (1971). The psychology of computer programming. NewYork: Van Nostrand Reinhold Company.Wells, Mark B. and Kurtz, Barry L. (1989). Teaching multiple programmingparadigms: A proposal for a paradigm-general pseudocode. ACM SIGCSEBulletin, 21(1), 246-251.Wilson, Stephen. (1977). The use of ethnographic techniques in educationalresearch. Review of Educational Research, 47(1), 245-265.Woodhouse, D. (1983). Introductory courses in computing: Aims and languages.Computer Education, 7(2), 79-89.Woods, P. (1986). Inside schools: Ethnography in educational research. New York:Routledge and Kegan Paul Inc.What Teachers Know About Programming^ 189Yakel, Erna, Cobb, Paul, Wood, Terry, Wheatley, Grayson, and Merkel, Graceann.(1990). The importance of social interaction in children's construction ofmathematical knowledge. In Cooney, Thomas J. (Ed.), Teaching and learningmathematics in the 1990s. Reston: National Council of Teachers ofMathematics.What Teachers Know About Programming^ 190APPENDIX AGLOSSARYAlgorithm: A finite set of step-by-step instructions for solving a problemApplication: The job or task that the user wants the computer to performArithmetic Logic Unit: The part of the computer that performs the mathematicaland logical functionsArray: A structured data typeArtificial Intelligence: The field of computing that investigates the use of computersto simulate human reasoningBit: A binary digitBug: An error in a computer programByte: Eight bitsCoding: The process of writing the computer program instructions in a particularprogramming languageCompiled language: A language in which the program code is translated tomachine code all at once (See interpreted language.)Computer Assisted Software Engineering: The process of creating software with theassistance of specially designed toolsComputer program: A series of instructions that tells the computer what to doDebugging: The process of finding and correcting a programming errorDesk Checking: Tracing the steps of a computer program by hand on paperEnvironment: The machine upon which a programming language is used and theway in which it is implementedExpert Systems: The field of artificial intelligence that deals with using computers tosimulate the knowledge of an expertFlowchart: A graphic tool used to design and document the steps of a programFOCUS: A high-level programming toolWhat Teachers Know About Programming^ 191Fourth Generation Language: A language which does not require the user to haveknowledge of low-level detailed program instructionsHardware: The physical components of a computerHexadecimal: Base 16.High-level language: a programming language that uses instructions that closelyresemble human language and mathematical notationInference Engine: The facility built in to a language used for artificial intelligenceprogramming which performs logical operationsInterpreted language: A language in which the program code is translated tomachine code one line at a time (See compiled language.)Linked List: An abstract data typeLoop: A programming construct which causes instructions to be performedrepetitivelyMainframe: A large scale computerNetwork: To join several computers together so that they can share common dataand programsOracle: A database package.OS/2: A computer operating systemPixel: The smallest part of a display screen that can be individually controlledPointer: A data type used as an internal address referenceProgrammer: The person who writes the instructions, or code, that tell thecomputer what to doProgramming language: A set of written symbols that instruct the computer toperform specific tasksQueue: An abstract data typeRegister: A part of the central processing unit which stores information forimmediate useREXX: An IBM mainframe system languageSoftware: The instructions that direct the operations of a computerWhat Teachers Know About Programming^ 192SPSS: A statistical package.Stack: An abstract data typeSupport: A job which involves helping users solve computer problemsSystems Programming: Writing programs that control the computer's operatingsystemThird Generation Language: A high-level language (e.g. Pascal)UNIX: A computer operating systemWindows: A graphical user interfaceWhat Teachers Know About Programming^ 193APPENDIX BSAMPLE INTERVIEW TRANSCRIPTKyle: Mar 17/92D: Do you know what I'm doing?K: Sort of. My understanding is is that you're working on a Master's Thesis inEducation and you're investigating something about Computer Scienceteaching.D: mm-hmmK: And pedagogy.D: Yes. Yeah. So I'm looking at urn teachers', people who teachprogramming's, view of programming and their view of teaching andwhat makes a good programmer and that kind of thing.K: Mm-hmmD: And the sense of the interview is not one where I sit and ask you questionsand you answer this form of questions that I have here.K: Right.D: But it's more what's called a 'rapport' interview. So we know each otherand and we're not going to pretend that we don't know each other, so anylingo you want to use or referring to things that I know about, like "I teach444" or whatever it's called, you can just do that and you don't have toworry about the fact that there's somebody else listening. Ok?K: OKD: All right. How did you come to be teaching in Computer Systems?K: Day time or night time?D: Either. Both, actually.K: I started off uh ... The Continuing Ed teaching started because there was amissing Pascal teacher many years ago.D: Oh.What Teachers Know About Programming^ 194K: in 1985 or 1986 and uh they knew, uh A and B knew that I knew Pascal. Ithink B passed my name on to A and A called me up and asked me if I'dlike to teach the Pascal course and urn so yeah, that's the way it started.D: And had you been a student at BCIT already?K: Yes. Before that I had ... My educational background is that I did the secondyear of BCIT's CST program, graduating in Expert Systems option and asyou know I recently wrapped up my BSc in Computer Science at SFU.D: And then how did you come to be teaching day school?K: Well, in the night school I eventually moved from Pascal to focus on whatare my specialties, which is AI programming techniques: LISP, Prolog,Knowledge System techniques in general and as an adjunct, Smalltalk andobject-oriented programming which are skills I've been playing with foryears. And so I was urn uh sort of had a long history and experience inSmalltalk and OOPS programming and when C wanted to start up urn aSmalltalk class in the daytime, he asked me if I'd like to teach it.D: Mm-hmm. So when did you start programming in Smalltalk?K: Urn... maybe I'm guessing, but maybe 1987, 1986, but my experience withobject-oriented programming goes back to I guess 85.D: And that would have been in ...K: In the expert systems option.D: OKK: Cuz these concepts, basically or have been largely influenced by a lot of AIprogramming work.D: Mm-hmm mm-hmm So would you make a distinction there at all?K: Urn, well a lot of the concepts that you find in in object-orientedprogramming are also found in the concepts of frames and frame-basedprogramming. Um yeah there are some technical distinctions, but they'reminor and the uh similarities are a lot larger. Yeah. Like a lot of the, a lotof the stuff that you see in object-oriented programming ... There's differentlevels of it. One of the levels that you can look at object-orientedprogramming is as a a way to represent the world, you know, andknowledge about the world and things in the world, and urn in in AI work,and in Expert Systems work, you're looking at the same problem, you'relooking at how do we represent knowledge and what are differenttaxonomies or ontologies, ways to represent things and that's uh uh theWhat Teachers Know About Programming^ 195similarities between frame representations and object representations arevery very similar.D: Mm-hmm, mm-hmm. Have you taught ... So you've taught Pascal,Smalltalk,K: LISPD: LISPK: Prolog and uh uh Knowledge Systems courses, in building knowledgesystems.D: OK. Anything else that you've taught either here or elsewhere?K: Uh, yeah. APL, here, I taught APL. Uh, to the daytime CST studentsD: Oh right.K: some years ago.D: Oh yeah, I remember that.K: YeahD: I'm just going to write some of these languages down ...K: SureD: cuz I'm going to ask you about, something about them in a bit.K: Um. and I have done um Smalltalk courses for outside groups, people likeBC Tel.D: Mm-hmm. Mm-hmm. How did you first learn how to program?K: At university.D: Mm-hmm.K: Yeah. I um chose Computer Science because it seemed to be a urn goodfield in terms of employment. I guess I made this decision like in 1978.D: OK, so you were just coming out of high school?K: No, I was coming back from India.D: OK.What Teachers Know About Programming^ 196K: Yeah (laughs)D: But this would be so you you after high school ...K: Oh, I I didn't well, I quit high school and I spent several years living on theroad urn travelling North America and whatnot and had manyadventures, eventually ended up in India and urn it was when I came backfrom there in 78 uh that I started university.D: You chose Computer Science having come from India?K: YeahD: Because it seemed like it offered good employment?K: Well, I've been meditating for years, since I was a teenager and when I wasin India, my teacher recommended that I study something in which I couldmake a lot of money easily (laughs).D: That sounds so so the opposite of what I would think a teacher in Indiawould say.K: Yeah, cuz I mean the basic principle in in meditative traditions or in yogatraditions is that you want some free time in order to be able to devote tospiritual practice like meditation, to service, and things like that and ifyou're so poor that you have to spend all of your time working, then youwon't have any time free to be able to devote to service or meditation etc.and uh so it's actually a very common teaching to uh work efficiently, tolearn something that you can make money easily with, so that you havefree time.D: Mm-hmm mm-hmm. Has that worked out? Do you have free time?K: Yeah.D: Yeah? That's not my sense of computer programmers at all. (he laughs)People with lots of free time, no.K: Yeah.D: Hmm. So ...K: So, I uhD: you went to SFU?K: I chose Computer Science because it looked like urn a) it looked like it wasa useful field to get a job easily in and although I knew nothing about whatWhat Teachers Know About Programming^ 197the work would be like, urn it it interested my vaguely, I had an aptitudefor scientific and mathematical things.D: OK so, you knew that you had an aptitude for Science and Math from ...K: YeahD: high school and that kind of stuff?K: Yeah and just from my interests.D: YeahK: I always loved Science. My first interests, you know, ever since I was a littlekid.D: Mm-hmm. And so it was your sense that Computer Science was going to•••K: I chose ...D: would require the same aptitude?K: I chose it primarily because um I chose it primarily because it seemed to meI would be able to get a job in the field and that it paid well.D: Mm-hmmK: And urn and secondly because it seemed in some way to be sort of scientificor technical and that seemed to fit with my interests.D: Yeah. OK. So, you did that for a number of years ..K: Do you want a basic history?D: Yeah, I guess so,K: I, uhD: cuz I want to ask about your sort of work background as well.K: Sure. I did uh 3, 3 ... I did maybe 4 semesters in a row at SFU, like a yearand a third of Computer Science courses and so that's where I was firstexposed to programming.D: OK. What was your first language?K: PL/IWhat Teachers Know About Programming^ 198D: Pl/I?K: Yeah.D: Oh, interesting.K: You know and it it in those days and still today a relatively good firstlanguage because it was urn uh you know well-structured, urn rich, etc.D: Yeah, yeah. So that's ...K: That ..D: Go ahead.K: That was the first language of choice that they chose to teach students atSFU in those days.D: And so you would say that that's a reasonable choice for a first language?K: Yeah, at the time it was a good choice, cuz you know, it's structuredprogramming constructs and stuff like that.D: Yeah Yeah. It... Does that imply that it wouldn't be a good first choicenow?K: Uh, it's a little bit top heavy in that it's got a lot of features? And well, it'shard to say. Like on the one hand it's got a tremendous amount offeatures. That could make it potentially overwhelming for a student, butthen again you can look at PL/I in terms of a subset language and chop outa lot of these other features and then as you want to introduce new featuresto students for example pointer manipulation or recursion the languagesupports that as well so in that sense the students could move from simpleprogramming to more complex uh programming techniques all within thesame language so there's that consistency.D: Mm-hmmK: So, you know, it has advantages that way.D: Yeah yeahK: And as well of course there's a lot of hooks to different types of fileprocessing urn which was useful and practical.D: Mm-hmmWhat Teachers Know About Programming^ 199K: Yeah. So after uh 4 semesters, I joined the co-op program at SFU and wentto work at ICBC and I chose ICBC because a returning co-op student, who Iasked about, you know, places to work uh said that they had a really neattext editor there. It was like a full-screen editor in which you could move acursor in two dimensions and stuff like that.D: Wow (we laugh)K: And I went wow!D: I remember those days.K: Because up until that point we just used an MTS line editor ..D: Yeah yeahK: for for editing. So uh so that's why I chose ICBC. And my first semester atICBC as a co-op student was as a PL/I programmer and it was a greatexperience because urn I was introduced to large formal methodologies, ashop that had to develop really big systems that urn you know used IMSand urn formal database policies, formal uh design and analysis policiesand urn people worked in teams and uh so it was an excellent, really anexcellent experience.D: mm-hmm mm-hmmK: Urn, came back after that semester, did another semester or anothersemester or two I can't remember, of Computer Science.D: Yes.K: Then I went back to ICBC again for another co-op term and this time Iasked to work as an APL programmer because by this time I'd learned APLand urn uh it was urn a much more interesting intriguing language to methan conventional 3GLs.D: In what way?K: uh its expressiveness. The ability to do very complex things in a verycompact amount of statements. Urn its consistency to the urn to theparadigm of um you know matrices, scalars, matrix uh manipulation. Umthat's one of the things that intrigued me about it, there were like it it itdefinitely like was in a particular paradigm and that is, of manipulatingmatrices.D: Mm-hmm.K: And uh that was interesting to work with.What Teachers Know About Programming^ 200D: mm-hmm, mm-hmm. Anything else about why it was so intriguing?K: Uh, well, I think I'd just be repeating myself and that would be that youcould you could do things quickly in it.D: OKK: In a powerful language.D: OK Do you still feel like that about APL?K: Yes. Mathematical type problems. Like at the time, spreadsheets didn'texist. This was in the 1970s. And urn so in uh at ICBC it was used for a lotof financial analysis work, you know, things today you would use aspreadsheet for, but at that time it was uh many times faster than using anyother tool except some of the report writers that were available uh for stuffand it was even faster in those days for building transaction applicationsthan urn most other tools available. Urn IBM APL included a hook to aurn like a screen interface uh and also hooks to IMS so that we could use itfor actually making, you know, a transaction application which woulddisplay out and read records to IMS databases. So we used IPL uh APL fordoing uh prototypes of urn applications which would, which actually wentinto production like at selected sites. An example would be urn urn whenyou wanted to make an appointment with an adjuster there was a systemthat would automatically do like adjuster appointment management.D: Mm-hmm Mm-hmm Wow. That's amazing I never would have thoughtthat - APL.K: Yeah. And and our group that ... it was an APL group, you know, it waslike like the leading edge group in the Systems uh department because wewere using report writers in APL and just spitting out applications tentimes faster than anybody else.D: NeatK: YeahD: So ...K: And after that um uh what I really wanted to do was go back to India urnall along my goal had been to save enough money to go back to India forsay 5 or 10 years and stay there for a good long time so after my first thatsecond work semester at ICBC, I elected not to go back to SFU, but just tostay on at ICBC and keep working, saving some money. So I did that for awhile. Saved some money, went back to India for quite a long time. Thattakes me up to the, I guess, early 80s urn I came back from India afterWhat Teachers Know About Programming^ 201several years. I got sick and urn had various adventures. Urn eventually Iuh did a business in which I would buy up review copy books from well, Icouldn't work regularly when I came back because I was sick for about ayear afterwards with intestinal problems, the usual story, but I had a realbad long case of it and so I had to do some type of work urn uh that I coulddo like at my own leisure. So I got into an entrepreneurial business inwhich I would buy up review copy books from university professors andsell them to a book wholesaler. Um and one day I was visiting BCIT doingthat and I saw a poster about the possibility of entering second year directlyfor urn certain qualifying students. And I realized right away I'd probablyhave those uh capabilities and uh I just dropped into the CST departmentto look into it and bang, that was my first introduction to the term ExpertSystems and it immediately caught my interest and thus I started in theExpert Systems program. And I went through Expert Systems, graduated,got a job building Expert Systems in Prolog for a small startup company,worked for them for just a couple of months and then they ran out ofmoney and went bankrupt. Uh then um I was hired to come here at BCITas a Systems Analyst and uh while here my work has been very varied interms of its uh what I've done over the years. Uh urn a lot of work hasbeen done in FOCUS, 4GL, um SPSS, REXX, urn more stuff than I canremember, and urn, uh, these days I'm using more a very high level toollike an EIS you know building tool ???? building tool in Windows andnow we're getting into Oracle because we're doing the Student Info Systemin Oracle.D: Right.K: And I do consulting work on the side. Usually in Prolog and Smalltalk.D: Oh yeah.K: In fact always in Prolog and Smalltalk.D: Yes. Urn so what would be the last Prolog or Smalltalk program ...K: Uh, the Prolog project that I'm working on at the moment is uh aknowledge system related to genetics. Um it's being done with a consultantdowntown who I've been associated with for quite a few years - Dr. L.D: Oh yeah.K: And uh the genetics department at UBC, urn there is a uh genetic material,chromosome, can have abnormalities and geneticists and there are a is it 26different chromosomes in a human being. And geneticists look at thesechromosomes and they're trained to be able to identify what theabnormalities are? And then they record these abnormalities using anotational system called ISCN.What Teachers Know About Programming^ 202D: I think he came to a Professional Day ...K: Dr. L. did?D: Dr L. did.K: Kay, so you know the story anyway.D: Yeah.K: I'm working on that project.D: Neat.K: So it's a very interesting project and urn uh it's going to be extended forleukemia abnormalities now. There's two types of abnormalities:congenital and acquired. Acquired abnormalities are those you get throughdisease, like leukemia and it's a chicken/egg scenario. I'm not a geneticistlike I don't know whether you get the ...D: RightK: you know, what comes first.D: YesK: But anyways when leukemia is present, there are genetic abnormalitiespresent as well.D: Mm-hmmK: So I'm working on a project related to that.D: Hmm. Wow wow. And that's Prolog?K: YeahD: Um, so you've been programming for a fairly long time. You'reprogramming now.K: Since 78.D: Mm-hmm. Kay. What do you like about programming?K: Creativity. For me it's a um for me it is a an outlet for uh creativeexpression for urn uh well for constructing something and uh I like the Ialso like the fact that you're solving a real world problem. I'm also amusician and urn.What Teachers Know About Programming^ 203Tape changeD: Urn so you were saying that you've been a musician since you were ayoung teenager.K: Yes and um although composing music doesn't have the same sort ofpractical value as uh writing programs does for me, I still enjoy the creativeexpression process, but definitely part of what interests me inprogramming and Computer Science, is that it has, it has something to dowith the world, you know manipulating the world or solving a problem.And urn my real interest these days, my particular research interest is inwhat are for me socially relevant applications of knowledge systems andAI. I did a research project last year for Mac Blo, research in which Ideveloped a knowledge system for treating pulp mill effluent. And ofcourse there's the genetics problem and I'm particularly interested in thesetypes of applications of the computer. Urn now, what else do I enjoy aboutcomputing, or what attracts me to it? Uh, part of it is urn, I guess anabstract esthetic quality similar to urn in mathematics, if you likemathematics, and if you've ever seen a beautiful theorem or a proof orsomething, there can be a sense of pleasure in uh the esthetic beauty ofthat. And it's similar in Computing Science for me. And in fact there's acorrelation in my mind and in my emotions between the sense of pleasureI get and the esthetic qualities of the language. And the esthetic qualities ofthe language to my mind are influenced by the urn uh by how closely thelanguage is build on some type of theoretical basis or is consistent to sometype of theoretical basis. For example, SQL is a very simple language andthe relation and model are very simple, but they're built on a very simple,you know, framework of like the predicate calculus. And it's consistent, itis ... and there's a beauty in it to me for that. Uh Object-oriented languages,Smalltalk in particularly, is completely consistent to the object paradigm,which is built on a sort of a consistent view of the world of class hierarchyand inheritance etc. and so there's a ... I find an esthetic beauty in that.Prolog, consistent to the logic programming paradigm, same thing. Andother languages which are more murky, be it and just are built to get thejob done, be they PL/I or FOCUS or LISP or whatever, I have a, like a sort ofdegrading level of esthetic beauty associated with them in my, in how Irespond to them.D: Yes. What do you dislike about programming?K: Urn I dislike programming languages which make it difficult to achievesome functional goal. For example, if I wanted to write a GUI and thelanguage either had the facility, but it was very awkward to use, or didn'thave it, that would make me dislike it. That's sort of a very feature-levelthing though so ...What Teachers Know About Programming^ 204D: YeahK: In a, in a general way, urn programming requires urn mental activity of acertain nature, intellectual activity and I'm aware that mind orconsciousness can operate in different modes. It's possible to be in a state ofawareness or consciousness in which there's, you're aware of the presentmoment, you're aware of your bodily sensations and emotions etc., you canrespond and talk, but there's not a lot of intellectual mental activity goingon. Programming and intellectual thought require a movement of themind in a particular way. And if I do that too much - thinking - um I'll getmentally fatigued and urn won't experience the same level of bliss andhappiness which I can experience say through urn being having lessmental activity. To put it another way, if I meditate a lot and experiencemental stillness and quiet regularly, a sense of peace and joy will arise inmy spontaneously and I'll feel a sense of integration and wholeness.D: mm-hmmK: And um the more I engage in continuous mental activity, say from themoment I wake up til the moment I go to bed every night, the more I feelI'm out of touch with feeling joy, peace, or a sense of integration. So what Idislike about programming is uh that it can urn it can create too muchmental activity in and not feeling completely integrated emotionally,mentally, spiritually.D: So those components are missing.K: It doesn't have to, I mean like it's a matter of, a matter of balance ...D: Ok, yeahK: But, but but programming and mental activity in general is something ifyou do all the time, I would not be in the optimal spiritual emotional statethat I'm capable of being in.D: RightK: Because to be there I also need to do things like physical exercise andspiritual exercise in order to be peaceful and healthy.D: Mm-hmm. Anything else that you don't like?K: Uh, as I become more skilled over the years, uh I dislike doing work whichis trivially easy for me.D: YesWhat Teachers Know About Programming^ 205K: It's very difficult for me to find any programming problem now whichrequires any effort on my part intellectually. Um the only area in which Ifind that now is Artificial Intelligence, which, in my opinion, contains themost difficult and challenging and interesting problems in programming,Computer Science and um so this is nothing to do with programming, butabout the nature of, you know, programming work, and that is that uhthere's less challenge as the years pass in a lot of the work.D: yeah. limm. OK. I've written down some of the languages that you havementioned. I don't know if I've got all of them.K: If you were to list a language,D: YesK: I probably know it.D: OK. OK. These are the ones that you've mentioned. Now I didn't putdown the 4GLs and stuff. I don't know. Maybe you want to. So I'll putFOCUS and we can think about whether we want to put other things onhere. What I would like ...K: Uh you know all like it would almost be better by exception to list alanguage that I don't know. Snobol, COBOL, I know a lot of them.D: OK, well, let's put down duh duh duh we've got APL, Smalltalk, LISP ...K: And I'm aware from, I'm aware from knowing a wide variety of languagesthat there are major paradigms in how to approach programmingproblems. And I'm familiar with those paradigms and I'm able to comparethem in my mind. Like I'm familiar with the difference between an object-oriented paradigm and a logic based paradigm or a procedural paradigm.D: OK. Maybe rather, so what I was going to ask you to do was classify theselanguages.K: Mm-hmm.D: If I were to ask you to do that would you classify them paradigmatically.K: Yes.D: OKK: That would be ... that's one way of looking at them. There's a few otherways you could look at them as well.What Teachers Know About Programming^ 206D: OK. Let's Ok. So paradigmatically, what other ways might you be temptedto classify, if say you had to just pile ...K: Oh, urn, um 4, a lot of 4GLs and DBMS tools urn sort of have a proceduralflavour, but these days, but they also um they increasingly have a, like a,um, how would I call it, almost an active data dictionary approach toprogramming where maybe a data modelling paradigm? Like where forexample if you're developing some type of a relational uh database withtransaction processing applications, it would be as simple as defining therelational model, the tables, and then say attaching, you know, like uhvalidation routines to the different urn fields in your database, all at like anactive data dictionary level and then you just ask it to generate screens thatum, you know, do transaction processing for you and that everything elseis built in. That's, you know, only vaguely procedural. It's almost as that'sa paradigm in itself. It's kind of. .. It has a sort of a flavour of the object-oriented paradigm, but not quite.D: KayK: Call it a data modelling paradigm.D: Yeah I've actually seen ...K: Or even ???? engineering paradigm.D: Do I have that text? No. There are actually texts that separate it that way.K: YeahD: That put it in a data ...K: and that urn is is like the de facto standard paradigm for a lot of likebusiness development tools these days and rightly so because it's anextremely effective and quick way to develop simple business applicationsfor transaction processing and supporting. So there's maybe that as aparadigm as well.D: OK, yeah. So let's get back to this paradigm.K: YeahD: So you're saying there's um object-oriented, procedural, logic,K: Logic, logic programmingD: Yeah. Urn maybe this data driven modelK: YeahWhat Teachers Know About Programming^ 207D: Can you define those first 3 ... in five words or less, no.K: Ha ha ha ha Uh the logic programming paradigm is based upon uh tryingto represent things in something like first order logic, the predicate calculusD: YesK: Urn with extensions urn with like in the case of Prolog with particularextensions, almost procedural extensions which you need to understandsuch as backtracking, such as um that the order of dauses is chosenaccording to the order that they're typed in.D: Yeah yeahK: Urn things of that nature.D: OK So you say it's basically logic but there is there are extensions.K: Basically the predicate calculus with certain extensions you need tounderstand like backtracking.D: OKK: UmD: Are there other examples of logic programming besides Prolog? Of logicprogramming languages?K: There are other logic programming languages, but I haven't worked inthem and they don't come anywhere close to Prolog in terms of popularity.D: OKK: Um, uh the procedural paradigm is one in which you basically urn arespecifying a series of actions, urn and that's how you would ... to me aprocedural language is one in which you you view that you've got urncontrol structure, uh functions and procedures and uh you and a programis made up of a series of statements which are executed in sequence inwhich the actions are performed in the series in which the functions andprocedures are called.D: Mm-hmmK: Urn the object-oriented paradigm is one in which you view your data andthe procedures as bound together into single entities called objects and uhin which there are qualities such as urn all objects are organized into ahierarchy of class, class definitions which have the properties ofinheritance for example.What Teachers Know About Programming^ 208D: Mm-hmmK: And it's a it's a urn it's a paradigm which reflects a very common whichreflects um a common way that people think about a lot of the world.D: YeahK: If you were to look into ways people think about the world in terms ofgeneralization, specialization or whole/part categories, these are thingswhich are fairly naturally reflected in the object-oriented model.D: Mm-hmmK: And um and besides that, in the object-oriented model you view programsas involving the passing of messages.D: YesK: The sending of messages.D: How do you view things like C++ or object Pascal or ...K: As object-oriented languages.D: Yeah?K: Yeah. I mean the fact that you kind of drop out of the object-orientedmodel and go into the procedural to me just means that, you know, youcould define that as a hybrid language in which you can work in the object-oriented paradigm or the procedural paradigm. Yeah. There are someother paradigms, you know, I must admit, like there's the pure functionalparadigm, functional programming. LISP is not a functional language, butyou could program in LISP as though it were a functional language. Inother words you can limit the programming to a subset of pure functionalprogramming.D: OK. What makes it not purely functional?K: There is constructs in LISP, urn, that fall outside of the functionalprogramming paradigm and by this I mean it like in the mathematicalsense. Um in old LISP there were like were control constructs that felloutside of the urn uh functional paradigm.D: Like ...K: Uh1D: Like loops and stuff?What Teachers Know About Programming^ 209K: like the go like the go statement,D: Oh, OKK: There were loops. Urn what are some other examples? Macros don't...LISP, Common LISP macros don't really belong to urn uh to the uhfunctional paradigm. That's another example.D: So ... I'm hearing you when you say Prolog, when you talk about Prologand you said it was um logic with extensions that are procedural, is that thesame sense with LISP, it has functions, but ...K: No, no, Prolog's extensions aren't procedural. Prolog's extensions are arethings like the fact that it backtracks.D: YeahK: Urn it I don't know how to characterize that, like into a into someparadigm.D: OKK: UmD: Sorry, I guess I'm, somebody else said something like that to me andK: YeahD: I'm putting words in your mouth.K: It has, I mean there, you know, besides thinking of it as just representingthe predicate calculus, it has other features as a programming languageD: OKK: But I wouldn't necessarily call them procedural features, it's just ...D: other featuresK: Other features (we laugh)D: Yeah. Kay. Other. MiscellaneousK: Yeah urn now another way of programming which I'm pretty familiar withand I'm not really sure how to classify it is rule-based programming. Urnwhich has uh some analogies to kind of like logic based programming, butit's not quite the same thing. Cuz when I think of logic programming, I'mWhat Teachers Know About Programming^ 210thinking definitely of something that's quite related to the predicatecalculus.D: yeahK: But when I think of rule-based programming, I'm thinking about beingable to define um discrete independent rules or constraints urn which arethen processed through some type of an inference engine.D: Mm-hmmK: Be it backward, forward or a constraint based engine.D: YeahK: And in rule based programming similar to logic programming I'mfocusing on urn like the specification of relationships or the specification ofconstraints as opposed to any as opposed to any procedural uh definitions.D: Mm-hmm mm-hmmK: So perhaps rule-based programming is is another paradigm.D: KayK: And of course I have experience in it urn in Prolog, cuz you can do likerule based programming in Prolog and also in Expert System shells whichI've worked in.D: Mm-hmm Mm-hmm Do you have a favourite language?K: Yeah, it uh probably Prolog.D: Mm-hmmK: Maybe Smalltalk. It's a toss-up between those two. They're very differentlanguages and you can do you know some things you can do very easily inone and vice versa.D: Kay. What makes them your favourites?K: What makes Prolog my favourite for and, and they're favourites fordifferent reasons.D: KayK: Smalltalk is my favourite in being able to do graphical user interfaces andin probably for like sort of general purpose programming problems. It'sWhat Teachers Know About Programming^ 211extremely flexible and versatile and it doesn't get in the way. Somelanguages for difficult problems have a quality where they don't scale upvery well? For more difficult problems?D: What do you mean? Scale up?K: Urn, they may appear to solve the problem adequately without too muchprogramming effort for a small case or a small problem. But when you tryto scale up the problem or extend the specifications, the functionalspecifications, it starts to be very unwieldly [sic] to develop the code and dothe design.D: Mm-hmm. Urn can you give me an example of a language where thatwould be the case?K: It's nothing, it's nothing inherent about the language, it depends on theparticular problem.D: OKK: Urn but I could think of languages, classical languages like C or Pascal,where if I wanted to do a sophisticated knowledge system, s... knowledgesystem, uh it might not work for a knowledge system which had a lot ofbells and whistles in it.D: yeahK: You might take, be able to take one little specific functional spec in that andbe able to do it, but when you start to having to create a bigger system, itstarts to become very unwieldly in design and in code.D: Mm-hmmK: But Smalltalk, I've had the experience that it, it scales up to bigger problemseasily, you know, you don't feel like you're fighting with it, that it's gettingin your way.D: Mm-hmmK: That in some way that way of representing things in the object-orientedway, it it continues to extend and support you as you're going into bigger,bigger problems.D: Mm-hmmK: Um and I like Smalltalk because it's got a tremendous amount of built incode.What Teachers Know About Programming^ 212D: YesK: Urn and the code is organized in a logical way in the class hierarchy. Urn itseems to me that one of the things that we really need in programming isto be able to reuse code and to be able to buy like off the shop shelf softwarecomponents. Urn there's no need in writing a piece of code thatsomebody's already written somewhere else before.D: Yes.K: And so then the problem becomes OK, imagine that there are hundreds ofthousands of identifiable components of software. How can you organizethem in such a way that you know they're not like sorted alphabetically or(we laugh) or something like that, some useful way to organize them?D: YesK: Well, the object-oriented paradigm provides an answer to that. The object-oriented paradigm provides a way for organizing literally hundreds ofthousands of comp... you know software components in a way that you canbrowse through it and use them and manage that level of complexity andsize.D: Mmm. Mm-hmm Mm-hmmK: And no other paradigm comes close to that or handles that at all.D: YeahK: So Smalltalk comes in with like a thousand, 1500 built in methods andthat's a lot of functionality. Then on top of that, the third party productsyou can buy for Smalltalk or C++ or any object-oriented language um justsupport that same view. You're just like adding a whole bunch of smallsoftware components and it's like you've got like a big library of softwarecomponents you can then build your code up with so that I can focus onjust what's new in my application, what's original and use existingcomponents to support everything else. And that's what I like about thelanguage. So, if I were to think about it abstractly, it's two things. One, it'sthe object-oriented paradigm as a way to model the world and that hassomething to do with the scale up thing I was talking about.D: YesK: The, because the paradigm follows in some way the way we think about theworld, urn and its consistency, that that paradigm's modelling capabilitiesare supportive of development. And the other is that it supports largeamounts of libraries of code. Those are the two things I like about it.What Teachers Know About Programming^ 213D: And Prolog?K: Oh, and I like the development environment.D: OK, YeahK: Prolog, I like for AI programming. Um in AI programming you often haveto look at very sophisticated algorithms that involve pattern-matching orideally backtracking or in which you're developing very rich complex datastructures and Prolog as a language supports the creation of algorithms andcomplex data structures and their manipulation really easily and elegantly.It's been my experience, I've done like say the same functional problem indifferent languages sometimes. It's been my experience that in Prolog thesolution is like profoundly smaller in terms of lines of source code and hasan elegance or a clarity to the design that is greater than any other languagethat I've worked with.D: Mm-hmm Mm-hmm Just checking how much tape we have ... Howmuch tape is there? Little, OK.K: So if I want to represent things symbolically.D: YesK: If I want to represent knowledge symbolically or or do reasoning orinference symbolically, Prolog really supports that easily.D: Mm-hmm Mm-hmm Kay yeah Yeah, It's been about 50 minutes so I'vefound this gets too tiring as you start to get towards an hour.K: YesD: So um. That's all the questions I have to ask for now. Is there anythingthat you're thinking "Oh I didn't mean that" or orK: Ha ha haD: or "I need to revise what I said" or anything you want to ask or mention?K: N oD: OK Good. So what I will do then is transcribe this and next week comeback, it was next week we planned I thinkK: Let's lookWhat Teachers Know About Programming^ 214Tape stop/startK: Repeat thatD: Just repeat what you just said.K: So why I why I chose Computing Science was was for practicalconsiderations, for a job and I thought it sort of met my interests in a vagueway, but why I stayed in it is because of um a genuine uh enjoyment withurn with programming as an experience. It's creative, it's practical, urn I geta gee whiz effect, you know, from doing something with a program. Anduh the technology both in software and hardware are changing fast and Ifind change stimulating.D: Yeah YeahK: And urn sort of like related to finding an esthetic beauty in urn like in sayurn a mathematical proof, if I were to, for example, study how a particularnatural language processing AI algorithm is done, urn, I get a sense ofesthetic beauty in the solution and how they've done it.D: Mm-hmmK: And I like that and it keeps me in intellectual stimulation.lD: Yeah. Me too.What Teachers Know About Programming^ 215

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
http://iiif.library.ubc.ca/presentation/dsp.831.1-0086491/manifest

Comment

Related Items