Should we teach students to program?

  • Published on
    14-Feb-2017

  • View
    212

  • Download
    0

Embed Size (px)

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 compu...