"A Jedi knight you will be"

"A Jedi knight you will be"

(with-phrasing (:object :subject :verb)
  Paul Graham's books very good are.  Over-rated sometimes they can
  be, but shine for schemers they do.  A good path from Scheme-think
  to Lisp-think the book "ANSI Common Lisp" provides.  Both
  tail-recursion but even more, iteration, loves him he does.)

I speak as someone who is fairly comfortable with
Scheme but cannot realistically hope to achieve that
comfort with CL.  I know the two languages are
different (and _how_ they are different).  Maybe my
experience is not statistically significant (whatever
that means), I hope so.

It isn't exactly a new hypothesis around here that
Scheme ruins one for CL.  I find it a plausible
hypothesis.  Exceptions for exceptional talent of
course, as always.  

First of all, i like to voice my opinion that lots of people in
the computing field likes to spur the use of spurious jargons.
The less educated they are, the more they like extraneous
jargons, such as in the Unix & Perl community. Unlike
mathematicians, where in mathematics there are no fewer jargons
but each and every one are absolutely necessary. For example,
polytope, manifold, injection/bijection/surjection,
group/ring/field.., homological, projective, pencil, bundle,
lattice, affine, topology, isomorphism, isometry, homeomorphism,
aleph-0, fractal, supremum/infimum, simplex, matrix, quaternions,
derivative/integral, ...and so on. Each and every one of these
captures a concept, for which practical and theoretical
considerations made the terms a necessity. Often there are
synonyms for them because of historical developments, but never
"jargons for jargon's sake" because mathematicians hate bloats
and irrelevance.

The jargon-soaked stupidity in computing field can be grouped
into classes. First of all, there are jargons for marketing
purposes. Thus you have Mac OS "X", Windows "XP", Sun OS ->
Solaris and the versioning confusion of 4.x to 7 to 8 and also
the so called "Platform" instead of OS. One flagrant example is
Sun Microsystem's Java stuff. Oak, Java, JDK, JSDK, J2EE, J2SE
enterprise edition or no, from java 1.x to 1.2 == Java 2 now 1.3,
JavaOne, JFC, Jini, JavaBeans, entity Beans, Awk, Swing...
fucking stupid Java and fuck Sun Microsystems. This is just one
example of Jargon hodgepodge of one single commercial entity.
Marketing jargons cannot be avoided in modern society. They
abound outside computing fields too. The Jargons of marketing
came from business practice, and they can be excusable because
they are kinda a necessity or can be considered as a naturally
evolved strategy for attracting attention in a free-market social
system.

The other class of jargon stupidity is from computing
practitioners, of which the Unix/Perl community is exemplary. For
example, the name Unix & Perl themselves are good examples of
buzzing jargons. Unix is supposed to be opposed of Multics and
hints on the offensive and tasteless term eunuchs. PERL is cooked
up to be "Practical Extraction & Reporting Language" and for the
precise marketing drama of being also "Pathologically Eclectic
Rubbish Lister". These types of jargons exudes juvenile humor.
Cheesiness and low-taste is their hall-mark. If you are familiar
with unixism and perl programing, you'll find tons and tons of
such jargons embraced and verbalized by unix & perl lovers. e.g.
grep, glob, shell, pipe, man, regex, tarball, shebang,
Schwartzian Transform, croak, bless, interpolation, TIMTOWTDI,
DWIM, RFC, RTFM, I-ANAL, YMMV and so on.

There is another class of jargon moronicity, which i find them
most damaging to society, are jargons or spurious and vague terms
used and brandished about by programers that we see and hear
daily among design meetings, comp.lang.* newsgroup postings, or
even in lots of computing textbooks or tutorials. I think the
reason for these, is that these massive body of average
programers usually don't have much knowledge of significant
mathematics, yet they are capable of technical thinking that is
not too abstract, thus you ends up with these people defining or
hatching terms a-dime-a-dozen that's vague, context dependent,
vacuous, and their commonality are often a result of sopho-morons
trying to sound big.

Here are some examples of the terms in question:

 * anonymous functions or lambda or lamba function
 * closure
 * exceptions (as in Java)
 * list, array, vector, aggregate
 * hash (or hash table)  <-- fantastically stupid
 * rehash (as in csh or tcsh)
 * regular expression (as in regex, grep, egrep, fgrep)
 * name space (as in Scheme vs Common Lisp debates)
 * depth first/breadth first (as in tree traversing.)
 * operator
 * operator overloading
 * polymorphism
 * inheritance
 * first class objects
 * pointers, references

My time is limited, so i'll just give a brief explanation of my
thesis on selective few of these examples among the umpteen.

In a branch of math called lambda calculus, in which much
theories of computation are based on, is the origin of the jargon
_lambda function_ that so commonly reciprocated by lisp and other
programering donkeys. In practice, a subroutine without
side-effects is supposed to be what "lambda function" means.
Functional languages often can defined them without assigning
them to some variable (name), therefore the "function without
side-effects" are also called "anonymous functions". One can see
that these are two distinct concepts. If mathematicians are
designing computer languages, they would probably just called
such thing _pure functions_. The term conveys the meaning,
without the "lamba" abstruseness. (in Fact, the mathematics
oriented language Mathematica refers to lambda function as pure
function, with the keyword Function.) Because most programers are
sopho-morons who are less capable of clear thinking but
nevertheless possess human vanity, we can see that they have not
adopted the clear and fitting term, but instead you see lambda
function this and that obfuscations dropping from their mouths
constantly.

Now the term "closure" can and indeed have meant several things
in the computing field. The most common i believe today, is for
it to mean a subroutine that holds some memory but without some
disadvantages of modifying a global variable. Usually such is a
feature of a programing language. When taken to extreme, we have
the what's called Object Oriented Programing methodology and
languages. The other meaning of "closure" i have seen in text
book, is for it to indicate that the things in the language is
"closed" under the operations of the language. For example, for
some languages you can apply operations or subroutines to any
thing in the language. (These languages are often what's called
"dynamic typing" or "typeless"). However, in other languages,
things has types and cannot be passed around subroutines or
operators arbitrarily. One can see that the term "closure" is
quite vague in conveying its meaning. The term nevertheless is
very popular among talkative programers and dense tutorials,
precisely because it is vague and mysterious. These pseudo-wit
living zombies, never thought for a moment that they are using a
moronic term, mostly because they never clearly understand the
concepts behind the term among the contexts. One can particular
see this exhibition among Perl programers. (for an example of the
fantastically stupid write-up on closure by the Perl folks, see
"perldoc perlfaq7" and "perldoc perlref".)

in the so-called "high-level" computing languages, there are
often data types that's some kind of a collection. The most
illustrative is LISt Processing language's lists. Essentially,
the essential concept is that the language can treat a collection
of things as if it's a single entity. As computer languages
evolves, such collection entity feature also diversified, from
syntax to semantics to implementation. Thus, besides lists, there
are also terms like vector, array, matrix, tree, hash/"hash
table"/dictionary. Often each particular term is to convey a
particular implementation of collection so that it has certain
properties to facilitate specialized uses of such groupy. The
Java language has such groupy that can illustrate the point well.
In Java, there's these hierarchy of collection-type of things:

 Collection
   Set (AbstractSet, HashSet)
     SortedSet (TreeSet)
   List (AbstractList, LinkedList, Vector, ArrayList)

 Map (AbstractMap, HashMap, Hashtable)
   SortedMap (TreeMap)

The words without parenthesis are java Interfaces, and ones in
are implementations. The interface hold a concept. The deeper the
level, the more specific or specialized. The implementation carry
out concepts. Different implementation gives different
algorithmic properties. Essentially, these hierarchies of Java
shows the potential complexity and confusion around groupy
entities in computer languages. Now, among the programers we see
daily, who never really thought out of these things, will attach
their own specific meaning to list/array/vector/matrix/etc type
of jargons in driveling and arguments, oblivious to any thought
of formalizing what the fuck they are really talking about. (one
may think from the above tree-diagram that Java the language has
at least put clear distinction to interface and implementation,
whereas in my opinion they are one fantastic fuck up too, in many
respects. (I will detail it some day.))

... i'm getting tired of writing this. There are just too many
spurious stupid jargons that's meaningless and endlessly
confusing, yet embraced and spoke by all monkey coders. What i am
coming into, is the jargon "tail recursion". What a fantastically
fucking fantastic stupid meaningless term that is so loved by the
LISP programing geeks. In every trickle of chance they'll flash
it out to debate. (hopefully i'll continue explaining the stupid
jargons and background of common computing terms that i listed
above and much more in the future.)

Now, let's talk about tail recursion.

I asked Sussman and Abelson about this once, long ago.  Their answer may
have changed.  But at the time they told me that they agreed with me that
"iteration" is an abstract concept and that a "loop" construct is one way
to achieve it notationally and that "tail recursion" is another.  To put
it another way, the lisp program:

 (defun my-length (list)
   (do ((length 0 (+ length 1))
        (sublist list (cdr sublist)))
       ((null sublist) length)))

is conceptually isomorphic to

 (defun my-length (list)
   (labels ((do-it (length sublist)
              (if (null sublist)
                  length
                  (my-length (+ length 1) (cdr sublist)))))
     (do-it 0 list)))

In effect, they are just syntactic rewrites of each other.  To me, and I
think to both of them, these are just syntactic sugar for one another.
But they were trying to make some teaching points so they focused mainly
on getting people to write the latter format.  I don't think they
have a deathwish for alternate syntaxes, but they feel those syntaxes are
covered to death in other courses and they didn't see wasting their own
precious course space on stuff that could be learned elsewhere.

But the studious omission of such an obvious alternate notation does not
go unnoticed by students.  And, moreover, students get their problems marked
wrong if they use a perfectly valid notation that is not part of the course
material.  And, as a consequence, the Skinnerian effect of taking this course
is often, in practice, regardless of original intent of Sussman and Abelson,
to teach people the "false truths" that (a) Iteration and Tail Recursion are
different [since it's often the case that the former is informally called
recursion, and the latter for contrast purposes only, is not, and since
one will get them credit and one won't] and that (b) Iteration is Bad and
Tail Recursion is Good.

And it was always my impression that SICP (the book at least) was
free of the usual Scheme propaganda, I wouldn't even call it a Scheme
book; they just use Scheme as a language, for whatever reason.  The
impression I got, and the reason I value this book very high, is that
it teaches people how to THINK, not only how to DO, as most other
books.  Naturally, that makes this book somewhat harder to understand
for students, and I had hoped that at least those who are intelligent
enough to ``survive'' the course until the end, would be smart
enough to figure out for themselves that tail recursion and iteration
are simply isomorphic concepts and it doesn't matter at all which
you use.  Pure speculation on my side, of course; I am very interested
whether that is actually true, so:  Did you (or anyone else) ever
meet people who took (and finished :-) the course and turned out
to be silly Scheme fanatics?  And was such a course held by
Abelson or Sussman themselves?  Of course, a Scheme fanatic could
use the book for a course and add a whole lot of Scheme propaganda
here and there :-)

Regards,
--
Nils Goesche
Ask not for whom the <CONTROL-G> tolls.

Although I also dislike Scheme strongly, I don't agree with your
assertion that someone who knows Scheme has no hope of learning CL - I
know at least one person who is a counterexample to this.

Regards,
--
Nils Goesche
Ask not for whom the <CONTROL-G> tolls.

For instance, I told everyone that there is one and only One True
Book that everybody should read as a first text on complex analysis:
``Functions of One Complex Variable'' by John Conway; some people
bought it, but I don't think many of them read much of it.  Instead,
most of them preferred a certain other book, which I always thought was
totally stupid, full of errors, much too wordy and infinitely boring:
The authors always close every topic just when it becomes interesting.
Something like a hundred and fifty pages that contain almost nothing,
a total waste of time.  But they preferred it, even the good ones.
I never found out, why.  I just hope the fact that the other book
was in German (and cheaper) wasn't the only reason ;-)

Regards,
--
Nils Goesche
Ask not for whom the <CONTROL-G> tolls.

  Ideas influence people in sundry ways.  Books that are written with the
  purpose of expanding on a particular idea is always responsible for the
  readers and their reactions.  The ultimate example is what religions call
  their holy scriptures -- they are credited with giving people a sense of
  meaning in their lives.  Various other books have had the same effect on
  people, such as Atlas Shrugged.  When something bad happens to people who
  "believe" in these books, a lot of people claim that the religion, book,
  etc, had nothing to do with it.

| Maybe some people just /are/ stupid, or maybe it is possible to pass the
| course without understanding the book, I don't know.

  Gee, I would to like visit your planet.  Here on earth, stupidity is the
  most common mental illness and it has no cure.  Intellectual laziness is
  the result of the dramatic absence of any need to think for the common
  citizen, so most people get by unexercised, just like they do with their
  physical well-being.  I think "fathead" is very descriptive.

| Sorry for insisting like this, but I really think it's a good book and
| keep recommending it to people, but I wouldn't want to create new Scheme
| fanatics that way, of course :-)

  The book is actually a very good read _after_ you understand much more
  than it tries to teach and have the background knowledge to keep it in
  context.  It puts things into a context of its own that differs greatly
  from other contexts that you cannot expect people to have.  Many books
  that have "influential" ideas work this way because they are somehow
  "detached" from the world people normally experience and live in, yet
  "explain" things to them with stunning clarity -- which is not hard if
  you do not have to be bothered by the real world.  In this way, it is far
  easier to tell a wonderfully elegant lie about something that is not than
  it is to find elegance in what is.  I mean, Hollywood would not _be_ if
  it had not always been easier to tell a wonderful story than to live a
  wonderful life, but believing that one lives in a Hollywood world does
  people a lot of harm.  Likewise, not understanding that SICP tells a
  wonderful story can seriously hurt the immature mind.

  Intelligent people can be far more stupid than unintelligent people,
  because the latter do not have the intellectual capacity of the former to
  create a "better" world of their own in which they can pretend to liv,
  and get away with it.  Intelligence is merely higher ablity, stupidity is
  the lack of skill in using whatever abilities you have.

  Oh, but anomalies do not disprove a general assertion, nor do they make
  good material for generalization to begin with.  If a person has been
  trained in some other language before being trained in Scheme, they have
  much better chances of not being brainwashed by Scheme, because there is
  something there to begin with.  I should perhaps clarify that I mostly
  consider the problem of "Scheme as the first programming language".

Regards,
--
Nils Goesche
Ask not for whom the <CONTROL-G> tolls.

Regards,
--
Nils Goesche
Ask not for whom the <CONTROL-G> tolls.

  I only argue that books that expand on ideas affect people in many
  strange ways.  The book clearly has partial "blame" because it erects its
  own context without sufficient ties and references to the world around it
  to make it clear that it is a wonderful story, not a description of the
  real world.  Since most people are not trained in integrating what they
  hear with what they know, the creation of a context _outside_ of their
  normal frame of reference is _dangerous_.  Bridging between the context
  of a book/idea and the real world is very necessary.  The course and the
  professor would both have to be _exceptional_ to bridge the context of
  SICP with the real world of programming computers.  (I would argue that
  the same is true for K&R's C book, because it also creates a very simple
  world/context that simply is not real and which has deluded C programmers
  that they live in the "virtual world" that C is good at programming in.)

| If this is the case in such courses, I think it is really not justified
| to blame the book if something bad comes out of them (of course I don't
| know how such courses look like at American universities, sorry about
| that).

  When _would_ it be justified to blame the book?

| I know what you mean, and you are right.  But don't forget that there are
| always a few, very few, among these idiots who are only `sleeping' and
| might, at some time, `awake'; much of the teaching effort is all about
| making those `sleepers' awake.

  That was very poetic and beautifully said.

  Yes, you should read it.  It adds an important perspective on many things
  that are difficult to understand in our complex society, but do not
  mistake the perspective for the whole story, which is the advice common
  to SICP.  It is especially important it if you are inclined to think that
  only the "working masses" are worth fighting for and believe that the
  owners exploit them -- since there are billions of words written on how
  bad business people are, it is quite interesting to see things more from
  their "side".  It is wisely written as a novel, in which you can immerse
  yourself and suspend disbelief and really enjoy it, but some people never
  unsuspended their disbelief and have become rather "nutty" as a result,
  arguing and living as if the world described therein _is_ the real world.
  (The author once said the proof that the world she described was real was
  that she could write the book.  Whichever way you try to understand this,
  it is a warning sign.)  From a philosophical perspective, it provides an
  opportunity to understand a view that implicitly underlies much of modern
  society but which is fought and misrepresented by those who would rather
  return to the tribal societies of, e.g., the Taliban, or the socialist
  hell that the author barely escaped (but which never escaped her, like
  many very traumatizing events in people's life, and which must be kept in
  mind to understand what she is actually rebelling against).  My signature
  is my summary of a lot of hardship both witnessed and experienced when I
  found to my surprise that it was actually hard to let go of the desire to
  fight against the Norwegian tax authorities when they finally released
  their death grip after 15 years of hell and I felt more empty than happy.
  (I think Ayn Rand would have been a very different person had she been
  able to pick herself up and go on, rather than delve on the evils she had
  endured and latched into a "live to tell" mode that some victims of evil
  have a tendency never to get out of.)  From a literary perspective, she
  has really mastered the "romantic" school of description of people and
  landscapes alike, but it is not naturalistic, and therefore appear to
  _be_ only what she describes.  This is another commonality with SICP that
  it takes some literary exposure to be comfortable with.  Naturalism is
  the school that argues that you should tell the whole story, while the
  romantic school argues that you should say only what is important to
  understand something, discarding the inessential.  I suspect that you
  will have no problem with this since you could absorb the good ideas from
  SICP without believing that what was omitted does not exist.

  I think further discussion should go in mail; this is way off-topic.

I guess K&R probably _ARE_ responsible for an entire generation of C programmers
who don't check the return codes of their system calls.  K&R would probably
argue that they were trying to teach C, not proper program design and defensive
programming.

Abelson & Sussman probably _ARE_ responsible for an entire generation of Scheme
programmers thinking that iteration is "impure and degraded", _completely_ missing
SICP's point that an iterative _PROCESS_ can be written in recursive form, (given
a guarantee of tail recursion).  SICP was trying to teach about the underlying
algorithmic structure.  

In both cases, that countless morons didn't get it isn't really the author's
fault.

These arguments would apply even more strongly to religious texts, IMO.
(When was the last time you saw a "christian" giving away all their worldly
 possessions and devoting themselves to their fellow man!?)