For various sundry reasons that I won't go into, I have not been doing
any Lisp hacking (or any other kind for that matter) lately. I'm
interested in using OpenMCL to target OS X for a project (although I
am not absolutely sure about Apples commitment to continue to exist as
a computer company).
What I want to do is take a step back to the basics. My last Lisp
hack looks like a C program written in Common Lisp. I really need to
get out of that style. I also have no Comp Sci background. So I am
interested in an efficient (for some value of efficient) means to not
only get comfortable with Common Lisp but also to get into Lisp Think.
I have the dead tree editions of Paul Graham's ANSI Common Lisp and On
Lisp, Peter Norvig's PAIP, Keene's Object Oriented Programming in
Common Lisp, and The Art of The Meta Object Protocol. I am aware of
Peter's ongoing online book and have the PDF version of David
Touretzky's Common Lisp: A Gentle Introduction to Symbolic
Computation.
My environment is Carbon Emacs (from CVS) + SLIME (from CVS) + OpenMCL
0.14.2p1 with some CVS updates on OS X 10.3.5 running on a 12" PowerBook
G4 1st edition.
While I am not an absolute beginner I would like to shake away my
C/C++ thinking. I think it has held me back. With that in mind, what
sequence of books and chapters from the above would you recomend,
particularly the exercises, that I should go through for a well
rounded Common Lisp programming discipline?
I would like to stay ANSI for as long as possible to get my Lisp Think
before I embark on the non-portable features of FFI, sockets, and GUI
type stuff where I will probably work at the OpenMCL metal.
Thanks in advance for any thoughtful responses and advice.
P.S. I've done just enough Lisp hacking to be ruined for C (not that
there is anything wrong with C) for general purpose, ie applications,
programming. Damn Lisp for being so cool that I don't want to really
muck about with Objective-C or C in Xcode.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
David Steuber <·····@david-steuber.com> writes:
> While I am not an absolute beginner I would like to shake away my
> C/C++ thinking. I think it has held me back. With that in mind, what
> sequence of books and chapters from the above would you recomend,
> particularly the exercises, that I should go through for a well
> rounded Common Lisp programming discipline?
I had a similar experience. At one time, I tried writing a program in
Emacs Lisp, but it felt like I was stuck in the C mindset. Then, a
few years ago, I tried again with Common Lisp. This time, I read many
books before writing any serious program. For some reason, it now
feels much easier to write programs that (I like to think) are more
Lispy than C-y.
The sequence of Lisp books went something like CLtL2, PAIP, ACL
(Graham), On Lisp, OO Programming in CL (Keene), AMOP. And Thinking
FORTH somewhere in there, which is probably another good influence
away from C thinking.
--
Lars Brinkhoff, Services for Unix, Linux, GCC, HTTP
Brinkhoff Consulting http://www.brinkhoff.se/
David Steuber <·····@david-steuber.com> writes:
> While I am not an absolute beginner I would like to shake away my
> C/C++ thinking. I think it has held me back. With that in mind, what
> sequence of books and chapters from the above would you recomend,
> particularly the exercises, that I should go through for a well
> rounded Common Lisp programming discipline?
>
> I would like to stay ANSI for as long as possible to get my Lisp Think
> before I embark on the non-portable features of FFI, sockets, and GUI
> type stuff where I will probably work at the OpenMCL metal.
Well, I feel that a good book to leave definitely the C mindset is
SICP. Unfortunately, the SICP code examples are written in
Scheme. Fortunately, that means that you have an opportunity to write
them in Common-Lisp.
http://mitpress.mit.edu/sicp/
http://swiss.csail.mit.edu/classes/6.001/abelson-sussman-lectures/
Check too: http://www.cliki.net/education
--
__Pascal Bourguignon__ http://www.informatimago.com/
Voting Democrat or Republican is like choosing a cabin in the Titanic.
Pascal Bourguignon <····@mouse-potato.com> writes:
> Well, I feel that a good book to leave definitely the C mindset is
> SICP. Unfortunately, the SICP code examples are written in
> Scheme. Fortunately, that means that you have an opportunity to write
> them in Common-Lisp.
Hmmm. I have the dead tree of SICP. I didn't really think of it
because it is Scheme rather than Common Lisp. But what you say does
make sense.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
David Steuber wrote:
> For various sundry reasons that I won't go into, I have not been doing
> any Lisp hacking (or any other kind for that matter) lately. I'm
> interested in using OpenMCL to target OS X for a project (although I
> am not absolutely sure about Apples commitment to continue to exist as
> a computer company).
>
> What I want to do is take a step back to the basics. My last Lisp
> hack looks like a C program written in Common Lisp. I really need to
> get out of that style. I also have no Comp Sci background. So I am
> interested in an efficient (for some value of efficient) means to not
> only get comfortable with Common Lisp but also to get into Lisp Think.
>
> I have the dead tree editions of Paul Graham's ANSI Common Lisp and On
> Lisp, Peter Norvig's PAIP, Keene's Object Oriented Programming in
> Common Lisp, and The Art of The Meta Object Protocol. I am aware of
> Peter's ongoing online book and have the PDF version of David
> Touretzky's Common Lisp: A Gentle Introduction to Symbolic
> Computation.
>
> My environment is Carbon Emacs (from CVS) + SLIME (from CVS) + OpenMCL
> 0.14.2p1 with some CVS updates on OS X 10.3.5 running on a 12" PowerBook
> G4 1st edition.
>
> While I am not an absolute beginner I would like to shake away my
> C/C++ thinking. I think it has held me back. With that in mind, what
> sequence of books and chapters from the above would you recomend,
> particularly the exercises, that I should go through for a well
> rounded Common Lisp programming discipline?
>
> I would like to stay ANSI for as long as possible to get my Lisp Think
> before I embark on the non-portable features of FFI, sockets, and GUI
> type stuff where I will probably work at the OpenMCL metal.
>
> Thanks in advance for any thoughtful responses and advice.
>
> P.S. I've done just enough Lisp hacking to be ruined for C (not that
> there is anything wrong with C) for general purpose, ie applications,
> programming. Damn Lisp for being so cool that I don't want to really
> muck about with Objective-C or C in Xcode.
Let me suggest that you find a copy of Norvig's _Paradigms of Artificial
Intelligence Programming_, skim it, pick out whichever project in there
looks most interesting, and implement it. Then change it to add some
features that interest you.
Although not inaccurate, the title is partly misleading, because the
stuff in the book isn't just AI stuff; there are lots of other
interesting things in there too, including a simple and understandable
Scheme interpreter and compiler, and a unification engine a la Prolog.
The full code of the projects is included, so you can just type it in
(or find it online, but that will be much less helpful in learning to
think in Lisp). The code is broken up somewhat across chapters, so in
order to build a working example you have to look up auxiliary utility
functions in the index, but that helps force you to think about what
they're for and what they do.
The examples (even the compiler) are fairly short and easy to
understand, but they are (simplified versions of) real programs that do
useful things, and they are easy to modify to add features that intrigue
you. And the don't depend in any way on the grungy things you are
wanting to avoid.
Implement and modify one or two of these things and you'll be in good
shape, Lisp-thinking-wise. For extra Lispy goodness I suggest
implementing a simple knowledge-representation framework. That won't be
much like any C code you are likely to have written, and there's always
something you can use a knowledgebase for, if you have one lying around.
Kind of like some power tools: if you don't have one, you won't miss it,
but if you do have one, you'll think of all sorts of things it could be
used for.
"mikel" <·····@evins.net> wrote in message
·······················@newssvr13.news.prodigy.com...
> The full code of the projects is included, so you can just type it in
> (or find it online, but that will be much less helpful in learning to
> think in Lisp). The code is broken up somewhat across chapters, so in
> order to build a working example you have to look up auxiliary utility
> functions in the index, but that helps force you to think about what
> they're for and what they do.
Typing the stuff in is key. Downloading or cut-n-pasting the code in doesn't
work at all (for me).
By typing it in you get the opportunity to think about each element that you
key in (assuming you don't simply go into a "transcribe/10-key/brain on
hold" mode).
You also get the great delight of finding your typos.
This is important because it teaches you how your environment reacts to
different errors. And since you have (ideally) the "correct" source handy to
compare against, you don't necessarily have to go through the pain of
actually debugging it, but it does give you experience in see error
messages, interpreting error messages and correcting the code.
What typing the code does is it lets you go through the mechanics of a
Common Lisp program, without necessarily have to do the "hard work" of
coming up with the design and algorithms and looking up the proper CL
functions and structures.
Just like buying a car off the lot doesn't teach you anything about how a
car works, downloading example source code doesn't really help you
understand the nuances of the technique. Typing the code in helps ensure
that you don't skip over something that you might while simply reading the
code.
Also, as you type in a bunch of CL source code, you'll start getting the
muscle memory to learn common idioms, learn your editor and environment,
etc.
Finally, you need to know very little CL to start this technique. You can
learn each function as it shows up, look it up in the Hyperspec, or
whatever. This, again, is much easier as you key the tokens in because as
soon as you type MAPCAR, you can say "What's MAPCAR?" and look it up.
Good Luck!
Regards,
Will Hartung
(·····@msoft.com)
Will Hartung wrote:
> Finally, you need to know very little CL to start this technique. You
can
> learn each function as it shows up, look it up in the Hyperspec, or
> whatever. This, again, is much easier as you key the tokens in
because as
> soon as you type MAPCAR, you can say "What's MAPCAR?" and look it up.
I've found the back of Graham's Ansi CL to be very useful here. That
quickref where things are laid out well. Fortunately the OP says he has
it. I hear the upcoming Margolies APress book will do something like
it, but I haven't seen a table of contents yet or know anything about
it.
There are two main themes I've noticed about programming in lisp. One
is while there is syntax, the default (idea thing thing thing) is a
seductive and massive simplification of thought. In other languages
like Java, {} indicates a power out of your hands, while () indicates
something you can change. While Lisp has areas out of your power too,
they're far fewer and subtler.
That's a special case of the 2nd theme, which is lisp invites you in to
have a deeper symbiosis with the system. I probably noticed this after
learning about compiler macros. Here, the compiler might ask for your
advice on how to optimize something. It is this obscure little area of
lisp, yet I can imagine a person writing a compiler thinking, "Hmm, I
would like programmatic access to compiler optimizations." And I think
this person had to know what it was like to be an empowered lisp user,
because he or she didn't think programmers were children to be given
strict rules and kept away from programming inappropriate things.
The reason I think the 1st is a special case of the 2nd is because lisp
allows one to have syntax, it just tries to minimize its own use of
syntax. If it didn't, that prebuilt syntax may be an obstacle. With
loop, what do people want to do with it? Build in ways to extend it.
Incidentally, about SICP/HTDP... I personally had to unlearn the Scheme
worldview. ;) If you take the Scheme stuff as just a view from another
language, without macros or whatever, then it's perfectly fine and
educational. But one should note that all SICP has on macros is two
tiny footnotes on them, one of them being negative. No mention of them
in Little/Seasoned Schemer books, and I suspect HTDP is like that too
("Programs are function plus variable definitions.") but I haven't read
it.
MfG,
Tayssir
David Steuber wrote:
> So I am
> interested in an efficient (for some value of efficient) means to not
> only get comfortable with Common Lisp but also to get into Lisp Think.
Besides SICP consider studying the recipes in HTDP (http://www.htdp.org>).
The recipes, although rigid at first sight, really teaches you how to
think, when you program.
--
Jens Axel Søgaard