New book(s) about Lisp
Edi Weitz
<http://www.bookfix.com/1163.html>
<http://www.bookfix.com/theory/>
I don't know how serious they are (obviously not a very large
publisher) but it looks like they plan to release "Successful Lisp"
this autumn.
Add to this the reprint of "On Lisp"
<http://lemonodor.com/archives/000386.html>
and Peter Seibel's announcement
<http://www.google.com/groups?selm=m3u1c8d14u.fsf%40javamonkey.com>
plus the "BookWare" section in Franz' online store and you'll end up
with at least three CL books in the next months. I think the last one
was six years ago (Slade, 1997) - most of the other CL books which can
be found at Amazon are much older.
If you're looking for evidence that Lisp is not dead this might be
one... :)
Edi.
Lars Brinkhoff
> I think the last [Common Lisp book] was six years ago (Slade, 1997)
There's "Advanced LISP Technology" from 2002 (ISBN 0415298199).
Edi Weitz
Yep, I didn't know about that one. However, from the short description
at Amazon this sounds more like a compilation of research papers about
"Lisp" in the sense of "CL, Scheme, and related languages". Do you
know the book?
I was talking about Common Lisp books specifically - I think the
market for these has been rather quite in the last years.
Edi.
Will Hartung
"Daniel Barlow" <d...@telent.net> wrote in message
news:87n0gzd...@noetbook.telent.net...
> Edi Weitz <e...@agharta.de> writes:
> > plus the "BookWare" section in Franz' online store and you'll end up
> > with at least three CL books in the next months. I think the last one
> > was six years ago (Slade, 1997) - most of the other CL books which can
> > be found at Amazon are much older.
> This information is not for public dissemination yet, but there's a
> reasonable chance you can add a fourth to that. Working title "Lisp
> for Perl Programmers", or something like. I'm in discussions with
> Prentice Hall.
Ideally, any book is better than no book, but I'll be interested to see how
these advance the art for a static technology. If nothing else, at least
they end up on bookshelves (I haven't seen a Lisp book on the shelves for a
long time, and I tend to buy most every one I see).
"Lisp for Perl Programmers" will hopefully be interesting, particularly if
it focuses on "programming in the small" doing "mundane" things, kind of
like the original Perl 4 Camel book. That was a great book, IMHO. I can
safely say that when the Perl 5 behemoth book came out several years later,
I completely gave up on Perl. I simply didn't want to know that much about
it.
I would like to see a book that doesn't even necessarily cover the entire
scope of the language, yet applies what it does cover over a wide array of
tasks. And hopefully, none of those tasks will be AI or any other "advanced"
topic.
I always enjoyed "Simply Scheme" which immediately defined its own
vocabulary and focused on teaching the language without going into intricate
details. It essentially uses a Logo-esque dialect and pushes on from there.
R4RS? Huh? Continuwhats? Amazingly you don't need to know these things to
learn Scheme.
"System Administration using CLisp", "Web Programming and CMUCL", "CLIM, the
Mouse, and You: a Programmers Guide".
Include a bunch of little utilities or programs, basically don't just give
them the empty toolbox of ANSI CL, but fill it with some high level usable
bits.
Cover complicated topics lightly enough to satisfy the 90%. Teach more
people "bad Lisp". Java in Lisp, Perl in Lisp, C in Lisp, whatever.
Why? Because ideally you'll end up with people using the system and getting
interested enough to find out the details. There are a LOT of people writing
Very Bad Java/C/C++/Perl, etc, and it doesn't seem to be hurting those
languages.
Skip the LOOP vs DO debate, just use one and ignore the other. Push "IF*" if
you want. Don't tell them about destructive functions. Hell, don't even
write a chapter on CAR, CDR, CADR, whatever. Use FIRST, REST, etc. Glance
over DEFSTRUCT and hit CLOS head on. Use VI as the editor.
Write some macros, document the macros, use the macros in your code, and
don't even give a chapter on Macros. Just stick them in your library and
explain them like you would LOOP.
Present the bits that are applicable to the focus of the book. Put the stuff
you don't cover in an appendix, perhaps.
But don't "get distracted" by the whole thing, the entire standard. We have
several books on "all of Lisp". The book "Object Oriented Programming in
Common Lisp" didn't spend a whole lot of time on CLOS, IMHO. It presented
massive permutations of the different Lisp forms, but didn't go in as deeply
into "OO Lisp" as the title would suggest. I think a more focused book would
have been better.
Let's get some books for the "blue collar" coders and users. Things that
they can use fairly immediately and to good use by Chapter 2.
"Lisp in the trenches -- Trump that deadline using Corman CL and COM"
"Black Ops: Scripting with Lisp"
"Exploring Mac OS X with MCL"
Regards,
Will Hartung
(wi...@msoft.com)
Lars Brinkhoff
> Lars Brinkhoff <lars...@nocrew.org> writes:
> > Edi Weitz <e...@agharta.de> writes:
> > > I think the last [Common Lisp book] was six years ago (Slade, 1997)
> > There's "Advanced LISP Technology" from 2002 (ISBN 0415298199).
> Yep, I didn't know about that one. However, from the short description
> at Amazon this sounds more like a compilation of research papers about
> "Lisp" in the sense of "CL, Scheme, and related languages".
Yes, that's true.
> Do you know the book?
No. Is there anyone else that does?
Thaddeus L Olczyk
wrote:
>"Lisp in the trenches -- Trump that deadline using Corman CL and COM"
Considering that I tried to do COM programming with Corman last year
and failed miserably, I would like to see this.
--------------------------------------------------
Thaddeus L. Olczyk, PhD
Think twice, code once.
Chris Double
> >"Lisp in the trenches -- Trump that deadline using Corman CL and COM"
> Considering that I tried to do COM programming with Corman last year
> and failed miserably, I would like to see this.
I developed some code to produce Corman Lisp wrappers from type
libraries. They are available at:
You may have tried this already, the code it generates is not high
level as you still need to use the FFI to allocate c-memory for some
of the wrapped calls. It was good enough though to allow displaying of
ActiveX controls from Lisp without too much hassle. See the
WildTangent example that is at the site too.
Chris.
--
http://radio.weblogs.com/0102385
c hore
> If you're looking for evidence that Lisp is not dead
> this might be one...
Instead of "not dead", I understand that the generally
accepted and allowed phrase (GAAP), based on the page
of Lisp quotes, is: "not deader than usual".
Kenny Tilton
How about "less and less dead every day"? I should go trademark "Phoenix
Common Lisp" now. Or "Nixon Common Lisp"... sh*t, I like it! :(
Better yet, I hear tell there was this company getting nowhere with an
electric grill, until they signed a forty-year old boxer to a branding
deal: "George Foreman Common Lisp"?
I scare myself.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
Bruce Nagel
> How about "less and less dead every day"? I should go trademark "Phoenix
> Common Lisp" now. Or "Nixon Common Lisp"... sh*t, I like it! :(
impediment jokes...
(Losthalo)
(lost...@innocent.com)
(www.not-art.org)
Kenny Tilton
Bruce Nagel wrote:
> On Fri, 06 Jun 2003 13:52:04 GMT, Kenny Tilton <kti...@nyc.rr.com> wrote:
>
>
>>How about "less and less dead every day"? I should go trademark "Phoenix
>>Common Lisp" now. Or "Nixon Common Lisp"... sh*t, I like it! :(
>
>
> Actually, follow Graham's lead: name it Phoenix,...
I considered that, but decided the point was to poke fun at everyone who
had once declared Lisp dead. Lazarus Common Lisp? Clemens Common Lisp?
No, they'll think Roger... btw, what /is/ happening with Arc?
> skip the old speech-
> impediment jokes...
God yes. But I have perfected a stone face response to anyone making
that mistake with me. We all need early warning systems for "they might
have heard this a million times before" remarks. I once destroyed any
nano-chance I had with a stunning, taller woman by asking her how tall
she was.
"Six foot two," she replied. "How short are you?"
Doh!
Nikodemus Siivola
> skip the old speech-impediment jokes...
Never heard one. This is the part where non-english speakers get to look
smug. ,)=
Cheers,
-- Nikodemus
Kenny Tilton
Nikodemus Siivola wrote:
> Bruce Nagel <lost...@nerg.net> wrote:
>
>
>>skip the old speech-impediment jokes...
>
>
> Never heard one. This is the part where non-english speakers get to look
> smug. ,)=
Eureka! I'm moving to China.
Calling all Lisp historians: does anyone remember anything at all about
the selection of the name LISP?
Were there any misgivings about the silliness? Of course silly and nerdy
and technogeek are synonyms, so it probably was more like "Perfect!".
Was it a throwaway, ie, just a temp working name, or maybe they thought
it was a temp language research project, as in "it's not like were going
to be living with this name for the next fifty or sixty years". <doh!>
Were any alternatives considered?
And here is one for any Lispnik: imagine you are back in the fifties and
you are looking for a name for a language summarized in:
http://green.iis.nsk.su/~vp/doc/lisp1.5/node1.html
Here are the highlights I picked out:
"The LISP language is designed primarily for symbolic data processing..
"LISP is a formal mathematical language...
"In the LISP language, all data are in the form of symbolic expressions...
"LISP can interpret and execute programs written in the form of
S-expressions..."
Yikes, no mention of LISt Processing.
How about "Sexy"?
Pascal Bourguignon
> And here is one for any Lispnik: imagine you are back in the fifties
> and you are looking for a name for a language summarized in:
>
> http://green.iis.nsk.su/~vp/doc/lisp1.5/node1.html
>
> Here are the highlights I picked out:
>
> "The LISP language is designed primarily for symbolic data processing..
Symbolic data Processing
> "LISP is a formal mathematical language...
Integers are dealt in maths.
> "In the LISP language, all data are in the form of symbolic expressions...
>
> "LISP can interpret and execute programs written in the form of
> S-expressions..."
Which are represented as Lists.
> Yikes, no mention of LISt Processing.
So, Lists, Integers, Symbols, Processing. LISP.
> How about "Sexy"?
Symbols, Events, Xylophones, Yacking ?
--
__Pascal_Bourguignon__ http://www.informatimago.com/
----------------------------------------------------------------------
Do not adjust your mind, there is a fault in reality.
Nicholas Geovanis
> Better yet, I hear tell there was this company getting nowhere with an
> electric grill, until they signed a forty-year old boxer to a branding
> deal: "George Foreman Common Lisp"?
Computer Associates is back in the software tools market?
I worked for them when they did the last George Foreman ad campaign.
For _years_ afterwards they dragged-around a boxing ring to all the
trade shows, complete with dancing-girls in red-white-blue halter-tops
and boxing trunks, a referee, starting bell....
> kenny tilton
* Nick Geovanis
| IT Computing Svcs
| Northwestern Univ
| n-geo...@nwu.edu
+------------------->
Donald Fisk
> Yikes, no mention of LISt Processing.
>
> How about "Sexy"?
There nearly was a language called SEXI (short for String
EXpression Interpreter), but its developers chickened out
and decided to call it SNOBOL instead.
> kenny tilton
--
:ugah179 (home page: http://web.onetel.com/~hibou/)
"I'm outta here. Python people are much nicer."
-- Erik Naggum (out of context)
Gordon Weakliem
> I would like to see a book that doesn't even necessarily cover the entire
> scope of the language, yet applies what it does cover over a wide array of
> tasks. And hopefully, none of those tasks will be AI or any other "advanced"
> topic.
> Let's get some books for the "blue collar" coders and users. Things that
> they can use fairly immediately and to good use by Chapter 2.
This is an awesome idea, though I'd suggest using the "cookbook" model
(e.g. The Perl Cookbook, The Python Cookbook, The Ruby Way). For those
not familar, each chapter's devoted to a subset of tasks, for example
"file I/O", which then has items like "scan all lines in a file",
"implement a simple grep", "modify a file in place". A good cookbook
discusses the alternatives and tradeoffs with each approach.
Henrik Motakef
> This is an awesome idea, though I'd suggest using the "cookbook" model
> (e.g. The Perl Cookbook, The Python Cookbook, The Ruby Way).
... or even the Common Lisp cookbook: http://cl-cookbook.sf.net