-
Notifications
You must be signed in to change notification settings - Fork 42
/
Copy pathindex.html
2731 lines (2648 loc) · 168 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
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
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>The Early History Of Smalltalk</title>
<style type="text/css">
body {
width:700px;
margin-left:auto;
margin-right:auto;
color:#444;
font: normal 14px/1.45 "Helvetica Neue", Arial, sans-serif;
}
h1 {
font-variant: small-caps;
margin-top:30px;
color:#000;
}
h2 {
font-family: Verdana;
margin-top:100px;
color:#000;
}
h3 {
color:#000;
margin-top:30px;
}
.copyright {
margin: 1em 4em 1em 4em;
font-size: small;
}
.toc {
margin: 1em 5em 1em 5em;
}
img {
margin-left: 10px;
margin-top:10px;
margin-bottom:10px;
}
.rightcolumn {
margin: 0.5em;
padding: 0.5em;
float: right;
border: 1px solid #808080;
}
.dedicate {
margin-left: 70%;
}
div.rightcolumn {
width: 30%;
}
.pendery {
border: 1px solid #808080;
padding: 1em;
margin: 1em 4em 1em 4em;
}
</style>
</head>
<body>
<p align="center"><a href="https://raw.githubusercontent.com/worrydream/EarlyHistoryOfSmalltalk/master/SmalltalkHistoryHOPL-scanned-2015-07-16.pdf">original pdf</a> / <a href="https://github.com/worrydream/EarlyHistoryOfSmalltalk">make corrections</a></p>
<h1 align="center">The Early History Of Smalltalk</h1>
<p align="center">
<i>Alan C. Kay</i><br>
<i>Apple Computer</i><br>
<i>[email protected]#</i>
</p>
<p class="copyright">
Permission to copy without fee all or part of this material is
granted provided that the copies are not made or distributed for
direct commercial advantage, the ACM copyright notice and the
title of the publication and its date appear, and notice is given
that copying is by permission of the Association for Computing
Machinery. To copy otherwise, or to republish, requires a fee
and/or specific permission.<br>
HOPL-II/4/93/MA, USA
© 1993 ACM 0-89791-571-2/93/0004/0069...$1.50
</p>
<h2 align="center">Abstract</h2>
<p>
Most ideas come from previous ideas. The sixties, particularly in the ARPA
community, gave rise to a host of notions about "human-computer symbiosis"
through interactive time-shared computers, graphics screens and pointing
devices. Advanced computer languages were invented to simulate complex systems
such as oil refineries and semi-intelligent behavior. The soon-to-follow paradigm
shift of modern personal computing, overlapping window interfaces, and
object-oriented design came from seeing the work of the sixties as something
more than a "better old thing." That is, more than a better way: to do mainframe
computing; for end-users to invoke functionality; to make data structures more
abstract. Instead the promise of exponential growth in computing/$/volume
demanded that the sixties be regarded as "<i>almost</i> a new thing" and to find out
what the actual "new things" might be. For example, one would compute with a
handheld "Dynabook" in a way that would not be possible on a shared mainframe;
millions of potential users meant that the user interface would have to
become a learning environment along the lines of Montessori and Bruner; and
needs for large scope, reduction in complexity, and end-user literacy would
require that data and control structures be done away with in favor of a more
biological scheme of protected universal cells interacting only through messages
that could mimic any desired behavior.
</p>
<p>
Early Smalltalk was the first complete realization of these new points of view
as parented by its many predecessors in hardware, language and user interface
design. It became the exemplar of the new computing, in part, because we were
actually trying for a qualitative shift in belief structures—a new Kuhnian paradigm
in the same spirit as the invention of the printing press—and thus took
highly extreme positions which almost forced these new styles to be invented.
</p>
<h2 align="center">Table of Contents</h2>
<ul>
<li>Introduction <a href="#p2">2</a></li>
<li>I. 1960-66—Early OOP and other formative ideas of the sixties
<a href="#p4">4</a>
<ul>
<li>B220 File System</li>
<li>SketchPad & Simula</li>
</ul>
</li>
<li>II 1967-69—The FLEX Machine, an OOP-based personal computer
<a href="#p6">6</a>
<ul>
<li>Doug Englebart and NLS</li>
<li>Plasma Panel, GRAIL, LOGO, Dynabook</li>
</ul>
</li>
<li>III. 1970-72—Xerox PARC <a href="#p12">12</a>
<ul>
<li>KiddiKomp</li>
<li>miniCOM</li>
<li>Smalltalk-71</li>
<li>Overlapping Windows</li>
<li>Font Editing, Painting, Animation, Music</li>
<li>Byte Codes</li>
<li>Iconic Programming</li>
</ul>
</li>
<li>IV. 1972-76—Xerox PARC: The first real Smalltalk (-72)
<a href="#p17">17</a>
<ul>
<li>The two bets: birth of Smalltalk and Interim Dynabook</li>
<li>Smalltalk-72 Principles</li>
<li>The Smalltalk User Interface</li>
<li>Development of the Smalltalk Applications & System</li>
<li>Evolution of Smalltalk: ST-74, ooze storage management</li>
<li><a href="#smalltalkAndChildren">Smalltalk and Children</a>
</ul>
</li>
<li>V. 1976-80—The first modern Smalltalk (-76) <a href="#p29">29</a>
<ul>
<li>"Let's burn our disk packs"</li>
<li>The Notetaker</li>
<li>Smalltalk-76</li>
<li>Inheritance</li>
<li>More Troubles With Xerox</li>
<li>ThingLab</li>
<li>Apple Demo</li>
</ul>
</li>
<li>VI. 1980-83—The release version of Smalltalk (-80) <a href="#p38">38</a>
<ul>
<li>Transformations</li>
<li><a href="#coda">Coda</a></li>
</ul>
</li>
<li>References Cited in Text <a href="#p41">41</a></li>
<li>Appendix I: KiddiKomp Memo <a href="#p45">45</a></li>
<li>Appendix II: Smalltalk-72 Interpreter Design <a href="#p47">47</a></li>
<li>Appendix III: Acknowledgments <a href="#p50">50</a></li>
<li>Appendix IV: Event Driven Loop Example <a href="#p53">53</a></li>
<li>Appendix V: Smalltalk-76 Internal Structures <a href="#p54">54</a></li>
</ul>
<div class="dedicate">
<p> —To Dan Ingalls, Adele Goldberg and the rest of Xerox PARC LRG gang </p>
<p> —To Dave Evens, Bob Barton, Marvin Minsky, and Seymour Papert </p>
<p> —To SKETCHPAD, JOSS, LISP, and SIMULA, the 4 great programming conceptions of the sixties </p>
</div>
<h2><a name="p2">Introduction</a></h2>
<p>
I'm writing this introduction in an airplane at 35,000 feet. On my lap is a five pound
notebook computer—1992's "Interim Dynabook"—by the end of the year it sold for under $700. It
has a flat, crisp, high-resolution bitmap screen, overlapping windows, icons, a pointing device,
considerable storage and computing capacity, and its best software is object-oriented. It has
advanced networking built-in and there are already options for wireless networking.
Smalltalk runs on this system, and is one of the main systems I use for my current work with
children. In some ways this is more than a Dynabook (quantitatively), and some ways not
quite there yet (qualitatively). All in all, pretty much what was in mind during the late sixties.
</p>
<p> Smalltalk was part of this larger pursuit of ARPA, and later of Xerox PARC, that I called <i>personal
computing.</i> There were so many people involved in each stage from the research communities
that the accurate allocation of credit for ideas is intractably difficult. Instead, as Bob Barton
liked to quote Goethe, we should "share in the excitement of discovery without vain attempts
to claim priority."
</p>
<p>
I will try to show where most of the influences came from and how they were transformed
in the magnetic field formed by the new personal computing metaphor. It was the <i>attitudes</i> as
well as the great ideas of the pioneers that helped Smalltalk get invented. Many of the people I
admired most at this time—such as Ivan Sutherland, Marvin Minsky, Seymour Papert, Gordon
Moore, Bob Barton, Dave Evans, Butler Lampson, Jerome Bruner, and others—seemed to have
a splendid sense that their creations, though wonderful by relative standards, were not near to
the absolute thresholds that had to be crossed. Small minds try to form religions, the great ones
just want better routes up the mountain. Where Newton said he saw further by standing on the
shoulders of giants, computer scientists all too often stand on each other's toes. Myopia is
still a problem where there are giants' shoulders to stand on—"outsight" is better than
insight—but it can be minimized by using glasses whose lenses are highly sensitive to
esthetics and criticism.
</p>
<p>
Programming languages can be categorized in a number of ways: imperative, applicative,
logic-based, problem-oriented, etc. But they all seem to be either an "agglutination of features"
or a "crystallization of style." COBOL, PL/1, Ada, etc., belong to the first kind; LISP, APL—
and Smalltalk—are the second kind. It is probably not an accident that the agglutinative languages
all seem to have been instigated by committees, and the crystallization languages by a single person.
</p>
<p>
Smalltalk's design—and existence—is due to the insight that everything we can describe can be
represented by the recursive composition of a single kind of behavioral building block that hides its
combination of state and process inside itself and can be dealt with only through the exchange of
messages. Philosophically, Smalltalk's objects have much in common with the monads of Leibniz and
the notions of 20th century physics and biology. Its way of making objects is quite Platonic in that
some of them act as idealizations of concepts—<i>Ideas</i>—from which <i>manifestations</i> can be created. That
the Ideas are themselves manifestations (of the Idea-Idea) and that the Idea-Idea is <i>a-kind-of</i>
Manifestation-Idea—which is a-kind-of itself, so that the system is completely self-describing—
would have been appreciated by Plato as an extremely practical joke [Plato].
</p>
<p>
In computer terms, Smalltalk is a recursion on the notion of computer itself. Instead of dividing
"computer stuff" into things each less strong than the whole—like data structures, procedures, and
functions which are the usual paraphernalia of programming languages—each Smalltalk object is a
recursion on the entire possibilities of the computer. Thus its semantics are a bit like having thousands
and thousands of computers all hooked together by a very fast network. Questions of concrete representation
can thus be postponed almost indefinitely because we are mainly concerned that the computers
behave appropriately, and are interested in particular strategies only if the results are off or
come back too slowly.
</p>
<p>
Though it has noble ancestors indeed, Smalltalk's contribution is a new design paradigm—which I
called <i>object-oriented</i>—for attacking large problems of the professional programmer, and making
small ones possible for the novice user. Object-oriented design is a successful attempt to qualitatively
improve the efficiency of modeling the ever more complex dynamic systems and user relationships
made possible by the silicon explosion.
</p>
<p align="right">
"We would know what they thought<br>
when they did it."<br>
—Richard Hamming
</p>
<p align="right">
"Memory and imagination are but two<br>
words for the same thing."<br>
—Thomas Hobbes
</p>
<p>
In this history I will try to be true to Hamming's request as moderated by Hobbes' observation. I
have had difficulty in previous attempts to write about Smalltalk because my emotional involvement
has always been centered on personal computing as an amplifier for human reach—rather than
programming system design—and we haven't got there yet. Though I was the instigator and original
designer of Smalltalk, it has always belonged more to the people who make it work and got it out the
door, especially Dan Ingalls and Adele Goldberg. Each of the LRGers contributed in deep and remarkable
ways to the project, and I wish there was enough space to do them all justice. But I think all of
us would agree that for most of the development of Smalltalk, Dan was the central figure.
Programming is at heart a practical art in which real things are built, and a real implementation thus
has to exist. In fact many if not most languages are in use today not because they have any real merits
but because of their existence on one or more machines, their ability to be bootstrapped, etc. But Dan
was far more than a great implementer, he also became more and more of the designer, not just of the
language but also of the user interface as Smalltalk moved into the practical world.
</p>
<p>
Here, I will try to center focus on the events leading up to Smalltalk-72 and its transition to its
modern form as Smalltalk-76. Most of the ideas occurred here, and many of the earliest stages of OOP
are poorly documented in references almost impossible to find.
</p>
<p>
This history is too long, but I was amazed at how many people and systems that had an influence
appear only as shadows or not at all. I am sorry not to be able to say more about Bob Balzer, Bob
Barton, Danny Bobrow, Steve Carr, Wes Clark, Barbara Deutsch, Peter Deutsch, Bill Duvall, Bob
Flegal, Laura Gould, Bruce Horn, Butler Lampson, Dave Liddle, William Newman, Bill Paxton,
Trygve Reenskaug, Dave Robson, Doug Ross, Paul Rovner, Bob Sproull, Dan Swinehart, Bert
Sutherland, Bob Taylor, Warren Teitelman, Bonnie Tennenbaum, Chuck Thacker, and John Warnock.
Worse, I have omitted to mention many systems whose design I detested, but that generated considerable
useful ideas and attitudes in reaction. In other words "histories" should not be believed very
seriously but considered as "FEEBLE GESTURES OFF" done long after the actors have departed the stage.
</p>
<p>
Thanks to the numerous reviewers for enduring the many drafts they had to comment on. Special
thanks to Mike Mahoney for helping so gently that I heeded his suggestions and so well that they
greatly improved this essay—and to Jean Sammet, an old old friend, who quite literally frightened
me into finishing it—I did not want to find out what would happen if I were late. Sherri McLoughlin
and Kim Rose were of great help in getting all the materials together.
</p>
<h2><a name="p4">I. 1960-66—Early OOP and other formative ideas of the sixties</a></h2>
<p>
Though OOP came from many motivations, two were central. The large scale one was to find a better
module scheme for complex systems involving hiding of details, and the small scale one was to
find a more flexible version of assignment, and then to try to eliminate it altogether. As with most
new ideas, it originally happened in isolated fits and starts.
</p>
<p>
New ideas go through stages of acceptance, both from within and without. From within, the
sequence moves from "barely seeing" a pattern several times, then noting it but not perceiving its
"cosmic" significance, then using it operationally in several areas, then comes a "grand rotation" in
which the pattern becomes the center of a new way of thinking, and finally, it turns into the same
kind of inflexible religion that it originally broke away from. From without, as Schopenhauer noted,
the new idea is first denounced as the work of the insane, in a few years it is considered obvious and
mundane, and finally the original denouncers will claim to have invented it.
</p>
<p>
True to the stages, I "barely saw" the idea several times ca. 1961 while a programmer in the Air
<a href="Images/b220.png" target="_blank"><img src="Images/thumbnails/b220.jpg" alt="b220 file format" align="right" style="max-width: 228px"></a>
Force. The first was on the Burroughs 220 in the form of a style for
transporting files from one Air Training Command installation to
another. There were no standard operating systems or file formats
back then, so some (to this day unknown) designer decided to
finesse the problem by taking each file and dividing it into three
parts. The third part was all of the actual data records of arbitrary
size and format. The second part contained the B220 procedures
that knew how to get at records and fields to copy and update the
third part. And the first part was an array of relative pointers
into entry points of the procedures in the second part (the initial pointers
were in a standard order representing standard meanings).
Needless to say, this was a great idea, and was used in many subsequent systems until the enforced
use of COBOL drove it out of existence.
</p>
<p>
The second barely-seeing of the idea came just a little later when ATC decided to replace the 220
with a B5000. I didn't have the perspective to really appreciate it at the time, but I did take note of its
segmented storage system, its efficiency of HLL compilation and byte-coded execution, its automatic
mechanisms for subroutine calling and multiprocess switching, its pure code for sharing, its protection
mechanisms, etc. And, I saw that the access to its Program Reference Table corresponded to the
220 file system scheme of providing a procedural interface to a module. However, my big hit from
this machine at this time was not the OOP idea, but some insights into HLL translation and evaluation.
[Barton, 1961] [Burroughs, 1961]
</p>
<p>
After the Air Force, I worked my way through the rest of college by programming mostly retrieval
<a href="Images/mooreslaw.png" target="_blank"><img src="Images/thumbnails/mooreslaw.jpg" alt="Moore's Law graph" align="right" style="max-width: 222px"></a>
systems for large collections of weather data for the National
Center for Atmospheric Research. I got interested in simulation
in general—particularly of one machine by another—but aside
from doing a one-dimensional version of a bit-field block transfer
(bitblt) on a CDC 6600 to simulate word sizes of various
machines, most of my attention was distracted by school, or I
should say the theatre at school. While in Chippewa Falls helping
to debug the 6600, I read an article by Gordon Moore which
predicted that integrated silicon on chips was going to exponentially
improve in density and cost over many years [Moore 65].
At the time in 1965, standing next to the room-sized freon-cooled
10 MIP 6600, his astounding predictions had little projection
into my horizons.
</p>
<h3>Sketchpad and Simula</h3>
<p>Through a series of flukes, I wound up in graduate school at the University of Utah in the Fall of
1966, "knowing nothing." That is to say, I had never heard of ARPA or its projects, or that Utah's main
goal in this community was to solve the "hidden line" problem in 3D graphics, until I actually
walked into Dave Evans' office looking for a job and a desk. On Dave's desk was a foot-high stack of
brown covered documents, one of which he handed to me: "Take this and read it."
</p>
<p>
Every newcomer got one. The title was "Sketchpad: A man-machine graphical communication
system" [Sutherland, 1963]. What it could do was quite remarkable, and completely foreign to any use of
a computer I had ever encountered. The three big ideas that were easiest to grapple with were: it was
the invention of modern interactive computer graphics; things were described by making a "master
drawing" that could produce "instance drawings"; control and dynamics were supplied by
"constraints," also in graphical form, that could be applied to the masters to shape an inter-related parts.
Its data structures were hard to understand—the only vaguely familiar construct was the embedding
of pointers to procedures and using a process called reverse indexing to jump through them to
routines, like the 220 file system [Ross, 1961]. It was the first to have clipping and zooming
windows—one "sketched" on a virtual sheet about 1/3 mile square!
</p>
<a href="Images/sketchpad.png" target="_blank"><img src="Images/thumbnails/sketchpad.jpg" alt="Sketchpad" style="max-width: 692px"></a>
<p>
Head whirling, I found my desk. On it was a pile of tapes and listings, and a note: "This is the
Algol for the 1108. It doesn't work. Please make it work." The latest graduate student gets the latest
dirty task.
</p>
<p>
The documentation was incomprehensible. Supposedly, this was the Case-Western Reserve 1107
Algol—but it had been doctored to make a language called Simula; the documentation read like
Norwegian transliterated into English, which in fact it was. There were uses of words like <i>activity</i> and
<i>process</i> that didn't seem to coincide with normal English usage.
</p>
<p>
Finally, another graduate student and I unrolled the program listing 80 feet down the hall and
crawled over it yelling discoveries to each other. The weirdest part was the storage allocator, which
did not obey a stack discipline as was usual for Algol. A few days later, that provided the clue. What
Simula was allocating were structures very much like the instances of Sketchpad. There were descriptions
that acted like masters and they could create instances, each of which was an independent entity.
What Sketchpad called masters and instances, Simula called activities and processes. Moreover,
Simula was a procedural language for controlling Sketchpad-like objects, thus having considerably
more flexibility than constraints (though at some cost in elegance) [Nygaard, 1966, Nygaard, 1983].
</p>
<p>
This was the big hit, and I've not been the same since. I think the reason the hit had such impact
was that I had seen the idea enough times in enough different forms that the final recognition was in
such general terms to have the quality of an epiphany. My math major had centered on abstract algebras
with their few operations generally applying to many structures. My biology major had focused
on both cell metabolism and larger scale morphogenesis with its notions of simple mechanisms
controlling complex processes and one kind of building block able to differentiate into all needed building
blocks. The 220 file system, the B5000, Sketchpad, and finally Simula, all used the same idea
for different purposes. Bob Barton, the main designer of the B5000 and a professor at Utah had said in
one of his talks a few days earlier: "The basic principle of recursive design is to make the parts have
the same power as the whole." For the first time I thought of the whole as the entire computer and
wondered why anyone would want to divide it up into weaker things called data structures and
procedures. Why not divide it up into little computers, as time sharing was starting to? But not in
dozens. Why not thousands of them, each simulating a useful structure?
</p>
<p>
I recalled the monads of Leibniz, the "dividing nature at its joints" discourse of Plato, and other
attempts to parse complexity. Of course, philosophy is about opinion and engineering is about deeds,
with science the happy medium somewhere in between. It is not too much of an exaggeration to say
that most of my ideas from then on took their roots from Simula—but not as an attempt to improve
it. It was the promise of an entirely new way to structure computations that took my fancy. As it
turned out, it would take quite a few years to understand how to use the insights and to devise
efficient mechanisms to execute them.
</p>
<h2><a name="p6">II. 1967-69—The FLEX Machine, a first attempt at an OOP-based personal computer</a></h2>
<a href="Images/linc.png" target="_blank"><img src="Images/thumbnails/linc.jpg" alt="Wes Clark and the LINC, ca 1962" align="right" style="max-width: 285px"></a>
<p>
Dave Evans was not a great believer in graduate school
as an institution. As with many of the ARPA "contractors"
he wanted his students to be doing "real things"; they
should move through graduate school as quickly as possible;
and their theses should advance the state of the art.
Dave would often get consulting jobs for his students, and
in early 1967, he introduced me to Ed Cheadle, a friendly
hardware genius at a local aerospace company who was
working on a "little machine." It was not the first personal
computer—that was the LINC of Wes Clark—but Ed wanted
it for noncomputer professionals, in particular, he wanted
to program it in a higher level language, like BASIC. I
said; "What about JOSS? It's nicer." He said: "Sure, whatever
you think," and that was the start of a very pleasant
collaboration we called the FLEX machine. As we got deeper into the design, we realized that we wanted
to dynamically <i>simulate</i> and <i>extend,</i> neither of which JOSS (or any existing language that I knew of)
was particularly good at. The machine was too small for Simula, so that was out. The beauty of JOSS
was the extreme attention of its design to the end-user—in this respect, it has not been
surpassed [Joss 1964, Joss 1978]. JOSS was too slow for serious computing (but cf. Lampson 65), did not
have real procedures, variable scope, and so forth. A language that looked a little like JOSS but had
considerably more potential power was Wirth's EULER [Wirth 1966]. This was a generalization of Algol
along lines first set forth by van Wijngaarden [van Wijngaarden 1963] in which types were discarded,
different features consolidated, procedures were made into first class objects, and so forth. Actually
kind of LISPlike, but without the deeper insights of LISP.
</p>
<p>
But EULER was enough of "an almost new thing" to suggest that the same techniques be applied to
simplify Simula. The EULER compiler was a part of its formal definition and made a simple conversion
into B5000-like byte-codes. This was appealing because it suggested that Ed's little machine could
run byte-codes emulated in the longish slow microcode that was then possible. The EULER compiler
however, was tortuously rendered in an "extended precedence" grammar that actually required
concessions in the language syntax (e.g. "," could only be used in one role because the precedence
scheme had no state space). I initially adopted a bottom-up Floyd-Evans parser (adapted from Jerry
Feldman's original compiler-compiler [Feldman 1977]) and later went to various top-down schemes,
several of them related to Shorre's META II [Shorre 1963] that eventually put the translater in the name
space of the language.
</p>
<p>
The semantics of what was now called the FLEX language needed to be influenced more by Simula
than by Algol or EULER. But it was not completely clear how. Nor was it clear how the users should
interact with the system. Ed had a display (for graphing, etc.) even on his first machine, and the LINC
had a "glass teletype," but a Sketchpad-like system seemed far beyond the scope that we could
accomplish with the maximum of 16k 16-bit words that our cost budget allowed.
</p>
<h3>Doug Engelbart and NLS</h3>
<a href="Images/nls.png" target="_blank"><img src="Images/thumbnails/nls.jpg" alt="four pictures" align="right" style="max-width: 250px"></a>
<p>
This was in early 1967, and while we were pondering
the FLEX machine, Utah was visited by Doug Engelbart. A
prophet of Biblical dimensions, he was very much one of
the fathers of what on the FLEX machine I had started to
call "personal computing." He actually traveled with his
own 16mm projector with a remote control for starting
and stopping it to show what was going on (people were
not used to seeing and following cursors back then). His
notion on the ARPA dream was that the destiny of oNLine
Systems (NLS) was the "augmentation of human
intellect" via an interactive vehicle navigating through
"thought vectors in concept space." What his system
could do then—even by today's standards—was incredible.
Not just hypertext, but graphics, multiple panes, efficient
navigation and command input, interactive collaborative
work, etc. An entire conceptual world and world
view [Engelbart 68]. The impact of this vision was to produce
in the minds of those who were "eager to be
augmented" a compelling metaphor of what interactive computing should be like, and I immediately adopted
many of the ideas for the FLEX machine.
</p>
<p>
In the midst of the ARPA context of human-computer
symbiosis and in the presence of Ed's "little machine",
Gordon Moore's "Law" again came to mind, this time
with great impact. For the first time I made the leap of
putting the room-sized interactive TX-2 or even a 10 MIP
6600 on a desk. I was almost frightened by the implications;
computing as we knew it couldn't survive—the
actual meaning of the word changed—it must have been
the same kind of disorientation people had after reading
Copernicus and first looked up from a different Earth to a
different Heaven.
</p>
<p>
Instead of at most a few thousand <i>institutional</i> mainframes
in the world—even today in 1992 it is estimated
that there are only 4000 IBM mainframes in the entire world—and
at most a few thousand users trained for
each application, there would be millions of <i>personal</i>
machines and users, mostly outside of direct institutional
control. Where would the applications and training come
from? Why should we expect an applications programmer
to anticipate the specific needs of a particular one of
the millions of potential users? An <i>extensional</i> system
seemed to be called for in which the end-users would do
most of the tailoring (and even some of the direct
construction) of their tools. ARPA had already figured this out
in the context of their early successes in time-sharing.
Their larger metaphor of human-computer symbiosis
helped the community avoid making a religion of their subgoals and kept them focused on the
abstract holy grail of "augmentation."
</p>
<p>
One of the interesting features of NLS was that its user interface was parametric and could be
supplied by the end user in the form of a "grammar of interaction" given in their compiler-compiler
TreeMeta. This was similar to William Newman's early "Reaction Handler" [Newman 66] work in
specifying interfaces by having the end-user or developer construct through tablet and stylus an
iconic regular expression grammar with action procedures at the states (NLS allowed embeddings via
its context free rules). This was attractive in many ways, particularly William's scheme, but to me
there was a monstrous bug in this approach. Namely, these grammars forced the user to be in a
system state which required getting out of before any new kind of interaction could be done. In hierarchical
menus or "screens" one would have to backtrack to a master state in order to go somewhere
else. What seemed to be required were states in which there was a transition arrow to every other
state—not a fruitful concept in formal grammar theory. In other words, a much "flatter" interface
seemed called for—but could such a thing be made interesting and rich enough to be useful?
</p>
<p>
Again, the scope of the FLEX machine was too small for a miniNLS, and we were forced to find
alternate designs that would incorporate some of the power of the new ideas, and in some cases to
improve them. I decided that Sketchpad's notion of a general window that viewed a larger virtual
world was a better idea than restricted horizontal panes and with Ed came up with a clipping
algorithm very similar to that under development at the same time by Sutherland and his students at
Harvard for the 3D "virtual reality" helmet project [Sutherland 1968].
</p>
<p>
Object references were handled on the FLEX machine as a generalization of B5000 descriptors.
Instead of a few formats for referencing numbers, arrays, and procedures, a FLEX descriptor
contained two pointers: the first to the "master" of the object, and the second to the object instances (later
we realized that we should put the master pointer in the instance to save space). A different method
was taken for handling generalized assignment. The B5000 used l-values and r-values [Strachey*]
which worked for some cases but couldn't handle more complex objects. For example: <i>a[55] := 0</i>, if <i>a</i> was a
sparse array whose default element was 0 would still generate an element in the array because
:= is an "operator" and <i>a[55]</i> is dereferenced into an l-value before anyone gets to see that the r-value
is the default element, regardless of whether <i>a</i> is an array or a procedure fronting for an array. What
is needed is something like: <i>a(55, ':=', 0),</i> which <u>can</u> look at all relevant operands before any store is
made. In other words, := is not an operator, but a kind of index that can select a behavior from a
complex object. It took me a remarkably long time to see this, partly I think because one has to invert
the traditional notion of operators and functions, etc., to see that objects need to privately own all of
their behaviors: <i>that objects are a kind of mapping whose values are its behaviors</i>. A book on logic by
Carnap [Ca *] helped by showing that "intensional" definitions covered the same territory as the
more traditional extensional technique and were often more intuitive and convenient.
</p>
<a href="Images/flex.png" target="_blank"><img src="Images/thumbnails/flex.jpg" alt="Flex machine diagrams" style="max-width: 576px"></a>
<p>
As in Simula, a coroutining control structure [Conway, 1963] was used as a way to suspend and
resume objects. Persistent objects like files and documents were treated as suspended processes and
were organized according to their Algol-like static variable scopes. These were shown on the screen
and could be opened by pointing at them. Coroutining was also used as a control structure for looping.
A single operator <b>while</b> was used to test the generators which returned <b>false</b> when unable to
furnish a new value. Booleans were used to link multiple generators. So a "for-type" loop would be
written as:
</p>
<pre>while i <= 1 to 30 by 2 ^ j <= 2 to k by 3 do j<-j * i;</pre>
<p>
where the <b>... to ... by ...</b> was a kind of coroutine object. Many of these ideas were reimplemented in a
stronger style in Smalltalk later on.
</p>
<a href="Images/flexstatement.png" target="_blank"><img src="Images/thumbnails/flexstatement.jpg" alt="FLEX when statement [Ka 69]" align="right" style="max-width: 268px"></a>
<p>
Another control structure of interest in FLEX was a kind of
event-driven "soft interrupt" called <b>when</b>. Its boolean
expression was compiled into a "tournament sort" tree that
cached all possible intermediate results. The relevant variables
were threaded through all of the sorting trees in all of
the <b>when</b>s so that any change only had to compute through
the necessary parts of the booleans. The efficiency was very
high and was similar to the techniques now used for
spreadsheets. This was an embarrassment of riches with
difficulties often encountered in event-driven systems.
Namely, it was a complex task to control the <i>context</i> of just when the <b>when</b>s should be sensitive. Part
of the boolean expression had to be used to check the contexts, where I felt that somehow the
structure of the program should be able to set and unset the event drivers. This turned out to beyond the
scope of the FLEX system and needed to wait for a better architecture.
</p>
<p>
Still, quite a few of the original FLEX ideas in their proto-object form did turn out to be small
enough to be feasible on the machine. I was writing the first compiler when something unusual
happened: the Utah graduate students got invited to the ARPA contractors meeting held that year at Alta,
Utah. Towards the end of the three days, Bob Taylor, who had succeeded Ivan Sutherland as head of
ARPA-IPTO, asked the graduate students (sitting in a ring around the outside of the 20 or so contractors)
if they had any comments. John Warnock raised his hand and pointed out that since the ARPA
grad students would all soon be colleagues (and since we did all the real work anyway), ARPA should
have a contractors-type meeting each year for the grad students. Taylor thought this was a great idea
and set it up for the next summer.
</p>
<p>
Another ski-lodge meeting happened in Park City later that spring. The general topic was education
and it was the first time I heard Marvin Minsky speak. He put forth a terrific diatribe against
traditional education methods, and from him I heard the ideas of Piaget and Papert for the first time.
Marvin's talk was about how we think about complex situations and why schools are really bad
places to learn these skills. He didn't have to make any claims about computers+kids to make his
point. It was clear that education and learning had to be rethought in the light of 20th century
cognitive psychology and how good thinkers really think. Computing enters as a new representation system
with new and useful metaphors for dealing with complexity, especially of systems [Minsky 70].
</p>
<a href="Images/plasma.png" target="_blank"><img src="Images/thumbnails/plasma.jpg" alt="The First Plasma Panel" style="max-width: 356px" align="right"></a>
<p>
For the summer 1968 ARPA grad students meeting at Allerton House in Illinois, I boiled all the mechanisms in the FLEX machine down into one 2'x3' chart. This included
all the "object structures", the compiler, the byte-code
interpreter, i/o handlers, and a simple display editor
for text and graphics. The grad students were a
distinguished group that did indeed become colleagues in
subsequent years. My FLEX machine talk was a success,
but the big whammy for me came during a tour to U of Illinois
where I saw a 1" square lump of glass and neon gas in which individual spots would light up on
command—it was the first flat-panel display. I spent the rest
of the conference calculating just when the silicon of the
FLEX machine could be put on the back of the display. According to Gordon Moore's "Law", the
answer seemed to be sometime in the late seventies or early eighties. A long time off—it seemed too
long to worry much about it then.
</p>
<a href="Images/dynabookmodel.png" target="_blank"><img src="Images/thumbnails/dynabookmodel.jpg" alt="Grail, Seymour Papert and LOGO Turtle, The Dynabook Model" style="max-width: 372px" align="right"></a>
<p>
But later that year at RAND I saw a truly beautiful system.
This was GRAIL, the graphical followon to JOSS. The
first tablet (the famous RAND tablet) was invented by
Tom Ellis [Davis 1964] in order to capture human
gestures, and Gave Groner wrote a program to efficiently
recognize and respond to them [Groner 1966]. Though
everything was fastened with bubble gum and the
system crashed often, I have never forgotten my first interactions
with this system. It was direct manipulation, it
was analogical, it was modeless, it was beautiful. I realized
that the FLEX interface was all wrong, but how could
something like GRAIL be stuffed into such a tiny machine
since it required <u>all</u> of a stand-alone 360/44 to run in?
</p>
<p>
A month later, I finally visited Seymour Papert, Wally
Feurzig, Cynthia Solomon and some of the other
original researchers who had built LOGO and were using it
with children in the Lexington schools. Here were children
doing real programming with a specially designed
language and environment. As with Simula leading to
OOP, this encounter finally hit me with what the destiny
of personal computing <i>really</i> was going to be. Not a
personal dynamic <i>vehicle,</i> as in Engelbart's metaphor
opposed to the IBM "railroads", but something much
more profound: a personal dynamic <i>medium.</i> With a
vehicle one could wait until high school and give "drivers
ed", but if it was a medium, it had to extend into
the world of childhood.
</p>
<p>
Now the collision of the FLEX machine, the flat-screen
display, GRAIL, Barton's "communications" talk,
McLuhan, and Papert's work with children all came
together to form an image of what a personal computer
really should be. I remembered Aldus Manutius who 40
years after the printing press put the book into its
modern dimensions by making it fit into saddlebags. It had
to be no larger than a notebook, and needed an interface
as friendly as JOSS', GRAIL's, and LOGO's, but with the
reach of Simula and FLEX. A clear romantic vision has a marvelous ability to focus thought and will.
Now it was easy to know what to do next. I built a cardboard model of it to see what it would look
and feel like, and poured in lead pellets to see how light it would have to be (less than two pounds). I
put a keyboard on it as well as a stylus because, even if hand printing and writing were recognized
perfectly (and there was no reason to expect that it would be), there still needed to be a balance
between
the low speed tactile degrees of freedom offered by the stylus and the more limited but faster
keyboard. Since ARPA was starting to experiment with packet radio, I expected that the Dynabook
when it arrived a decade or so hence, would have a wireless networking system.
</p>
<p>
Early next year (1969) there was a conference on Extensible Languages in which almost every
famous name in the field attended. The debate was great and weighty—it was a religious war of
unimplemented poorly thought out ideas. As Alan Perlis, one of the great men in Computer Science,
put it with characteristic wit:
</p>
<blockquote>
It has been such a long time since I have seen so many familiar faces
shouting among so many familiar ideas. Discovery of something new in
programming languages, like any discovery, has somewhat the same
sequence of emotions as falling in love. A sharp elation followed by
euphoria, a feeling of uniqueness, and ultimately the wandering eye
(the urge to generalize) [ACM 69].
</blockquote>
<p>
But it was all talk—no one had <u>done</u> anything yet. In the midst of all this, Ned Irons got up and
presented IMP, a system that had already been working for several years that was more elegant than
most of the nonworking proposals. The basic idea of IMP was that you could use any phrase in the
grammar as a procedure heading and write a semantic definition in terms of the language as
extended so far [Irons 1970].
</p>
<p>
I had already made the first version of the FLEX machine syntax driven, but where the meaning of a
phrase was defined in the more usual way as the kind of code that was emitted. This separated the
compiler-extensor part of the system from the end-user. In Irons' approach, <i>every</i> procedure in the
system defined its own syntax in a natural and useful manner. I incorporated these ideas into the
second versions of the FLEX machine and started to experiment with the idea of a direct interpreter rather
than a syntax directed compiler. Somewhere in all of this, I realized that the bridge to an object-based
system could be in terms of each object as a syntax directed interpreter of messages sent to it. In one
fell swoop this would unify object-oriented semantics with the ideal of a completely extensible language.
The mental image was one of separate computers sending requests to other computers that
had to be accepted and understood by the receivers before anything could happen. In today's terms
every object would be a <i>server</i> offering <i>services</i> whose deployment and discretion depended entirely
on the server's notion of relationship with the servee. As Liebniz said: "To get everything out of
nothing, you only need to find one principle." This was not well thought out enough to do the FLEX
machine any good, but formed a good point of departure for my thesis [Kay 69], which as Ivan
Sutherland liked to say was "anything you can get three people to sign."
</p>
<p>
After three people signed it (Ivan was one of them), I went to the Stanford AI project and spent
much more time thinking about notebook KiddyKomputers than AI. But there were two AI designs
that were very intriguing. The first was Carl Hewitt's PLANNER, a programmable logic system that
formed the deductive basis of Winograd's SHRDLU [Sussman 69, Hewitt 69] I designed several
languages based on a combination of the pattern matching schemes of FLEX and PLANNER [Kay 70]. The
second design was Pat Winston's concept formation system, a scheme for building semantic
networks and comparing them to form analogies and learning processes [Winston 70]. It was kind of
"object-oriented". One of its many good ideas was that the arcs of each net which served as attributes
in AOV triples should themselves be modeled as nets. Thus, for example a first order arc called LEFT-OF
could be asked a higher order question such as "What is your converse?" and its net could answer:
RIGHT-OF. This point of view later formed the basis for Minsky's frame systems [Minsky 75]. A few
years later I wished I had paid more attention to this idea.
</p>
<p>
That fall, I heard a wonderful talk by Butler Lampson about CAL-TSS, a capability-based operating
system that seemed very "object-oriented" [Lampson 69]. Unforgeable pointers (ala B5000) were
extended by bit-masks that restricted access to the object's internal operations. This confirmed my
"objects as server" metaphor. There was also a very nice approach to exception handling which
reminded me of the way failure was often handled in pattern matching systems. The only problem—
which the CAL designers did not see as a problem at all—was that only certain (usually large and
slow) things were "objects". Fast things and small things, etc., weren't. This needed to be fixed.
</p>
<p>
The biggest hit for me while at SAIL in late '69 was to <i>really understand</i> LISP. Of course, every
student knew about <i>car, cdr</i>, and <i>cons</i>, but Utah was impoverished in that no one there used LISP and
hence, no one had penetrated the mysteries of <i>eval</i> and <i>apply</i>. I could hardly believe how beautiful
and wonderful the <i>idea</i> of LISP was [McCarthy 1960]. I say it this way because LISP had not only been
around enough to get some honest barnacles, but worse, there were deep flaws in its logical
foundations. By this, I mean that the pure language was supposed to be based on functions, but its most
important components—such as lambda expressions, quotes, and conds—were not functions at all,
and instead were called special forms. Landin and others had been able to get quotes and conds in
terms of lambda by tricks that were variously clever and useful, but the flaw remained in the jewel.
In the practical language things were better. There were not just EXPRs (which evaluated their
arguments), but FEXPRs (which did not). My next question was, why on earth call it a functional language?
Why not just base everything on FEXPRs and force evaluation on the receiving side when needed? I
could never get a good answer, but the question was very helpful when it came time to invent
Smalltalk, because this started a line of thought that said "take the hardest and most profound thing
you need to do, make it great, and then build every easier thing out of it". That was the promise of
LISP and the lure of lambda—needed was a better "hardest and most profound" thing. Objects should
be it.
</p>
<h2><a name="p12">III. 1970-72—Xerox PARC: The KiddiKomp, miniCOM, and Smalltalk-71</a></h2>
<p>
In July 1970, Xerox, at the urging of its chief scientist Jack Goldman, decided to set up a long range
research center in Palo Alto, California. In September, George Pake, the former chancellor at
Washington University where Wes Clark's ARPA project was sited, hired Bob Taylor (who had left the
ARPA office and was taking a sabbatical year at Utah) to start a "Computer Science Laboratory." Bob
visited Palo Alto and we stayed up all night talking about it. The Mansfield Amendment was threatening
to blindly muzzle the most enlightened ARPA funding in favor of directly military research, and
this new opportunity looked like a promising alternative. But work for a company? He wanted me to
consult and I asked for a direction. He said: follow your instincts. I immediately started working up a
new version of the KiddiKomp that could be made in enough quantity to do experiments leading to
the user interface design for the eventual notebook. Bob Barton liked to say that "good ideas don't
often scale." He was certainly right when applied to the FLEX machine. The B5000 just didn't directly
scale down into a tiny machine. Only the byte-codes did, and even these needed modification. I
decided to take another look at Wes Clark's LINC, and was ready to appreciate it much more this time
[Clark 1965].
</p>
<a href="Images/kiddikomp.png" target="_blank"><img src="Images/thumbnails/kiddikomp.jpg" alt="KiddiKomp" style="max-width: 703px"></a>
<p>
I still liked pattern-directed approaches and OOP so I came up with a language design called "Simulation LOGO" or SLOGO for short (I had a feeling the first versions might run nice and slow). This
was to be built into a SONY "tummy trinitron" and would use a coarse bit-map display and the FLEX
machine rubber tablet as a pointing device.
</p>
<p>
Another beautiful system that I had come across was Peter Deutsch's PDP-1 LISP (implemented
when he was only 15) [Deutsch 1966]. It used only 2K (18-bit words) of code and could run quite well
in a 4K machine (it was its own operating system and interface). It seemed that even more could be
done if the system were byte-coded, run by an architecture that was hospitable to dynamic systems,
and stuck into the ever larger ROMs that were becoming available. One of the basic insights I had gotten
from Seymour was that you didn't have to do a lot to make a computer an "object for thought"
for children, but what you did had to be done well and be able to apply deeply.
</p>
<p>
Right after New Years 1971, Bob Taylor scored an enormous coup by attracting most of the
struggling Berkeley Computer Corp to PARC. This group included Butler Lampson, Chuck Thacker, Peter
Deutsch, Jim Mitchell, Dick Shoup, Willie Sue Haugeland, and Ed Fiala. Jim Mitchell urged the group
to hire Ed McCreight from CM and he arrived soon after. Gary Starkweather was there already,
having been thrown out of the Xerox Rochester Labs for wanting to build a laser printer (which was
against the local religion). Not long after, many of Doug Englebart's people joined up—part of the
reason was that they want to reimplement NLS as a distributed network system, and Doug wanted to
stay with time-sharing. The group included Bill English (the co-inventor of the mouse), Jeff Rulifson,
and Bill Paxton.
</p>
<p>
Almost immediately we got into trouble with Xerox when the group decided that the new lab
needed a PDP-10 for continuity with the ARPA community. Xerox (which had bought SDS essentially
sight unseen a few years before) was horrified at the idea of their main competitor's computer being
used in the lab. They balked. The newly formed PARC group had a meeting in which it was decided
that it would take about three years to do a good operating system for the XDS SIGMA-7 but that we
could <i>build</i> "our own PDP-10" in a year. My reaction was "Holy cow!" In fact, they pulled it it off with
considerable panache. MAXC was actually a microcoded emulation of the PDP-10 that used for the first
time the new integrated chip memories (1K bits!) instead of core memory. Having practical in house
experience with both of these new technologies was critical for the more radical systems to come.
</p>
<p>
One little incident of LISP beauty happened when Allen Newell visited PARC with his theory
of hierarchical thinking and was challenged to prove it. He was given a programming problem to solve
while the protocol was collected. The problem was: given a list of items, produce a list consisting of
all of the odd indexed items followed by all of the even indexed items. Newell's internal programming
language resembled IPL-V in which pointers are manipulated explicitly, and he got into quite a
struggle to do the program. In 2 seconds I wrote down:
</p>
<pre>oddsEvens(x) = append(odds(x), evens(x))</pre>
<p>
the statement of the problem in Landin's LISP syntax—and also the first part of the solution. Then a
few seconds later:
</p>
<pre>where odds(x) = if null(x) ∨ null(tl(x)) then x
else hd(x) & odds(ttl(x))
evens(x) = if null(x) ∨ null(tl(x)) then nil
else odds(tl(x))</pre>
<p>
This characteristic of writing down many solutions in declarative form and have them also be the
programs is part of the appeal and beauty of this kind of language. Watching a famous guy much
smarter than I struggle for more than 30 minutes to not quite solve the problem his way (there was a
bug) made quite an impression. It brought home to me once again that "point of view is worth 80 IQ
points." I wasn't smarter but I had a much better internal thinking tool to amplify my abilities. This
incident and others like it made paramount that any tool for children should have great thinking
patterns <u>and</u> deep beauty "built-in."
</p>
<a href="Images/penderypaperdisplay.png" target="_blank"><img src="Images/thumbnails/penderypaperdisplay.jpg" alt="Pendery Paper Display Transducer Design" align="right" style="max-width: 420px"></a>
<p>
Right around this time we were involved in another conflict with Xerox management, in particular
with Don Pendery the head "planner". He really didn't understand what we were talking about and
instead was interested in "trends" and
"what was the future going to be like"
and how could Xerox "defend against
it." I got so upset I said to him, "Look.
<i>The best way to predict the future is to
invent it.</i> Don't worry about what all
those other people might do, this is
the century in which almost any clear vision can be made!" He remained
unconvinced, and that led to the famous "Pendery Papers for PARC
Planning Purposes," a collection of
essays on various aspects of the
future. Mine proposed a version of the notebook as a "Display Transducer",
and Jim Mitchell's was entitled "NLS
on a Minicomputer."
</p>
<p>
Bill English took me under his wing and helped me start my group as I had always been a lone
wolf and had no idea how to do it. One of his suggestions was that I should make a budget. I'm
afraid that I really did ask Bill, "What's a budget?" I remembered at Utah, in pre-Mansfield
Amendment days, Dave Evans saying to me as he went off on a trip to ARPA, "We're almost out of
money. Got to go get some more." That seemed about right to me. They give you some money. You
spend it to find out what to do next. You run out. They give you some more. And so on. PARC never
quite made it to that idyllic standard, but for the first half decade it came close. I needed a group
because I had finally realized that I did not have all of the temperaments required to completely finish
an idea. I called it the Learning Research Group (LRG) to be as vague as possible about our charter.
I only hired people that got stars in their eyes when they heard about the notebook computer idea. I
didn't like meetings: didn't believe brainstorming could substitute for cool sustained thought. When
anyone asked me what to do, and I didn't have a strong idea, I would point at the notebook model
and say, "Advance that." LRG members developed a very close relationship with each other—as Dan
Ingalls was to say later: "... the rest has enfolded through the love and energy of the whole Learning
Research Group." A lot of daytime was spent outside of PARC, playing tennis, bikeriding, drinking
beer, eating Chinese food, and constantly talking about the Dynabook and its potential to amplify
human reach and bring new ways of thinking to a faltering civilization that desperately needed it
(that kind of goal was common in California in the aftermath of the sixties).
</p>
<p>
In the summer of '71 I refined the KiddiKomp idea into a tighter design called miniCOM. It used a
bit-slice approach like the NOVA 1200, had a bit-map display, a pointing device, a choice of
"secondary" (really tertiary) storages, and a language I now called "Smalltalk"—as in "programming
should be a matter of ..." and "children should program in ...". The name was also a reaction against
the "IndoEuropean god theory" where systems were named Zeus, Odin, and Thor, and hardly did
anything. I figured that "Smalltalk" was so innocuous a label that if it ever did anything nice people
would be pleasantly surprised.
</p>
<a href="Images/minicom.png" target="_blank"><img src="Images/thumbnails/minicom.jpg" alt="miniCOM" style="max-width: 507px"></a>
<pre class="rightcolumn">
Smalltalk-71 Programs
to T 'and' :y do 'y'
to F 'and' :y do F
to 'factorial' 0 is 1
to 'factorial' :n do 'n*factorial n-1'
to 'fact' :n do 'to 'fact' n do factorial n. ^ fact n'
to :e 'is-member-of' [] do F
to :e 'is-member-of' :group
do'if e = firstof group then T
else e is-member-of rest of group'
to 'cons' :x :y is self
to 'hd' ('cons' :a :b) do 'a'
to 'hd' ('cons' :a :b) '<-' :c do 'a <- c'
to 'tl' ('cons' :a :b) do 'b'
to 'tl' ('cons' :a :b) '<-' :c do 'b <- c'
to :robot 'pickup' :block
do 'robot clear-top-of block.
robot hand move-to block.
robot hand lift block 50.
to 'height-of' block do 50'
</pre>
<p>
This Smalltalk language (today labeled -71) was very influenced by FLEX, PLANNER, LOGO, META II, and my own
derivatives from them. It was a kind of parser with
object-attachment that executed tokens directly. (I think
the awkward quoting conventions come from META). I
was less interested in programs as algebraic patterns
than I was in a clear scheme that could handle a variety
of styles of programming. The patterned front-end
allowed simple extension, patterns as "data" to be
retrieved, a simple way to attach behaviors to objects,
and a rudimentary but clear expression of its <i>eval</i> in
terms that I thought children could understand after a
few years experience with simpler programming.
Program storage was sorted into a discrimination net and
evaluation was straightforward pattern-matching.
</p>
<p>
As I mentioned previously, it was annoying that the
surface beauty of LISP was marred by some of its key
parts having to be introduced as "special forms" rather
than as its supposed universal building block of
functions. The actual beauty of LISP came more from the
<i>promise</i> of its metastructures than its actual model. I spent
a fair amount of time thinking about how objects could
be characterized as universal computers without having to have any exceptions in the central
metaphor. What seemed to be needed was complete control over what was passed in a message send;
in particular <i>when</i> and in <i>what environment</i> did expressions get evaluated?
</p>
<p>
An elegant approach was suggested in a CMU thesis of Dave Fisher [Fisher 70] on the synthesis of
control structures. ALGOL60 required a separate link for dynamic subroutine linking and for access to
static global state. Fisher showed how a generalization of these links could be used to simulate a
wide variety of control environments. One of the ways to solve the "funarg problem" of LISP is to
associate the proper global state link with expressions and functions that are to be evaluated later so
that the free variables referenced are the ones that were actually implied by the static form of the
language. The notion of "lazy evaluation" is anticipated here as well.
</p>
<p>
Nowadays this approach would be called <i>reflective design</i>. Putting it together with the FLEX models
suggested that all that should be required for "doing LISP right" or "doing OOP right" would be to
handle the mechanics of invocations between modules without having to worry about the details of
the modules themselves. The difference between LISP and OOP (or any other system) would then be
what the modules could contain. A universal module (object) reference —ala B5000 and LISP—and a
message holding structure—which could be virtual if the senders and receivers were sympatico—
that could be used by all would do the job.
</p>