Should we teach students to program?

  • Published on
    14-Feb-2017

  • View
    212

  • Download
    0

Transcript

  • Log On Education

    Should we Teach Students to Program? M y mother made me Michigan has devel- take Latin when I was in high school. She said that learning Latin would help me learn other languages, and in addition, it was an excellent intel- lectual exercise. In retrospect, I think my mother's claims were a bit exaggerated. That said, there is a germ of truth in the folk wisdom: Latin is the basis for many languages, and be- sides, I got to use the car on weekends!

    C o m p u t e r pro- g r a m m i n g was/ is claimed to be the New Latin. Respected folks such as S e y m o u r Papert and Alan Kay argued that in learn- ing to program one l ea rned powerful problem-solving/de- sign/thinking strate- gies. The procedural thinking embodied in programming gives concreteness to ab- s t ract ideas (e.g., instead of teaching that a function is a mapping from a domain to a range, whatever that means, students learn that a function is a machine that transforms an input, in specified ways, to an output); more personally, I really learned what proof-by-induction was when I wrote recursive Lisp programs.

    At the National Science Foundation in the Advanced Applications of Tech- nology (AAT) Program, a number of researchers have explored different methods for teaching introductory programming. John Anderson and colleagues at Carnegie Mellon Univer-

    sity, for example, have developed computer-based tutoring programs that can teach students beginning Lisp quite effectively. In Pascal program- ming Mike Clancy and Marcia Linn at UC Berkeley have developed a case- based textbook that is effective; Phil Miller and colleagues at C M U have developed an effective computer-based Pascal tutor (GENIE); my group at

    Elliot Soloway

    oped a compute r - based environment, the Goal-Plan-Code Editor, that permits the low-end achievers to perform as well as the high-end achievers. While the details of each approach are interesting, the bot- tom line is this: yes, s tuden ts can be taught to write shor- tish programs (10-100 lines) in introductory programming.

    Now for the hereti- cal question: Should all students learn to program? Ignore for a moment those stu- dents who wish to major in computer science; yes, they should learn to pro- gram in school, but for them, learning to p rogram is simply vocational training. W h a t abou t the masses taking com- puter literacy courses and struggling with those pesky semi- colons in Pascal, or wr i t ing spaghet t i

    code in Basic? Just because we can teach in t roductory p r o g r a m m i n g more effectively, shouldwe subject non- majors to programming?

    To get the dialogue going on this nonprovocative question, I have asked a number of researchers in the AAT Program to give their opinion.

    ElliOt Soloway and Mark Guzdlal, University of Michigan No, we should not be teaching the likes of Pascal, Basic, Lisp, and Scheme to nonmajors. Attempting to

    C O M M U N I C A T I O N S OP T H | A~M October 1993/Vol,36, No.10 ~ 1

  • Log On Education

    learn programming in those general purpose ]programming languages (GPPL) won't be effective in achiev- ing the real goal: empowering stu- dents to manipulate, on a routine basis, computational media. As com- puter notebooks--not notebook computers---become as integral to our material culture as pen and paper, students will be composing and sharing interactive, multiple- media, documents. As was argued in the May 1993 "Log on Education" column, this transformation from static documents to dynamic docu- ments is already taking place in schools (as, indeed, it is happening everywhere else).

    Learning to express oneself in a GPPL, as they are currently con- ceived, requires a steep learning curve: writing a 100-line program is much harder than writing a 10-line program; writing a 1,000-line pro- gram is much, much harder than writing a 100-line program. And, let's be honest, to make the computer truly sing and dance, one needs to write significantly sized programs. What practical program can some- one who finishes--even successfully-- Computer Science 101 actually write?

    Current GPPL s still suffer from a historical accident: computers were initially used for solving a certain class of malLhematical problems. Pas- cal is simply a computer scientist's cleaning up of Fortran. Computer Science 10][ starts with integers and real numbers; f rom there, it's a long, long way Io creating a simulation program a la SimCity! Moreover, the control structures are meant to spec- ify deterministic algorithms; the real challenge i,.s supporting students in exploring open-ended problems that require opportunistic algorithms. As long as GPPLs tie themselves to their mathematical historical roots, they will offer precious little to those who want to manipulate the range of computational media.

    Rather than teach a GPPL, we be- lieve that in order for students to manipulate computational media students need to learn design strate- gies for specific domains; they need to be supported in this endeavor by domain-specific, scaffolded, c o m -

    puter-aided design (CAD) environ- ments. Our position is motivated by observing what nonprogrammers are doing with computational media right now. Millions of professionals are routinely juggling computational media without knowing a while loop from a repea t loop.

    For example, in creating an illus- tration, a graphic artist working in PhotoShop applies domain-specific operations (e.g., filter, rotate) to domain-specific data structures (e.g., image components); he or she might name and save that particular se- quence o f operators to apply later to the same illustration or to other evolving illustrations. In effect, the artist is the control structure; the art- ist can't possibly be expected to work out ahead of time the conditions under which operations should be applied; rather, the artist is working opportu- nistically, deciding in real-time which transformation has the "right" im- pact.

    Similarly, in Emile (created by Mark Guzdial for his dissertation re- search), students construct micro- worlds to explore concepts in phys- ics. Emile is scaffolded; it helps physics learners to create compara- tively complex designs by providing a library o f domain-specific, reusable components, and by guiding stu- dents through the microworld design process. In using Emile, students learn physics as well as design strate- gies for creating physics micro- worlds.

    In ScienceWorks, a successor to Emile, students will move even fur- ther away from programming: rather than composing textual strings, students will directly manip- ulate graphical objects in order to construct SimCitylike simulations. Since Emile & ScienceWorks do not have the Turing expressiveness of a GPPL, students can, in principle, hit a ceiling in what they can construct; however, for all practical purposes, the limiting factors are their imagi- nation and their mastery o f the req- uisite design skills.

    In sum, then, we see students ex- ploring subject domains using com- putational media in much the same way as do nonprogramming, domain professionals: rather than learning a

    GPPL, which will enable them to cre- ate toy artifacts--at best, students need to learn design skills in a do- main, where they are supported by a scaffolded CAD environment.

    MiChael Clancy and Marcia Llnn, University of California, Berkeley Yes, teach programming. Soloway asks "should we teach programming to the masses?" We say, yes, with case studies. Soioway and Guzdial recom- mend teaching students to use do- main-specific CAD objects so they can use computers in a discipline such as mechanics. We say, use a lan- guage like Lisp that supports the def- inition of such objects, and addition- ally allows all the advantages of a high-level programming language.

    Learning to program benefits everyone. Programming is ubiqui- tous in modern society; we use spreadsheets, databases, and even expert systems as a matter of course. Programming courses communicate the powerful, foundational models for these applications. Programming courses create "power users" of ap- plications and a receptive audience for the technology of the future. These courses also attract talented students who will develop the inno- vative applications that our complex society continues to demand.

    Students at U C Berkeley under- stand this message. Already over half the student body learns some pro- gramming. Over one-third o f Berke- ley's business majors choose a course in Lisp programming over an appli- cations course to satisfy their com- puting requirement.

    Instead o f rejecting programming courses, we advocate improving pro- gramming instruction with case stud- ies. Case studies ensure that students become power users and innovative developers. Case studies engage stu- dents in solving large, complex prob- lems right from the beginning of the course. They communicate expert concepts o f computer science, such as recursion. They help students learn to design objects for solving problems in domains like social sci- ence. They help students distinguish alternative paradigms such as func- tional and object-oriented ap-

    22 October 1993/Vol,36, No.10 C O M M U N I C A T I O N S O l U T H E A I M

  • Log On Education

    proaches. They make evident the fun of programming. They incorporate cognitive research by scaffolding stu- dents as they design long, complex programs. Finally, case studies guar- antee better teaching, which attracts and sustains a more diverse student body.

    Programming courses are even better when they teach a suitable high-level language. Our introduc- tory courses use Lisp. We agree with both Soloway and Miller that a suit- able language provides high-level operators. We agree with diSessa that ideally the high-level operators should be easily decomposed into other language primitives. We addi- tionally believe that the language should support multiple paradigms.

    Lisp is better than environments like Emile since students can (a) ex- plore the high-level operators rather than treating them as black boxes, (b) solve problems in science as well as other disciplines, and (c) learn complex concepts like recursion and functional abstraction. In addition, a high-level language allows students to hone their skills in testing and debugging.

    We believe all students will benefit from programming courses as long as they are taught effectively. This means using case studies. (For exam- ple, we recommend Designing Pascal Solutions, by Clancy and Linn, W. H. Freeman, New York, 1992.) It works for our students; Berkeley nonma- jors, by the end of our introductory course, produce bug-free projects consisting of several pages of code.

    Andrea dlSessa, University of California at Berkeley The Boxer Project at UC Berkeley is dedicated to turning computers into true "computational media" in which all sorts of people do all sorts of things to achieve their intellectual and practical goals. We believe com- puters can build on, and dramatically enhance, written text to become the basis for a genuine new literacy. We don' t mean a "toy" li teracy-- inserting disks, being "familiar with" some important applications. We mean a real literacy, complete with art forms and other genres that allow people to do and think things they

    could not without the medium. We have used our prototype medium (called Boxer) to teach new things (fractals and the mathematics of in- finity) to younger children (e.g., a year-long physics course for 6th- grade children) and in ways more enjoyable or simply not possible with other media (e.g., capitalizing on children's surprising expertise in vis- ualization).

    Programming, in this context, means fully controlling the dynamic and interactive components of our new computational medium. We must have programming, in one form or another, or we will have cut off half the power of the medium-- l ike reading without writing. I warn against the illusion of "program- mingless" computational medium that Soloway and Guzdial advocate. The fundamental fact is that "pro- vided resources" never do all and exactly what you need. We must give ordinary folks true combinability and modifiability. Programming is the name of those capabilities, and any- thing short of that will suffer serious limitations.

    Creating a computational medium requires three things, two of which were listed by Soloway and Guzdial. First, it requires making program- ming easier to learn and do. This is obvious, but it is important that we are making progress. Most of our 6th-grade students were capable of producing 100-box (rough equiva- lent of "lines") programs. Some pro- duced programs as large as 500 boxes. On the other hand, measuring accomplishment by lines of code or boxes smacks of the kind of narrow view on programming we must es- cape. We've documented children learning Newton's laws by designing a three-box program.

    Second, a computational medium also requires expressiveness and use- fulness. Most current languages were simply not designed keeping in mind that people might use them every- day, as a medium. Boxer (and some other modern systems) makes impor- tant progress here too. For example, even before you program in Boxer, you can use it as a rich hypertext pro- cessing system.

    Finally, in approaching computa-

    tional media, programming needs to climb out of the "vocational ghetto" that it is stuck in. Lisp and Pascal are the creation of people interested in doing computer science and instruct- ing new computer scientists, not in broad, socially sanctioned intellectual advances for everyone. One of our proudest achievements with Boxer is the creation of classroom communi- ties that work by sharing ideas and artifacts ("Log on Education," May, 1993). The power of a genuinely computer literate culture has sur- prised even us, and we should get on with the task of fostering such cul- tures as much as "teaching programming."

    Phil Miller, Carnegie Mellon University War and battle! Fundamental dichot- omy! Startling juxtaposition! Teach- ers of computer programming are moving in two irreconcilable direc- tions. At once we have the glacially slow, glacially inevitable emergence of C as the common language for programming instruction and simul- taneously the observation that pro- gramming instruction is being and should be supplanted by direct ma- nipulation, visual, end-user pro- gramming. The former appeals to the barbaric programmer; awakens the primordial urge to code down to the silicon; gets the real stuff of pointer arithmetic coursing the veins of adolescent innocents. It kicks sand in the face of 20 years of program- ming methodologies, prissy abstrac- tions, representation, type systems, and correctness. It revels in power, ubiquity, and speed. The latter, gen- trifles programming, tips its cap to the real help people derive from computing, sees a role for sanitized programming in " . . . learning to explore models via the creation of microworld simulations . . . ' ; molds computing into environments that nurture student creativity as they make science their own--but , it cer- tainly doesn't want to get program- ming all over its shoes by stepping into a pile of it.

    The dichotomy is false. Program- ming is here to stay and program- ming will be stretched, sanitized, tai- lored, and generally subtended to

    ONIWUNIICJlLT|ONS OP qrHII AI~I October 1993/Vo|.36, No.J0 ~

  • Log On Education

    the needs of countless disciplines and activities. People who program are empowered. Programming in a lan- guage that is implemented on every commonly used platform and oper- ating system is perhaps the only way to ensure that good software doesn't live and die with particular machines and development systems. Learning to program in the dominant idiom makes it easy for students to study, understand, and extend exciting software artifacts. It also makes those students very useful to the world's techno-economy. But, teaching pro- gramming as an end in itself, as a set of papal encyclicals to be memorized then scrupulously applied is going nowhere. Such instruction is not in- teresting. It is less learnable and less useful than programming embedded in a rich cognitive context.

    At Carnegie Mellon we have had great success in teaching program- ming, Computer Science 101 for heavens sake, by using programming to support other activities. We have had success for a number of years teaching automated kitchen layout software to architecture students. More recently the creation and ma- nipulation of artificial life micro- worlds for students of science and engineering has been the vehicle to get students beyond the usual end- point. Instead of ending with recur- sion, linked-lists and trees, students take themselves through object- oriented programming at the level of extensive subclassing of the object hierarchy, the creation of new and complex data representations, and the methods that operate on them. By mixing real programming with real context:, by hiding irrelevant de- tail, by folding in a heaping helping of multimedia simulation environ- ments, and by putting students into the driver's seat with teachers along for the ride, we're getting back to something Alan Perlis noticed a long time a g o i p r o g r a m m i n g is fun.

    Mitchel Resnick and Seymour PapeR, MIT It's not surprising that many people are starting to question the value of learning computer programming. Schools have done to programming what they have done all too often to

    other subjects: they have made it iso- lated and disconnected. In most schools, p r o g r a m m i n g is discon- nected from other subjects (the "pro- gramming class" is separate from other classes), disconnected from students' interests (a typical assign- ment: write a program to generate prime numbers), and even discon- nected from other computer activi- ties (writing programs and using applications are viewed as totally sep- arate activities).

    The sad state of programming in schools doesn't mean we should do away with programming in educa- tion. Rather, it means we need to fundamentally rethink how we intro- duce programming to students.

    We can gain some insights from recent changes in the teaching of reading and writing. During the past decade, educators have shifted away from basal readers and workbooks, toward a "whole language" ap- proach, in which children read books connected to their interests, and they write stories as part of integrated and meaningful activities.

    Similarly, schools should adopt a "whole programming" approach. Students should write programs as a way to explore, experiment, and express themselves. In our research project, for example, elementary school children write their own video-game programs. Children also write programs to control machines they've built out of Lego bricks: one child built a "chocolate-carob" fac- tory and wrote a program to operate the factory.

    These types of activities require new types of programming tools. To- day's programming languages too often violate the dictum that "simple things should be simple, and com- plex things should be possible." We need new programming paradigms. For example, parallel programming languages can make it much easier to create a video game, or control a Lego factory. In the computer- science community, parallelism is viewed as an "advanced" concept, but children need it more than anyone (and are shocked to find that tradi- tional languages don' t allow it). In our research, we have developed sev- eral parallel programming languages

    for precollege students, and we have observed significant changes in the ways students use and relate to pro- gramming.

    What will students gain from "whole programming" activities? Educational researchers have found that students learn a great deal when they are engaged in designing and constructing things. And through programming, students clearly gain new expertise in making things. (Of course, students could also use di- rect-manipulation computer applica- tions to make things. But program- ming allows a degree of flexibility that is missing in the fixed menus of standard applications. Ideally, pro- gramming and applications should be integrated together, so that users could get the best of both.)

    Perhaps most important, pro- gramming can deeply affect how people view the world. In recent years, programming-based ideas and metaphors have spread through the sciences and social sciences, changing how researchers think about all types of systems. Because o f program- ming-based ideas, entomologists now think about ant colonies differently, cognitive scientists think about the mind differently, management re- searchers think about organizations differently. When students use our new programming environments, we find that they, too, develop new ways of looking at the world.

    Soloway's Last Words Not surprisingly there seems to be considerable disagreement on what flavor of programming language to teach: graphical language versus not- a-graphical language, Pascal versus Lisp versus Boxer. The religious wars continue. On the other hand, there seems to be general agreement that (1) Guzdial and I are wrong, and (2) programming/s the New Latin; it does enable the learning of various subject areas. Thus, it needs to be better integrated into schooling so as to empower students to "develop new ways of looking at the world." At least my fellow contributors are right on one issue! []

    Elliot Soloway is an associate professor in the depart- ment of electrical engineering and computer science at the University of Michigan.

    24 October 1993/Vo1.36, No.10 O I I M U N I C A T I O l l I O F T N I A l l