Re: Opinions on intro lisp books

casioculture@xxxxxxxxx wrote:
> Geoffrey King wrote:
> > Wow, *i* would never learn that way. Sounds very 19th century. I would
> > approach it from the opposite manner, which thematically would be: what
> > i am trying to do dictates what i learn. By programming analogy its top
> > down.
> >
>
> Well I must ask for forgiveness for seeming to argue with you guys,
> after all, you're far more knowledgeable, but I have the newbie
> perspective for the time being.

Well, as long as you qualify your statements that much, I doubt anyone
will hold them against you ;).

> Yes, I would learn Gawk or Tcl-sqlite that way, and I am. After all,
> there's not much to them. But Lisp is a little different, I found. From
> what I read so far, according to Paul Graham, It's a "bottom-up"
> language, not a "top-down" one.

Languages aren't really "bottom-up" or "top-down", for the most part.
Some languages support one style of programming better than they
support the other, according to some people (and in some cases there is
little room for argument- Forth is a good example).

Even if that weren't the case, I'm not sure that a language being a
"bottom-up" language would imply that it should be learned in a
"bottom-up" fashion.

> I would learn some industrial language that was designed to do a
> specific thing that "top-down" "only-what-I-need" way, but Lisp it
> seems was designed to be an implementation of a universal computation
> theory, namely lambda calculus.

This winds up not being that relevant to learning to use CL, in
practice. CL is a descendant of McCarthy's original work, but a lot of
water has gone under the bridge since then. Remember that McCarthy
doesn't seem to have intended that his language actually be
implemented. Or just go look at some early Lisp (LISP, actually), and
compare it to recent code.

People who program professionally, and expect to be taken seriously,
should know something about the theory of computation, no matter the
language they program in. Amateurs can be forgiven for not knowing much
about the theory, as long as they don't pretend that they do (in which
case they should be shot at dawn, and buried without ceremony).

I don't believe that learning to program in CL requires more theory
than learning to program in PHP.

> I don't have anything immediate that I need to do with lisp, do I
> really need to learn it in 10 days? No, I really don't, I'd rather
> learn it in ten years, and if after a year I find that I had learnt it
> 'all', and by 'all' I mean all I want out of it, i'd rather be suprised
> rather than be cursing that it should've taken me ten days.

OK, first, I wish you wouldn't top post. There are some points I'd like
to make in context, and I just can't do that, given your post, without
cutting and pasting people's words in ways that would be unfair to
them, arduous, or both. Please don't be offended, as I mean this in the
kindest way- just don't top post in the future. Trim what you aren't
responding to.

Anyway, I thought that the analogy with learning Japanese made
elsewhere in this thread was interesting. I have always liked learning
foreign (to me, of course) languages, and I am particularly interested
in ways to accelerate that learning. Japanese is my current project,
and also a testbed for my "theories" (I put that in quotes because I
lack qualifications in the field of language acquisition- my theories
on the subject may be the equivalent of the theories proposed by
devotees of perpetual motion). I would like to see if I can pass the
JLPT 2 given one year of study in my spare time (I already speak and
read Chinese a bit, which helps with the kanji, and the cognates)- so
far I think I am on a very good pace to do that, and I may even decide
to take JLPT 1 next fall (the test is administered once a year).

I'm generally suspicious of arguments from analogy, and I think that
learning a programming language is very different from learning a
spoken language. I do think that there is some carryover from what I
know about human language acquisition though.

I think it's best, when learning a new language, to approach it from a
few different directions. So, in studying Japanese, I make sure to
watch a lot of Japanese media, with subtitles, listening carefully to
the spoken language, but I also make sure to read texts on Japanese
grammar that are way over my head. I don't push too hard, with the
latter. If I fail to understand something after a few minutes, I move
on. I also make sure that I go back a while later and skim again.

Each time, a bit more sticks, and I can read dense tomes quickly, since
I aim only at understanding what is accessible to me. I also take the
middle road- I read textbooks meant for English speaking students of
Japanese, but I do not treat them the way that a student preparing for
an exam would. The results, so far, are encouraging. I understand
spoken Japanese as well, after a month or so, as I understood spoken
Chinese after taking intensive classes, at a good University, for a
year or two- my vocabulary is, of course, smaller, and I can't speak
well yet, but it is encouraging.

I'd suggest a similar approach to learning Lisp. Immersion works, and
it is most important to have the same information presented repeatedly
in different contexts. Don't read Text #1, Text #2, and Text #3 in
order, waiting till you understand everything in a given paragraph to
advance to the next. Get each, and read them repeatedly, in order, out
of order, etc., letting each reinforce the lessons of the other. At the
same time, write programs in CL, even if they are trivial at the
beginning. And don't decide that a given attribute of the language is
stupid until you understand it from all angles.

So, my recommendation for intro lisp texts is: all of them, from the
simplest to the most complex. Also, there are a number of systems out
there, written in CL, that do useful things. Read the code, but don't
worry if you only understand parts of it right now. Come back and
reread it in a while- you will understand more.

If I had to suggest a progression for a smart, experienced programmer
who wasn't familiar with any variant of Lisp, I'd suggest this order:

1) Paul Graham's ANSI Common Lisp.

2) The first few chapters of OnLisp, also by Graham, and free in pdf
format- stop when you get to where he talks about gensyms- I believe
that is chapter 10. Finish it later- there is no reason for you to
worry about the things in later chapters right now, as they are quite
advanced, but it wouldn't hurt you to skim those chapters.

3) PAIP, by Norvig. Great book.

If you find this order tricky, then "A Gentle Introduction...." is
probably appropriate. It progresses very slowly, and explains things
that most programmers should probably understand already, but that many
actually don't. I was unable to get past the beginning- too slow, too
basic. If you are new to programming, as well as CL, this might be a
good place to start.

Practical Common Lisp is a good book to read while reading the others,
if you want to use CL to accomplish the kinds of tasks that people
usually use "scripting" languages for. It is well written, and fills a
very important gap, but it will be out of date in the near future, in
my opinion. So will everything on the O'Reilly bookshelf, so I don't
mean that as a serious criticism; just an observation. I tend to prefer
the "timeless classics", but there's no doubt that writing and
publishing PCL is a virtuous act.

SICP is wonderful, but it is written around Scheme, and the first
chapter requires more math than most newbie programmers have. Slog
through, it's worth it. You will uinderstand Lisp- well not Lisp
precisely, but... well, call it Lisp for now, better after
understanding the parts about metacircular evaluators. SICP is really
more of a book about thinking about programming than it is a book
specifically about any Lisp, let alone CL.

HtDP is another book I couldn't get through because it was too basic.
It seemed very good though, for people learning to build systems.

So- very long post, responding to a fairly old post. Sorry about that.
I hope someone finds it helpful.

.