diff options
| author | elioat <elioat@tilde.institute> | 2023-08-23 07:52:19 -0400 |
|---|---|---|
| committer | elioat <elioat@tilde.institute> | 2023-08-23 07:52:19 -0400 |
| commit | 562a9a52d599d9a05f871404050968a5fd282640 (patch) | |
| tree | 7d3305c1252c043bfe246ccc7deff0056aa6b5ab /js/games/nluqo.github.io/~bh/elogo.html | |
| parent | 5d012c6c011a9dedf7d0a098e456206244eb5a0f (diff) | |
| download | tour-562a9a52d599d9a05f871404050968a5fd282640.tar.gz | |
*
Diffstat (limited to 'js/games/nluqo.github.io/~bh/elogo.html')
| -rw-r--r-- | js/games/nluqo.github.io/~bh/elogo.html | 452 |
1 files changed, 452 insertions, 0 deletions
diff --git a/js/games/nluqo.github.io/~bh/elogo.html b/js/games/nluqo.github.io/~bh/elogo.html new file mode 100644 index 0000000..b24b355 --- /dev/null +++ b/js/games/nluqo.github.io/~bh/elogo.html @@ -0,0 +1,452 @@ +<HTML> +<HEAD> +<TITLE>The Logo language and the Logo style</TITLE> +</HEAD> +<BODY> +<H1>Symbolic Programming vs. Software Engineering -- +Fun vs. Professionalism -- +Are These the Same Question? +</H1> +<CITE>Brian Harvey<BR>University of California, Berkeley</CITE> + +<P>I was asked to talk about "the role of Logo-like learning of programming in +computer science education." The trouble is that I'm not sure I know what +"Logo-like" means. It's an interesting word; as soon as we hear it, we all +feel as if we know more or less what the person who says it means. We don't +have the same urge to interrupt that we would if someone said, for example, +"recursion-like." But do we really understand each other? It gets a little +fuzzy, for me, when I think about it in more detail. + +<H2>What is a Logo-Like Language?</H2> + +<P>Let me give a couple of examples. First, I notice that in the conference +announcement, the programming language ISETL is considered to be Logo-like. +But in 1976, Seymour Papert dismissed APL, which is in many ways similar in +spirit to ISETL, by referring to "languages of the BASIC/APL/FORTRAN family" +[Pap76]. Logo, APL, and ISETL are all interactive languages that support +recursive functions and are designed around mathematical ideas rather than +around computer hardware capabilities. Logo is different from the other two +in that its mathematics is meant to appeal to young kids, while both APL and +ISETL present a more conventional, adult mathematics. What has changed to +make APL non-Logo-like in 1976 but ISETL Logo-like in 1993? + +<P>As a second example, I'm not sure that my own work, even when I use Logo, +is really "Logo-like." In Seymour's new book he characterizes the spirit +of Logo as a promotion of Concrete Operational thinking from an interim +stage of development, one that should be discarded as soon as possible, to a +mode of thinking that is at least as valuable as Formal or abstract +reasoning, even in adulthood. [Pap93] + +<P>When I read that, I was reminded of the history of the Logo IF notation. +The early dialects of Logo, up to the MIT Logo for the Apple and its +Terrapin descendents, use a BASIC-like IF-THEN notation: + +<P><CODE>IF :X < 0 THEN PRINT "NEGATIVE</CODE> + +<P>I was part of the design team for Apple Logo, the first LCSI product, and I +was, as much as anyone, responsible for the shift to the notation in which +IF is a procedure with two arguments, a true-or-false value and a list of +instructions: + +<P><CODE>IF :X < 0 [PRINT "NEGATIVE]</CODE> + +<P>Our argument was that Logo should have a single, uniform rule for evaluating +expressions: Every expression consists of the name of a procedure, followed +by some number of expressions that provide the arguments. Logo evaluates +those subexpressions, then invokes the named procedure with their values as +its argument values. The advantage of the uniform notation is that it paves +the way to user-defined control structures like + +<P><CODE>WHILE [:X < 0] [PRINT :X MAKE "X :X+5]</CODE> + +<P>But there's no question that the LCSI syntax requires some explanation +for beginning Logo programmers. By making this change, have we put general +rules -- abstract thinking -- above the concrete specificity of IF/THEN? +Was this a non-Logo-like change? LCSI is Seymour's company, and they still +use the newer IF syntax. + +<H2>What is Logo-Like Learning?</H2> + +<P>Both of these examples raise the question of what constitutes a Logo-like +language. I was asked to address a somewhat different question, about +Logo-like learning. But I'm just as confused about what that means. Let me +describe two of my own experiences as a teacher, and let's ask to what +extent each of them is "Logo-like." + +<P>The experience I enjoyed most, and of which I'm proudest, was running a +computer lab at the Lincoln-Sudbury Regional High School, in Massachusetts, +from 1979 to 1982. It was never completely clear what I was supposed to +teach. The principal, who came from a business background, talked about +"data processing." Some of the other teachers had picked up on the recently +invented phrase "computer literacy." Computer science as a high school +subject didn't really exist yet; I was myself most interested in computer +programming, especially systems programming. The students, too, had a broad +range of interests and expectations when they signed up for a computer +course. + +<P>At first I tried offering different courses for students with different +levels of interest, but I soon learned that most students didn't really know +what they wanted until they had some experience within the courses. +(Remember that personal computers had just barely been invented, and most +students had no idea what it meant to use a computer, or to program one.) +I ended up using a self-paced structure, in which there was one course for +everyone, but each student could design his or her own curriculum within +broad limits. Logo programming was one of the options. Every beginner was +required to learn a little Logo and a little word processing; beyond that, +anything was allowed. + +<P>We had a Unix-based timesharing system. At that time, Unix provided +programming languages and application software far in advance of anything +available on personal computers, such as the Apple II and the Atari 800. +Partly because of Unix, and partly because I was spending much of my own +time on system software development, the kids soon got the idea that the +adult programming language was C, and so that's what all of the really +interested students used. C is about as far from a Logo-like language as +you can get! The C programmer deals very directly with issues of data +representation within a computer, such as word length and memory allocation. + +<P>On the other hand, what felt "Logo-like" about this situation was that the +kids were engaged entirely in real work, using the computer for their own +goals and not jumping through assigned hoops. (Some students took on the +task of helping with the school's administrative computing; this work was +somewhat less self-directed, but even more real, than the student-initiated +projects.) A lot of effort went into video games, using the limited +character-based graphics of the VT-100 terminals. One student wrote an +EMACS-like text editor, called JOVE, that's still widely used at Unix sites. +Not all students took to programming, but many more learned to use the word +processing facility for their papers for other classes. (One year I had +three or four students who were also taking a chemistry class, in which the +teacher had said they could bring one page of notes into the final exam. +These students collaborated on designing and printing a page, using the +smallest available font, to cram in all their notes!) + +<P>One reason that Logo itself wasn't popular among these students was the +technical limitations of the facility. Graphics terminals were very +expensive in those days. We did have a few Atari 800 computers that we used +as graphics terminals (Atari Logo hadn't been invented yet), but they could +only handle 40-column text, so they weren't good for much other than +graphics. The Logo interpreter we cobbled together for Unix was very slow. +There was no hardcopy graphics capability. We did also have some Terrapin +floor turtles, but they were unreliable. + +<P>Another Logo-like aspect, however, was the social interaction in the lab. +There was no formal class time; people would come and go to use the machine +or just to hang out. An organization of students took responsibility for +running the lab, and its members were given keys to the room so that they +could use the machine without supervision evenings and weekends. (Nothing +was ever stolen, and there was very little breakage.) Kids set up their own +working partnerships; more experienced kids taught newcomers. Most of my +effort went into this meta-curriculum rather than into teaching programming. +It didn't always go smoothly; there were fights, violations of privacy, and +the like. But we all saw these problems as community problems, not just as +something for me, the teacher, to deal with. + +<P>(To make this focus on community sound a bit more serious, and perhaps more +"Logo-like," let me discuss it in Piagetian terms for one paragraph. By +high school age, kids are supposed to be at the highest stage of cognitive +development, the Formal Operational stage. In a certain sense, there is +nothing more for them to learn, cognitively. On the other hand, high school +kids are still far from the top of the scale in moral development. So it +makes sense that issues of community and responsibility should be central to +their education.) + +<P>To sum up, my high school computer lab felt to me very much a Logo-like +learning environment, although Logo itself was a minor component, and +although many of its characteristics are ones that Seymour Papert lists +as non-Logo-like: the equipment was concentrated in one room, the +curricular focus was on computing rather than on math or other areas, +and the style of work was primarily the formal, abstract, goal-directed +style that Seymour criticizes as male-oriented. + +<P>I currently teach undergraduates at the University of California at +Berkeley. Our introductory computer science course was developed at MIT +[Abe85]; one of the developers is Hal Abelson, a Logo old-timer who led the +first microcomputer Logo development projects for the TI 99/4 and the Apple +II. The course uses Scheme, a dialect of Lisp that's similar to Logo in many +ways. (At Berkeley we've even modified Scheme to add the Logo word and +sentence primitives, so that our students can write Logo-like language +processing programs.) + +<P>Is this course Logo-like? How I feel about that question depends on my +standard of comparison. In a recent paper [Har91] I compare the Abelson and +Sussman course with more traditional, Pascal-based, software engineering +courses; by that standard, our course feels very Logo-like indeed. The +traditional course is full of commandments about programming style, telling +students what they should and shouldn't do. The traditional course must +spend a lot of time on programming language syntax; our (dare I say) +Logo-like language has a simple syntax that takes hardly any instructional +time. Students work on programming projects that are designed to illuminate +big ideas in computer science: ideas that help the students write programs, +rather than abstract theoretical ones. + +<P>But compared to my high school experience, this course doesn't feel +Logo-like at all. The style is very different, first of all. I give +lectures to groups of 300 students. Then the students go to the computer +lab to do their assigned projects, but I'm generally not in the lab with +them. (We do have teaching assistants in the lab at scheduled hours.) +The projects are assigned, rather than student-initiated. + +<P>In the six years I've been at Berkeley, I've taken some small steps toward +a learning environment that feels slightly more Logo-like. For example, +we used to assign weekly homework with exercises from the textbook. Now I +assign the exercises, but don't collect them, so that it's clear to the +students that the exercises are for their own benefit and not for evaluation +purposes. I've instituted cooperative learning, redesigning the programming +projects to be done by groups rather than by individual students. These are +very tiny steps to be discussing at a Logo conference! But they go very +much against the grain of the context within which I teach. The introductory +course is part of a curriculum ladder, and later courses depend on +"covering" the curriculum. The students, in these bad economic times, tend +to be much more worried about competing for jobs than about learning. + +<P>The irony in all this, as we'd expect from our Logo experience, is that the +students who end up doing best, even in the job market, are the ones who can +find the courage to forget about jobs and grades and jumping through hoops, +and treat my course as if it were a more Logo-like environment, getting +excited about the new ideas and pushing beyond the required work to +invent and explore new programming techniques. + +<P>When I was an undergraduate myself, I was lucky enough to fall in with +the gang at the MIT Artificial Intelligence Lab, which was for me the +perfect prototype of a Logo-like environment even before there was Logo. +On the one hand, everyone was engaged in real work, pushing the state of the +art in computing, but on the other hand, nobody felt any pressure about it. +It was all for fun; you could try anything, and if it didn't work out, you +just tried something else. (But don't forget that the hacker spirit at that +lab is also the prototype of the style of work that Papert and Turkle call +androcentric.) + +<H2>How are the Two Related?</H2> + +<P>After this long preamble, I think I'm ready to talk about the question in +the title of this paper. There are two different ways of looking at a +computer science lab that both seem connected somehow to the Logo-like scale. +The more obvious one is about style of work; as I've been saying, from that +perspective, my high school lab felt extremely Logo-like, and my university +course doesn't. This is the question that I've inadequately represented as +"Fun vs. Professionalism" in my title. + +<P>The other is the more technical question about curriculum +and programming language. There is a very sharp distinction between the +software engineering approach and what I think of as the artificial +intelligence approach. In the software engineering approach, students are +being trained primarily to be disciplined in their programming style, so +that their code can easily fit in with other people's code. The curriculum +is full of rules; the programming language used is always one with strong +typing and similar restrictive rules. Software engineers talk about object +oriented programming, for example, primarily as an advance in information +hiding: An OOP language is one in which procedures as well as data have +very tightly limited scopes. The AI approach replaces this moralistic tone +with the cultivation of a sense of wonder at the ways in which thinking +harder about programming can pay off in increased expressiveness. In this +approach, there isn't one correct way to program, but rather a world full of +programming styles and structures, each one appropriate for certain kinds of +problems. On this view, for example, object oriented programming is about a +metaphor, expressing a kind of parallelism in which each datum has its own +intelligence, rather than about discipline. + +<P>This division, the one I've called "Symbolic Programming vs. Software +Engineering," is fundamentally about the philosophy of computer science. +It seems quite different from the question about style of work, but I think +I can find some similarities. + +<P>One difference between a Logo microworld and an ordinary piece of +educational software is that in the Logo version, the program itself is +available for inspection and modification, not a black box. In the study of +computer science, a programming language is itself a microworld. That's why +the Lisp tradition of introducing even beginners to the workings of the Lisp +interpreter is Logo-like: By examining and modifying the interpreter, we +turn the Lisp microworld into a glass box instead of a black box. + +<P>A crucial part of a Logo classroom is that the learners have permission to +explore using their own individual styles. There isn't just one right way +to program. Similarly, in the symbolic programming approach to teaching +computer science, there is no orthodoxy about top-down structured +programming. Top-down is one fine approach, but so is tool-building without +a specific goal in view. + +<P>Symbolic languages, and languages with relaxed attitudes toward data types, +allow for programming projects about sentence generation, carrying on +conversations, the automated psychotherapist, and so on. These projects are +very much in the Logo tradition, and in contrast with the heavy emphasis on +numeric computation that's typical of the software engineering languages. + +<H2>Logo-Like Languages Revisited</H2> + +<P>Finding these examples in which the technical details of a programming +language and a curriculum seem to be connected with working in the Logo +spirit gives me the courage to return to the question of languages and hope +that in so doing I'm still addressing the question that was given to me. + +<P>In my 1982 <CITE>Byte</CITE> article, I listed several characteristics that seemed to +make Logo special. [Har82] Let me go through the list and comment on where +we stand in programming languages today. + +<P><STRONG>Procedural.</STRONG> We seem to have won this battle. Even +BASIC, in its modern dialects, allows a modular program structure. In fact, +procedural languages are now the right wing of language design, in contrast +with newer approaches such as functional, object-oriented, and logic +programming. Some recent versions of Logo address the issue of parallelism, +although that newer Logo technology is not yet, I think, widely understood +among the people actually using Logo in schools. + +<P>The issue today that corresponds to the one about procedural programming +languages a decade ago is that many people don't want to deal with languages +at all. Instead, modern software provides a graphical user interface, with +mice, buttons, menus, and so on. Even Logo has not ignored this trend; +LogoWriter on the Macintosh is full of immediate-mode graphical controls for +things like moving and turning the turtle by hand. I think the battle we +have to fight is to maintain the position that immediate-mode control isn't +enough, because it doesn't allow for the abstraction of regularities and +patterns of work. There must be a way to create control structures that can +carry out the same operations that can be performed graphically. + +<P><STRONG>Interactive.</STRONG> This is a crucial issue, and the terms of +the debate have changed dramatically in recent years. Originally, there was +a clear-cut distinction between interactive languages such as Logo, Lisp, +and BASIC, and non-interactive languages like C and Pascal. The style of +work in the non-interactive languages was awful. Programmers had to write +their programs in an environment entirely separate from the language itself, +then go through a compilation process, and finally run the program, often +with no runtime support for debugging or modifying the program. Their +excuse was that a compiled program runs much faster than an interpreted one, +and indeed the Logo interpreters of that time were unpleasantly slow. + +<P>The characteristics of the underlying languages have not changed. But +today's Pascal or C programmer works with an integrated development system. +There is a text editor that understands the syntax of the particular +language, so that it can check the form of a program as you write it. There +is interactive debugging, generally using a window system effectively so +that the debugging information is visually separate from the output of the +program itself. You still can't walk up to a C compiler and ask it to print +2+2, and yet today's C programmers are likely to complain that a Logo +programmer suffers from an insufficiently interactive working environment! +For myself, I still find interaction with the actual programming language +more powerful than these auxiliary interactive tools, but I'm not sure +whether that's just because I'm accustomed to an old-fashioned style of work. +It can certainly be argued that commercially available versions of Logo have +moved backward in their provisions for debugging support; Apple Logo allowed +the user to enable an automatic PAUSE in case of an error, but LogoWriter +doesn't. + +<P><STRONG>Recursive.</STRONG> In the early Logo work, learning about +recursion was a crucial step in intellectual development. Ideas like the +little person model of procedure invocation were invented mainly to help in +understanding recursion. In one sense, this battle seems to be behind us; +every modern programming language allows recursion. But the conventional +wisdom in computer science education is that recursion is too costly for +ordinary use; students are taught to prefer iterative language mechanisms. +Meanwhile, except for drawing fractals, Logo users rarely use recursion in a +way that couldn't be handled by conventional iterative language constructs. +(Indeed, part of my technical work has been the introduction of iterative +constructs to Logo.) I think it's still worth remembering that recursion is +a single mechanism with remarkable expressive power. For example, these +days it's easier to draw a circle in a canned drawing program than in Logo, +because the canned program has a dedicated circle feature; but the drawing +program can't use its circle feature to draw spirals or stars. + +<P><STRONG>List Processing.</STRONG> Logo is still out in front on this +point. Even other dialects of Lisp don't make the manipulation of words and +sentences as convenient as it is in Logo. If you want to conjugate a verb +or take the plural of a noun, Logo is the language of choice. On the other +hand, I think it's still true that most actual Logo users consider list +processing to be arcane and difficult. LogoWriter fans often prefer to +manipulate text by carrying out a sequence of text editing commands on the +representation of the text on the screen, rather than apply recursive +functions to the text taken as data. My hope is that a good collection of +higher-order functions like MAP and FILTER can make list processing seem +more palatable. + +<P><STRONG>Untyped.</STRONG> This is probably where you'll find the most +heated arguments between symbolic programming enthusiasts and software +engineers. The lack of type declarations in Logo, and in Lisp generally, +makes programming enormously easier to learn; the software engineers, +though, think it's sinful. The real argument for typed variables is that +the compiler can produce more efficient programs, but the theoretical +argument is that restricting a variable to a particular type makes for more +disciplined programming. (It also makes for ludicrous user interfaces, in +cases where the natural thing is to read numbers until the user says +something like "DONE" to indicate the end of the numbers. Instead, the +typed languages make the user type something like "9999" or "-1" to indicate +the end.) Some computer scientists will say that the advent of object +oriented programming has settled this question in favor of strong typing, +but the example of Object Logo shows that that isn't so. + +<P><STRONG>Extensible.</STRONG> We are beginning to win this battle when it +comes to application software. Many large programs these days include a +"scripting language," such as Hypertalk as the scripting language for +Hypercard. But mainstream programming languages are not generally viewed as +bases for building language extensions, except in the sense that you can +write a full interpreter or compiler from scratch. This property is still +very important in Logo practice, because it's the technical basis for +microworlds. Any Logo programmer (not just the implementors at the software +companies) can develop an extended Logo with extra primitives for some +microworld. + +<P><STRONG>Interesting Applications.</STRONG> New applications are invented +very fast these days. Logo is in the lead in some cases (robotics, with +Lego-Logo), hustling to catch up in others (MIDI support recently added to +Object Logo), and not really in the running for some (real-time animation, +unless you have a massively parallel computer on which to run *Logo). The +proliferation of special-purpose software tuned to each of these application +areas raises the question of whether we can reasonably expect any +general-purpose programming language to be a good match in every case. In +the old days, the appeal of Logo programming wasn't so much the act of +programming itself as the results you could tease out of a computer; today +you can get more spectacular results without programming at all. This is +why there has been a vast decrease in the amount of time spent on +programming in schools in the past few years; students are using application +programs instead. Is this good or bad? In a way the issue is similar to +the one that we argued about when Sprites were introduced in TI Logo: "It's +too easy to get pretty pictures on the screen in immediate mode, so kids +won't learn to think procedurally." + +<P><STRONG>User-Friendly.</STRONG> In the old days we made a big fuss about +things like the text of error messages and the names of primitives. This +tradition is still alive in Logo; the switch from OUTPUT to REPORT in +LogoWriter is an example. But a new generation of computer users accustomed +to point-and-click interfaces would question the user-friendliness of any +Logo environment. I think we have to admit that Logo syntax, although +better than Pascal, is still far from transparent. Can we develop more +compelling notations without sacrificing the essence of programming? I +guess this is what Boxer is about, in part. + +<P><STRONG>No Threshold, No Ceiling.</STRONG> We are starting to see a +division of the Logo using community. Products like LogoWriter are +deliberately aimed at the young kids who make up most of Logo's actual +audience. Object Logo is a high-end version for more advanced programmers. +I've found it necessary to implement my own version, Berkeley Logo, just so +that there will be a more or less unchanging interpreter for the language +used in my books. In principle I suppose this is a good thing, because it +allows us to extend the limits of Logo usability in both directions. But I +wonder whether Logo's rather small audience can support so many separate +development teams. + +<P>To sum up, some of the technical issues that seemed important a decade ago +in distinguishing Logo from other languages are no longer at issue, such as +procedural organization and recursion. Others burn as brightly as ever: +list processing and untyped variables. Most interestingly, others have +changed into different issues, especially the ones about user interfaces, +such as the definition of interactiveness. + +<H2>References</H2> + +<P>Abelson, Harold, and Gerald Jay Sussman with Julie Sussman. <CITE>Structure +and Interpretation of Computer Programs</CITE>, MIT Press/McGraw-Hill, 1985. + +<P>Harvey, Brian. "Why Logo?" <CITE>Byte</CITE>, vol. 7, no. 8, August, 1982. + +<P>Harvey, Brian. "<A +HREF="bridge.ps">Symbolic Programming vs. the A.P. Curriculum</A>," <CITE>The +Computing Teacher</CITE>, vol. 18, no. 5, February, 1991. + +<P>Papert, Seymour. "An Evaluative Study of Modern Technology in +Education," MIT Logo Memo 26, June, 1976. + +<P>Papert, Seymour. <CITE>The Children's Machine</CITE>, Basic Books, 1993. + +<P><ADDRESS> +<A HREF="index.html"><CODE>www.cs.berkeley.edu/~bh</CODE></A> +</ADDRESS> +</BODY> +</HTML> |