about summary refs log blame commit diff stats
path: root/tools/treeshake_translate
blob: 36fcf7c66dfe6d9c00b73d5d80f1f988ed42997c (plain) (tree) 
c1d596f5 ^







ab837e8f ^

1
2
3
4
5
6
7

8







                                                      
                            
#!/bin/sh
# Translate SubX into minified ELF binaries for Linux.

set -e

grep -vh '^\s*#\|^\s*$' $*  > a.in
cat a.in  |tools/treeshake  > a.treeshake
./translate_subx a.treeshake
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-12-29 01:44:22 +0000
09' href='#n209'>209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 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>
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-12-29 01:44:16 +0000