foreword added

Author: martin-henz

xml/others/02foreword02.xml

@@ -3,9 +3,132 @@
  Foreword
  </NAME>
 
- <TEXT>
- in preparation
- </TEXT>
+ <TEXT>
+ I had the pleasure of meeting the amazing Alan Perlis and talking with
+ him a few times, when I was still a student. Following in his
+ footsteps is a daunting task, even though he blazed an excellent
+ trail. Still, I would like to reexamine one comment he made in the
+ original foreword to this book (and, please, you may wish to read his
+ foreword before you finish this one). Is it really true that it is
+ better to have 100 functions operate on one data structure than to
+ have 10 functions operate on 10 data structures?
+ </TEXT>
+ <TEXT>
+ To answer that question carefully, we first need to ask whether
+ that one data structure is <QUOTE>universal</QUOTE>: can it conveniently
+ fulfill the roles of those 10 more specialized data structures?
+ </TEXT>
+ <TEXT> 
+ For that matter, we can also ask: do we really need 100
+ functions? Is there a single universal function that can fulfill
+ the roles of all those other functions?
+ </TEXT>
+ <TEXT> 
+ The surprising answer to that last question is <QUOTE>yes</QUOTE>; it is
+ only slightly tricky to construct a function that accepts (1) a
+ data structure that serves as a description of some other
+ function, and (2) a list of arguments, and behaves exactly as
+ that other function would when applied to the given
+ arguments. And it is only slightly tricky to design a data
+ structure capable of describing any computation whatsoever. One
+ such data structure (the tagged-list representation of
+ expressions and statements, paired with environments that
+ associate names with values) and one such universal function
+ (<JAVASCRIPTINLINE>apply</JAVASCRIPTINLINE>) are described in
+ Chapter 4 of this book. So maybe we need only one function and
+ one data structure.
+ </TEXT>
+ <TEXT> 
+ That is true in theory. In practice, we find it convenient to
+ draw distinctions that help us, as human beings constructing
+ descriptions of computations, to organize the structure of our
+ code so that we can better understand them. I believe that
+ Perlis was making a remark not about computational capability,
+ but about human abilities and human limitations.
+ </TEXT>
+ <TEXT>
+ One thing the human mind seems to do well is to name things; we have
+ powerful associative memories. Given a name, we can quickly recall
+ some associated thing to mind. This is why we typically find it easier
+ to work with the lambda calculus than the combinatory calculus; it is
+ much easier for most people to interpret the Lisp expression
+ <SCHEMEINLINE>(lambda (x) (lambda (y) (+ x y)))</SCHEMEINLINE>
+ or the JavaScript expression
+ <JAVASCRIPTINLINE>x => y => x + y</JAVASCRIPTINLINE>
+ than the combinatory expression
+ <BLOCKQUOTE>
+((S ((S (K S)) ((S ((S (K S)) ((S (K K)) (K +)))) ((S (K K)) I)))) (K I))
+ </BLOCKQUOTE>
+ even though there is a
+ direct structural correspondence, easily expressed in five lines of
+ Lisp code.
+ </TEXT>
+ <TEXT> 
+ So while in principle we could get by with just one universal
+ function, we prefer to modularize our code, to give names to the
+ various pieces, and to mention the names of function
+ descriptions rather than constantly feeding the descriptions
+ themselves to the universal function.
+ </TEXT>
+ <TEXT> 
+ In my 1998 talk <QUOTE>Growing a Language,</QUOTE> I commented
+ that a good programmer <QUOTE>does not just write programs. A
+ good programmer builds a working vocabulary.</QUOTE> As we
+ design and define more and more parts of our programs, we give
+ names to those parts, and the result is that we have a richer
+ language in which to write the rest.
+ </TEXT>
+ <TEXT> 
+ But we also find it natural to draw distinctions among data
+ structures, and to give them names.
+ </TEXT>
+ <TEXT>
+ It may be that nested lists are a universal data structure (and
+ it is worth noting that many modern and widely used data
+ structures, such as HTML and XML and JSON, are also
+ parenthetically nested representations, only slightly more
+ elaborate than Lisp<APOS/>s bare parentheses). There are also many
+ functions, such as finding the length of a list or applying a
+ function to every element of a list and getting back a list of
+ the results, that are useful in a wide variety of situations.
+ And yet, when I am thinking about a specific computation, I
+ often say to myself, <QUOTE>This list of two things I expect to be a
+ personal name and a surname, but that list of two things I
+ expect to be the real and imaginary parts of a complex number,
+ and that other list of two things I will regard as the numerator
+ and denominator of a fraction.</QUOTE> In other words, I draw
+ distinctions<EMDASH/>and it may be useful to represent those
+ distinctions explicitly in the data structure, in part to
+ prevent mistakes such as accidentally treating a complex number
+ as a fraction. (Again, this is a comment about human abilities
+ and human limitations.)
+ </TEXT>
+ <TEXT>
+ So maybe the truth is somewhere in between the extremes that
+ Perlis so eloquently posited. Maybe the sweet spot is something
+ more like 40 functions general enough to operate usefully on a
+ universal data structure such as lists, but also 10 sets of 6
+ functions each that are relevant when we take one of 10
+ specialized views of that universal data structure. This is
+ manageable if we give good names to these functions and
+ specialized views.
+ </TEXT>
+ <TEXT>
+ As you read this book, please pay attention not only to the
+ programming language constructs and how they are used, but also
+ to the <EM>names</EM> given to functions and variables and data
+ structures. They have been chosen in a deliberate and systematic
+ way to enhance your understanding of the overall program
+ structure.
+ </TEXT>
+ <TEXT>
+ Primitives, means of combination, abstraction, naming, and
+ conventions for using a universal data structure in specialized
+ ways by drawing distinctions: these are the fundamental building
+ blocks of a good programming language. From there, imagination
+ and good engineering judgment based on experience can do the
+ rest.
+ </TEXT>
 
  <SIGNATURE>
  <ATTRIBUTION>