general thoughts

[Alex Martelli]

Dave Kuhlman wrote:
        ...
>>> I think you need substantial capacity and appetite for abstract thought
>>> to really _enjoy_ SICP -- it doesn't spoon-feed you, nor does it use
        ...
> This book is a huge time sink.  One section shows you how to fake object
> oriented programming in a dialect of lisp with no O-O support.  After
> working through that section, I asked myself, Why do I need to know this?
> What good is it going to do me, unless I'm using a lisp dialect that does
> not support object-oriented programming?

People who like to think abstractly generally also like to have
multiple switchable mental models of how something like method
dispatching could be implemented.  People who prefer concrete
thinking generally want ONE such mental model, preferably the
exact one they're dealing with at a given time.

That's NOT a put-down of either kind of people - we NEED both
kinds, and there's a synergy between the two types when put in
the same time, although clashes are quite possible too.

I'd never suggest SICP to somebody who prefers concrete thought.
It's not a matter of more or less intelligence, please note, but
of the WAY one's mind prefers to work.


> And, a large part of the book describes how to program without variables
> and
> state.  That's weird and interesting, just like the Elephant Man was weird
> and interesting.  But, after that, then what?  Am I supposed to try to
> program that way?

You can choose to -- or you can choose to add another capability
of abstraction to your panoply of such.  You probably already
have a mental model of computation WITH side effect -- now you've
added another, of computation WITHOUT side effect.  Python happens
to have just enough functional flavor (though GvR doesn't like
that:-) that this specific capability has some use.  Actually
(see Coplien's "Multi-paradigm DESIGN for C++") a reasonable
collection of mental models for highly varied paradigms can come
in useful even when you might not think so.  Procedural, OO,
functional, relational, logical/constraint ... they all have their
place even if you're forced to code in machine code, and so do
the various subflavors (e.g., the many ways in which OO can be
approached -- with or without multiple dispatching, the many
ways to model and implement dispatching, etc).

For example, often you build little languages for task specific
issues, embedded in whatever other languages you're programming
with.  Scheme and Lisp are quite good for that, but you can and
do perform such activities in any language.  Then, having some
model of paradigms you can use and how to implement them is nice.


> What is the lesson to be learned from "Structure and interpretation of
> Computer Programs"?  Maybe it's main purpose is to provide an enjoyable
> read for those who have still not given up on lisp.

It's not about Lisp -- it's about mental models of computation.

SICP's purpose is definitely not to give concrete, usable-today
tips.  It's to broaden your horizons, enriching your panoply of
mental models about computation.  That's why it's no good for
people who like to think concretely, and why the "gurus like this
book" diagnosis is unfair to many brilliant people who _don't_.


> Seriously, what was I supposed to have gained from all that time I spent
> on
> this book.  As you may suspect, it captivated me, too.

Aha -- this sounds like somebody WITH appetite for abstract thought
(else you wouldn't have liked it) subject to cultural / peer pressures
towards concreteness (else you wouldn't feel that broadening your
horizons, without learning anything immediately-usable, might be
a waste of time).


> It did not teach me good Python programming style.  I could not hardly
> read my own code with all those many layers of parentheses.

True, alas -- lispish concrete syntax [expletive deleted] -- expect
mild flames from those who like it, of course:-).

> It did not teach me how to use Python data structures.  I found myself
> doing too many screwy things with lists.

Python's lists are definitely not what you want as a direct
replacement for lisp/scheme ones -- you can build the latter
with two-item tuples (if immutable) or lists (if mutable) a la:

class lispnode(object):
    __slots__ = '_car', '_cdr'
    def __init__(self, car=None, cdr=None):
        self.car = car
        self.cdr = cdr
cons = lispnode

and any embellishments you want to iterate on lispish lists made
of such nodes, form such a lispish list from any Python iterable, &c.


> I was supposed to learn something more theoretical, right?  What was it?

See above.


> Or, was this book just a devious way to trick more people into using lisp?

Naah... not in the concrete-syntax way.  It's just that some
concepts are fruitful and usable even in other languages.


Alex