Hello all,
i have got a short question. After programming and designing for over 20
years and climbing up on following ladder
Basic->6502->Logo->Pascal->C->Fortran->C++->Python I realized I am in a
need of a language that let me stronger express my thinking. I am
somewhat familiar with the Lisp as I use Emacs almost exclusively but
really lacking some fundamentals.
So what would be a next step I need to make. What strategy would you
recommend to adopt in order to make the biggest strides in the shortest
time and avoid the most common misconceptions as well as pitfalls.
Looking forward for a good stuff,
Andy
AlFire <····················@ggmail.com> writes:
> i have got a short question. After programming and designing for over
> 20 years and climbing up on following ladder
> Basic->6502->Logo->Pascal->C->Fortran->C++->Python I realized I am in
> a need of a language that let me stronger express my thinking. I am
> somewhat familiar with the Lisp as I use Emacs almost exclusively but
> really lacking some fundamentals.
Welcome!
> So what would be a next step I need to make. What strategy would you
> recommend to adopt in order to make the biggest strides in the
> shortest time and avoid the most common misconceptions as well as
> pitfalls.
>
> Looking forward for a good stuff,
Once you've read PCL, have a look at SICP. Well, not just a look,
study it deeply ;-)
SICP = Structure and Interpretation of Computer Programs
http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html
http://swiss.csail.mit.edu/classes/6.001/abelson-sussman-lectures/
http://www.codepoetics.com/wiki/index.php?title=Topics:SICP_in_other_languages
http://eli.thegreenplace.net/category/programming/lisp/sicp/
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Indentation! -- I will show you how to indent when I indent your skull!"
On Sep 19, 3:32 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Once you've read PCL, have a look at SICP. Well, not just a look,
> study it deeply ;-)
>
> SICP = Structure and Interpretation of Computer Programs
> http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html
> http://swiss.csail.mit.edu/classes/6.001/abelson-sussman-lectures/
> http://www.codepoetics.com/wiki/index.php?title=Topics:SICP_in_other_...
> http://eli.thegreenplace.net/category/programming/lisp/sicp/
+1
The SICP video series is amazing.
Adam
AlFire schrieb:
> Hello all,
>
> i have got a short question. After programming and designing for over 20
> years and climbing up on following ladder
> Basic->6502->Logo->Pascal->C->Fortran->C++->Python I realized I am in a
> need of a language that let me stronger express my thinking.
Can you explain a bit more in what way Python does not allow you to
express your thoughts strongly enough?
Do you have something specific in mind that you expect about Lisp?
Andr�
--
From: Vilho =?utf-8?B?UsOkaXPDpG5lbg==?=
Subject: Re: Lisp for begginer
Date:
Message-ID: <87vdws4u2d.fsf@iki.fi>
AlFire <····················@ggmail.com> writes:
> Hello all,
>
> i have got a short question. After programming and designing for over
> 20 years and climbing up on following ladder
> Basic->6502->Logo->Pascal->C->Fortran->C++->Python I realized I am in
> a need of a language that let me stronger express my thinking. I am
> somewhat familiar with the Lisp as I use Emacs almost exclusively but
> really lacking some fundamentals.
>
> So what would be a next step I need to make. What strategy would you
> recommend to adopt in order to make the biggest strides in the
> shortest time and avoid the most common misconceptions as well as
> pitfalls.
>
> Looking forward for a good stuff,
>
> Andy
I came from C++ background and Seibel's book got me hooked. You can take
a look at it for free (but be warned, you probably will end up buying it
anyway):
http://gigamonkeys.com/book/
After that, I read Graham's ANSI Common Lisp. Browse this newsgroup for
more advanced reading.
BR,
Vilho
--
AlFire <····················@ggmail.com> writes:
> Hello all,
>
> i have got a short question. After programming and designing for over 20
> years and climbing up on following ladder
> Basic->6502->Logo->Pascal->C->Fortran->C++->Python I realized I am in a
> need of a language that let me stronger express my thinking. I am
> somewhat familiar with the Lisp as I use Emacs almost exclusively but
> really lacking some fundamentals.
>
> So what would be a next step I need to make. What strategy would you
> recommend to adopt in order to make the biggest strides in the shortest
> time and avoid the most common misconceptions as well as pitfalls.
Given that you have a deep background in programming languages, I would
recommend starting with Peter Norvig's Paradigms of Artificial
Intelligence Programming: Case Studies in Common Lisp. (PAIP)
It is not a tutorial in Lisp, but it does have a compact introduction to
the language. But for someone with a background in programming, it can
get you going in the language very easily. The real benefit is the
description of different programming techniques from AI, and the code
that shows how you would implement parsers, knowledge representation
systems, rule engines, etc.
More info at <http://www.norvig.com/>
For some people, the introduction and description in PAIP is a bit too
terse, since it isn't really designed as a tutorial, but rather as a
quick introduction to lisp. In that case, I would recommend Peter
Seibel's book, based on the many postitive reviews that it has gotten.
--
Thomas A. Russ, USC/Information Sciences Institute
On Thu, 2008-09-18 at 20:14 -0700, AlFire wrote:
> Hello all,
>
> i have got a short question. After programming and designing for over 20
> years and climbing up on following ladder
> Basic->6502->Logo->Pascal->C->Fortran->C++->Python I realized I am in a
> need of a language that let me stronger express my thinking. I am
> somewhat familiar with the Lisp as I use Emacs almost exclusively but
> really lacking some fundamentals.
>
> So what would be a next step I need to make. What strategy would you
> recommend to adopt in order to make the biggest strides in the shortest
> time and avoid the most common misconceptions as well as pitfalls.
>
> Looking forward for a good stuff,
>
> Andy
hi,
this would have saved me a ton of time and hassle back when i was
learning lisp:
stick to "this-style" .. don't try to "doThis" using read-table tricks
etc.
if you're on linux, which you should be; don't bother installing lisp
software (both implementations and libraries) using distro packages
stick with emacs; just add slime to it
forget all you think you know about OOP
forget all you think you know about exceptions, conditions and handling
of this
..about reading i'd start with Practical Common Lisp and make sure you
keep the Common Lisp reference (hyperspec) near at all times
http://gigamonkeys.com/book/
http://www.lispworks.com/documentation/HyperSpec/Front/index.htm
ftp://ftp.lispworks.com/pub/software_tools/reference/HyperSpec-7-0.tar.gz
On Lisp is also nice, but don't start with it though:
http://www.paulgraham.com/onlisp.html
..and don't give up; be persistent .. it's worth it
--
Lars Rune Nøstdal || AJAX/Comet GUI type stuff for Common Lisp
http://nostdal.org/ || http://groups.google.com/group/symbolicweb
> don't bother installing lisp
> software (both implementations and libraries) using distro packages
wasn't the Debian Common Lisp Controller supposed to be a good thing?
On Sep 19, 6:30 am, Giovanni Gigante <····@cidoc.iuav.it> wrote:
> > don't bother installing lisp
> > software (both implementations and libraries) using distro packages
>
> wasn't the Debian Common Lisp Controller supposed to be a good thing?
The purpose behind c-l-c is to allow a distro to package and ship lisp
source code and have it work on a variety of lisp compilers on the end-
user's machine. That's a noble goal, but has nothing do do with the
reason most people want lisp : to develop lisp applications.
C-l-c is a hack for a specific purpose... don't use it unless you
happen to be, say, building a linux distro. And even then ... do we
recompile every C application on the system when we download a new
compiler? Do we keep 4 complied versions of our binaries around for
GCC, TCC, ICC etc? No, we don't. And when we request the source
package of a c library, we don't get a special 'C controller' that
automatically and brokenly makes the libs available to the compilers
somehow.
Something like sb-heapdump is a better solution than c-l-c for
distributing lisp apps on debian. C-l-c is really just a solution
looking for a problem, and causes more support headaches for me than
any other simple lisp-on-linux feature.
Cheers,
drewc
??>> don't bother installing lisp
??>> software (both implementations and libraries) using distro packages
GG> wasn't the Debian Common Lisp Controller supposed to be a good thing?
it was supposed to be, but it failed :). i think reason for this is that
lisp libraries
nowadays evolve much faster than debian release cycle, so if you use
packages
from your distro, you end up with pile of obsoleted stuff, and you
constantly hear
"this is available in a new version, this is fixed in a new version"...
still, probably it's good enough to start with -- install implementation,
bunch
of libs and experiment with them. later, when one find limitations and bugs
in bundled implementations and libs he can build lisp from source and use
libraries directly from repositories.
Giovanni Gigante <····@cidoc.iuav.it> writes:
>> don't bother installing lisp
>> software (both implementations and libraries) using distro packages
>
>
> wasn't the Debian Common Lisp Controller supposed to be a good thing?
It's not up to it.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"You cannot really appreciate Dilbert unless you read it in the
original Klingon"
Lars Rune N�stdal <···········@gmail.com> writes:
> if you're on linux, which you should be; don't bother installing lisp
> software (both implementations and libraries) using distro packages
That's my advice in general too, but I must say that on gentoo,
nowadays, it works very well to "emerge" the cl-* package (as long as
you install and use asdf-binary-location, and make sure
common-lisp-controler is not installed).
--
__Pascal Bourguignon__ http://www.informatimago.com/
"You cannot really appreciate Dilbert unless you read it in the
original Klingon"
Lars Rune Nøstdal <···········@gmail.com> writes:
>
> if you're on linux, which you should be; don't bother installing lisp
> software (both implementations and libraries) using distro packages
I've had good luck with the Fedora packages for SBCL. You're absolutely
right about libraries though--just use ASDF-INSTALL and get on with
writing cool software:-)
--
Robert Uhl <http://public.xdi.org/=ruhl>
If your adversary is badly bunkered, there is no rule against your
standing over him and counting his strokes aloud, but it will be a wise
precaution to arm yourself with the niblick before doing so, so as to
meet him on equal terms. --Horace G. Hutchinson, 1886
In article <··············@ggmail.com>,
AlFire <····················@ggmail.com> wrote:
> Hello all,
>
> i have got a short question. After programming and designing for over 20
> years and climbing up on following ladder
> Basic->6502->Logo->Pascal->C->Fortran->C++->Python I realized I am in a
> need of a language that let me stronger express my thinking. I am
> somewhat familiar with the Lisp as I use Emacs almost exclusively but
> really lacking some fundamentals.
>
> So what would be a next step I need to make. What strategy would you
> recommend to adopt in order to make the biggest strides in the shortest
> time and avoid the most common misconceptions as well as pitfalls.
>
> Looking forward for a good stuff,
>
> Andy
Learn about Lisp style:
http://lispm.dyndns.org/documentation/norvig-lisp-style.pdf
Above is a paper written by Peter Norvig and Kent Pitman
many years ago. Much of that is still valid.
It's also useful to get an overview over the language.
ANSI CL from Paul Graham gives kind of an overview.
There is more than he describes, but you have to start
somewhere. Peter Seibel's book is good to get the
first coding started.
Make sure that you understand that the typical development
process is iterative, incremental and (very important)
interactive. If you don't work like that, the chance is high
that you are working against the language. Lisp
is not so much for batch programming. So make sure
that you understand and can use you development environment.
The needs for an interactive environment is a bit different
than what you may be used to when using 'batch' environments
(lot's of files, some build machinery, check in / check out,
long edit/compile/run/debug cycles, ...). Lisp environments
try to get you as near as possible to live code and data.
That's a huge difference.
--
http://lispm.dyndns.org/
On Sep 18, 11:55 pm, Rainer Joswig <······@lisp.de> wrote:
> http://lispm.dyndns.org/documentation/norvig-lisp-style.pdf
One of the recommendations in here that surprised me was to avoid use
of AND and OR for non-booleans, e.g.
(or (try-to-find-a-usable-frob)
(make-instance 'frob ...))
(and (check-precondition)
(compute-some-non-boolean-result))
I do this kind of thing all the time. I seem to recall this idiom
being very common in the Lisp Machine system code, which is where I
picked up a lot of my Lisp style. I'm curious what others think about
this (not that I'm likely to change my practice :)
The AND idiom is perhaps the less important because it's easy to
rewrite:
(and form0 form1 ... formN)
-> (if (and form0 form1 ...) formN nil)
but OR is harder because, in general, you have to bind a variable for
each non-final subform:
(or form0 . forms)
-> (let ((tmp0 form0)) (if tmp0 tmp0 (or . forms)))
Anyway, WDYT?
-- Scott
On 2008-09-23, Scott Burson <········@gmail.com> wrote:
> On Sep 18, 11:55 pm, Rainer Joswig <······@lisp.de> wrote:
>
>> http://lispm.dyndns.org/documentation/norvig-lisp-style.pdf
>
> One of the recommendations in here that surprised me was to avoid use
> of AND and OR for non-booleans, e.g.
Norvig since moved on to dicking around with Python, right? So these kinds of
recommendations are to be taken with a grain of salt.
> (or (try-to-find-a-usable-frob)
> (make-instance 'frob ...))
>
> (and (check-precondition)
> (compute-some-non-boolean-result))
Yes, very cryptic. Better write some macros:
(defmacro prog-until-something-returns-non-nil (&rest forms)
`(or ,@forms))
(defmacro prog-until-something-returns-nil (&rest forms)
`(and ,@forms))
Rightee-o.
> I do this kind of thing all the time. I seem to recall this idiom
> being very common in the Lisp Machine system code, which is where I
> picked up a lot of my Lisp style. I'm curious what others think about
> this (not that I'm likely to change my practice :)
>
> The AND idiom is perhaps the less important because it's easy to
> rewrite:
>
> (and form0 form1 ... formN)
> -> (if (and form0 form1 ...) formN nil)
Of course, the inner AND has to be rewritten, so you end up with
(if form0 (if form1 (if form2 ... (if formN-1 formN nil)) ... ))
> but OR is harder because, in general, you have to bind a variable for
> each non-final subform:
>
> (or form0 . forms)
> -> (let ((tmp0 form0)) (if tmp0 tmp0 (or . forms)))
For that, we have COND
(or form0 form1 ... formN)
->
(cond (form0) (form1) (formN))
> Anyway, WDYT?
OR is particularly useful if you care about the result.
(let ((object (or (try-getting-it-this-way)
(else-this-way)
*fall-back-on-this*)))
...)
No brainer. You could use COND, but it would just mean extra parentheses.
If the return value of the test forms provides not only the boolean indicator
of success, but also serves as the result value, then use OR. If the forms
provide only the test, which must be translated to a return value, or some
other action, with additional forms, then use COND.
On Sep 23, 2:02 pm, Kaz Kylheku <········@gmail.com> wrote:
> On 2008-09-23, Scott Burson <········@gmail.com> wrote:
>
> > The AND idiom is perhaps the less important because it's easy to
> > rewrite:
>
> > (and form0 form1 ... formN)
> > -> (if (and form0 form1 ...) formN nil)
>
> Of course, the inner AND has to be rewritten, so you end up with
>
> (if form0 (if form1 (if form2 ... (if formN-1 formN nil)) ... ))
No, the inner AND is returning a boolean, so it doesn't have to be
rewritten (according to the recommendation).
> > but OR is harder because, in general, you have to bind a variable for
> > each non-final subform:
>
> > (or form0 . forms)
> > -> (let ((tmp0 form0)) (if tmp0 tmp0 (or . forms)))
>
> For that, we have COND
>
> (or form0 form1 ... formN)
>
> ->
>
> (cond (form0) (form1) (formN))
Ah, right, I rarely use this -- not for any good reason, I just don't
tend to think of it.
> OR is particularly useful if you care about the result.
>
> (let ((object (or (try-getting-it-this-way)
> (else-this-way)
> *fall-back-on-this*)))
> ...)
>
> No brainer. You could use COND, but it would just mean extra parentheses.
My feeling also.
-- Scott
On 2008-09-23, Scott Burson <········@gmail.com> wrote:
> On Sep 18, 11:55 pm, Rainer Joswig <······@lisp.de> wrote:
>
>> http://lispm.dyndns.org/documentation/norvig-lisp-style.pdf
>
> One of the recommendations in here that surprised me was to avoid use
> of AND and OR for non-booleans, e.g.
And by the way, AND and OR are not boolean functions. They are operators
designed for evaluation control, which are dressed up to look like boolean
functions.
Norvig's recommendation boils down to ``I disagree with the design and purpose
of some basic Common Lisp functions, and so should you''.
What a crock.
On Sep 23, 2:23 pm, Kaz Kylheku <········@gmail.com> wrote:
> On 2008-09-23, Scott Burson <········@gmail.com> wrote:
>
> > On Sep 18, 11:55 pm, Rainer Joswig <······@lisp.de> wrote:
>
> >> http://lispm.dyndns.org/documentation/norvig-lisp-style.pdf
>
> > One of the recommendations in here that surprised me was to avoid use
> > of AND and OR for non-booleans, e.g.
>
> And by the way, AND and OR are not boolean functions. They are operators
> designed for evaluation control, which are dressed up to look like boolean
> functions.
Well, yes. I think that's exactly where the disagreement arises :)
> Norvig's recommendation boils down to ``I disagree with the design and purpose
> of some basic Common Lisp functions, and so should you''.
>
> What a crock.
Well, we're all free to have our own opinions about various elements
of the CL spec. I, for instance, am a LOOP-hater.
Anyway, Kent is listed as a co-author. Kent, are you listening? Care
to comment?
-- Scott
In article
<····································@z6g2000pre.googlegroups.com>,
Scott Burson <········@gmail.com> wrote:
> On Sep 18, 11:55 pm, Rainer Joswig <······@lisp.de> wrote:
>
> > http://lispm.dyndns.org/documentation/norvig-lisp-style.pdf
>
> One of the recommendations in here that surprised me was to avoid use
> of AND and OR for non-booleans, e.g.
>
> (or (try-to-find-a-usable-frob)
> (make-instance 'frob ...))
>
> (and (check-precondition)
> (compute-some-non-boolean-result))
>
> I do this kind of thing all the time. I seem to recall this idiom
> being very common in the Lisp Machine system code, which is where I
> picked up a lot of my Lisp style. I'm curious what others think about
> this (not that I'm likely to change my practice :)
>
> The AND idiom is perhaps the less important because it's easy to
> rewrite:
>
> (and form0 form1 ... formN)
> -> (if (and form0 form1 ...) formN nil)
I usually write (when (and . . .) (some-thing))
>
> but OR is harder because, in general, you have to bind a variable for
> each non-final subform:
>
> (or form0 . forms)
I find OR useful and readable.
> -> (let ((tmp0 form0)) (if tmp0 tmp0 (or . forms)))
>
> Anyway, WDYT?
>
> -- Scott
--
http://lispm.dyndns.org/
On Sep 23, 1:15 pm, Rainer Joswig <······@lisp.de> wrote:
> I usually write (when (and . . .) (some-thing))
Interesting. I tend to avoid using WHEN and UNLESS for value. Not
sure if I'm absolute about that, though.
-- Scott
AlFire wrote:
> Hello all,
>
> i have got a short question. After programming and designing for over 20
> years and climbing up on following ladder
> Basic->6502->Logo->Pascal->C->Fortran->C++->Python I realized I am in a
> need of a language that let me stronger express my thinking. I am
> somewhat familiar with the Lisp as I use Emacs almost exclusively but
> really lacking some fundamentals.
>
> So what would be a next step I need to make. What strategy would you
> recommend to adopt in order to make the biggest strides in the shortest
> time and avoid the most common misconceptions as well as pitfalls.
>
> Looking forward for a good stuff,
>
> Andy
*If* you are like me, you will find that "reading" (or worse,
"studying") books like PCL, OnLisp & SICP gets to be boring
pretty soon. Especially when you are a beginner. It will
slow you down, talking about things you don't care about or
distracting you with mysterious and wonderful things.
Instead, just write lots of code to explore something you
care about and *refer* to these books as needed (+ the spec).
Then rewrite it, play with it, trim some fat, until it looks
more "beautiful" or at least less ugly. For style, idioms
etc., look at code written by seasoned programmers. This way
your working vocabulary will get large pretty fast.
But if you are like a friend of mine, you *will* want to
study the books various people recommended. This friend
takes up a brand new subject and ends up knowing about it in
incredible depth, including history, evolution, branches not
taken and all sorts of minutiae. Very impressive but also
very annoying. Me, I just want to learn enough to get
something done, or as soon as I learn something I want to
try it out.
In article <················@bitblocks.com>,
Bakul Shah <············@bitblocks.com> wrote:
> AlFire wrote:
> > Hello all,
> >
> > i have got a short question. After programming and designing for over 20
> > years and climbing up on following ladder
> > Basic->6502->Logo->Pascal->C->Fortran->C++->Python I realized I am in a
> > need of a language that let me stronger express my thinking. I am
> > somewhat familiar with the Lisp as I use Emacs almost exclusively but
> > really lacking some fundamentals.
> >
> > So what would be a next step I need to make. What strategy would you
> > recommend to adopt in order to make the biggest strides in the shortest
> > time and avoid the most common misconceptions as well as pitfalls.
> >
> > Looking forward for a good stuff,
> >
> > Andy
>
> *If* you are like me, you will find that "reading" (or worse,
> "studying") books like PCL, OnLisp & SICP gets to be boring
> pretty soon. Especially when you are a beginner. It will
> slow you down, talking about things you don't care about or
> distracting you with mysterious and wonderful things.
> Instead, just write lots of code to explore something you
> care about and *refer* to these books as needed (+ the spec).
> Then rewrite it, play with it, trim some fat, until it looks
> more "beautiful" or at least less ugly. For style, idioms
> etc., look at code written by seasoned programmers. This way
> your working vocabulary will get large pretty fast.
>
> But if you are like a friend of mine, you *will* want to
> study the books various people recommended. This friend
> takes up a brand new subject and ends up knowing about it in
> incredible depth, including history, evolution, branches not
> taken and all sorts of minutiae. Very impressive but also
> very annoying. Me, I just want to learn enough to get
> something done, or as soon as I learn something I want to
> try it out.
Norvig's PAIP is very good at explaining the process
of improving some non-trivial software. You get
a piece of code that is longer and a few lines, the
book describes it how it is developed. Then you
can experiment with it. For example it has a chapter
on playing Othello with various strategies. One
can implement new strategies. I wrote years ago
when I bought that book a GUI for the code and tried
to see how to best reuse his code without changing
the implementation (much).
There is also 'COMMON LISP: An Interactive Approach'
by Stuart C. Shapiro:
http://www.cse.buffalo.edu/~shapiro/Commonlisp/
(available as PDF)
The 'interactive approach' is very important when
reading Lisp books. One can try out the various
things using the Lisp listener (REPL) - piece by piece.
Some people like to learn by trying out things. The
interactive nature of most Lisp implementations makes
it possible that you can work through a book and
at the same time use the code on the computer...
--
http://lispm.dyndns.org/
P� Fri, 19 Sep 2008 20:44:58 +0200, skrev Bakul Shah
<············@bitblocks.com>:
>
> *If* you are like me, you will find that "reading" (or worse,
> "studying") books like PCL, OnLisp & SICP gets to be boring
> pretty soon. Especially when you are a beginner. It will
> slow you down, talking about things you don't care about or
> distracting you with mysterious and wonderful things.
> Instead, just write lots of code to explore something you
> care about and *refer* to these books as needed (+ the spec).
> Then rewrite it, play with it, trim some fat, until it looks
> more "beautiful" or at least less ugly. For style, idioms
> etc., look at code written by seasoned programmers. This way
> your working vocabulary will get large pretty fast.
>
> But if you are like a friend of mine, you *will* want to
> study the books various people recommended. This friend
> takes up a brand new subject and ends up knowing about it in
> incredible depth, including history, evolution, branches not
> taken and all sorts of minutiae. Very impressive but also
> very annoying. Me, I just want to learn enough to get
> something done, or as soon as I learn something I want to
> try it out.
Depends how patient you are. When I was younger I had to know everything
yesterday. Lengthy reading sessions board me. Now at 40 and then some I
find I have more patients and find the time to study works like Knuth
TAOCP which would have driven me up the wall earlier. Truth is I already
have a fairly broad knowledge and a fair idea how things work. Thus I
finally find the time to dot the i's and explore the subjects in more
depth.
Getting good at anything takes time. Have fun and explore. Then later if
you feel like it fill in the details.
--------------
John Thingstad
Andy,
I'm learning lisp because it looks like it may be the queen of
programming languages (in the sense of Gauss' assertion that number
theory is the queen of mathematics). I'm learning it in my spare time;
it is unlikely I will have the opportunity to use it at work in the
near future. My programming background is about half as deep as yours
and about a quarter as broad. I've read the following lisp texts, many
of which are freely available on the web (listed in order of
decreasing coolness):
1. Hal Abelson, Jerry Sussman and Julie Sussman, "Structure and
Interpretation of Computer Programs"
2. Peter Norvig, "Paradigms of Artificial Intelligence Programming:
Case Studies in Common Lisp"
3. Paul Graham, "On Lisp"
4. Peter Seibel, "Practical Common Lisp"
5. David S. Touretzky, "Common Lisp: A Gentle Introduction to Symbolic
Computation"
6. Paul Graham, "Hackers and Painters"
7. Paul Graham, "ANSI Common Lisp"
However, immersion is the fastest way to learn a language.
Unfortunately, nothing has yet jumped out at me as a suitable lisp
project. Recently though, as a baby step, I've coded a lisp
interpreter in C based on the paper, "The Roots of Lisp" by Graham. I
found this to be a rather fun lisp-ish project.
Adam
······@ieee.org wrote:
> Andy,
>
> I'm learning lisp because it looks like it may be the queen of
> programming languages (in the sense of Gauss' assertion that number
> theory is the queen of mathematics). I'm learning it in my spare time;
> it is unlikely I will have the opportunity to use it at work in the
> near future. My programming background is about half as deep as yours
> and about a quarter as broad. I've read the following lisp texts, many
> of which are freely available on the web (listed in order of
> decreasing coolness):
>
> 1. Hal Abelson, Jerry Sussman and Julie Sussman, "Structure and
> Interpretation of Computer Programs"
> 2. Peter Norvig, "Paradigms of Artificial Intelligence Programming:
> Case Studies in Common Lisp"
> 3. Paul Graham, "On Lisp"
> 4. Peter Seibel, "Practical Common Lisp"
> 5. David S. Touretzky, "Common Lisp: A Gentle Introduction to Symbolic
> Computation"
> 6. Paul Graham, "Hackers and Painters"
> 7. Paul Graham, "ANSI Common Lisp"
Whoa. Can you say "paralysis"? Sher ya can. I have never read more than
thirty pages on a new language before starting to program in it.
>
> However, immersion is the fastest way to learn a language.
> Unfortunately, nothing has yet jumped out at me as a suitable lisp
> project.
Lisp is the anenome of languages, paralyzing anyone who gets close
enough. It is also the perfect language for people who have no ideas --
they can hobby away furiously and get PhDs and publish papers and go to
conferences and never define one application class or function.
> Recently though, as a baby step, I've coded a lisp
> interpreter in C based on the paper, "The Roots of Lisp" by Graham. I
> found this to be a rather fun lisp-ish project.
Ah, the Patrick Collison (sp?) School of Devotion to Lisp: Lisp rocks!
Let's program in C all day long!
TISLHFYP,
k
P� Sat, 20 Sep 2008 04:39:03 +0200, skrev <······@ieee.org>:
>
> However, immersion is the fastest way to learn a language.
> Unfortunately, nothing has yet jumped out at me as a suitable lisp
> project. Recently though, as a baby step, I've coded a lisp
> interpreter in C based on the paper, "The Roots of Lisp" by Graham. I
> found this to be a rather fun lisp-ish project.
>
I think you got that backwards. Write a C interprenter in Lisp.. (so you
can say "C is just too slow"..)
Unless you really desire learning C. :)
--------------
John Thingstad