lisp "philosophy" ?
Martin J. Brown, Jr.
from the web, some better than others. What I'm not getting from them is a
lisp "philosophy" (??), a description of how to look at a problem through lisp
colored glasses...
so lisp is list processing, so what?
How do I look at some problem as a list? If that's how to do it.
If I can understand lisp, "grok" it, then the rest is just syntax and functions.
I hope I'm explaining myself, what I'm looking for.
If you have a pointer to some online material that explains the lisp
"philosophy", I'd appreciate it if you would pass it on to me.
I'm not looking for a treatise, just something short, a couple of paragraphs or
a page.
Thank you for any suggestions you may have.
- Martin -
Erik Naggum
| I've just started working with lisp. I've downloaded a number of tutorials
| from the web, some better than others. What I'm not getting from them is a
| lisp "philosophy" (??), a description of how to look at a problem through lisp
| colored glasses...
If you look too hard, you will never see it.
| so lisp is list processing, so what?
No, Lisp is not list processing.
| How do I look at some problem as a list? If that's how to do it.
No, that is not how to do it.
| If I can understand lisp, "grok" it, then the rest is just syntax and
| functions.
No, this is not so.
| I hope I'm explaining myself, what I'm looking for.
No, but I understand what you might be satisfied with.
| If you have a pointer to some online material that explains the lisp
| "philosophy", I'd appreciate it if you would pass it on to me.
The collected writings of Common Lisp people will give you one
philosophy, and the collected writing of Scheme freaks will give you
quite another philosophy.
| I'm not looking for a treatise, just something short, a couple of
| paragraphs or a page.
No can do.
| Thank you for any suggestions you may have.
Pay for a real book. It is very unlikely that you will be able to pick
up what you want from on-line resources. They all sort of assume that
you have already grasped what you seek in a sort of abstract way, even
the tutorials (which I think are all seriously deficient).
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
Kent M Pitman
> I've just started working with lisp. I've downloaded a number of
> tutorials from the web, some better than others. What I'm not
> getting from them is a lisp "philosophy" (??), a description of how
> to look at a problem through lisp colored glasses...
This is a reasonable question.
> so lisp is list processing, so what?
This is not surprising question, though it turns out your premise is
what's bad here.
Actually, it isn't [just] list processing. It started out that way.
It is now a great many things.
It is about symbols, not just lists.
It is about deferring decision making until a time appropriate to make
decisions, often not binding yourself to a type decision at compile time.
For example, in lisp a "variable" is not typed. It can hold any data
unless you go to special trouble to say it should not do so, and even then
that is only "advice" to the compiler, it's not an imperative. Type
information is in the datum, not in the variable. This has important
implications on how method dispatch works. C++ does all its dispatch
decisions too early, based on the declared type, and this causes some
conceptually wrong behaviors in practice.. Java does a thing that's kind
of halfway between Lisp and C++, with the foo.bar() dispatch being done
on dynamic information about foo, but with the arguments to the .bar(...)
being done on the basis of static information--that's not right either.
There are a great many other things. Go to the Association of Lisp Users
web page at www.alu.org and start looking around at some of the resources
there. There are some good tutorials and references to books and other
materials that you will find helpful.
> How do I look at some problem as a list? If that's how to do it.
No, a list is just a datastructure that should be part of your standard
arsenal of data structures taught you to you in any algorithms or data
structures course in school. Lists are good for sequential access and
for sharing subtails of information (both for space efficiency and for
semantic correlation that can occur due to sharing). Arrays are good,
by contrast, for random access. A lot of other factors play in. But
the point is that lisp was created in 1958 or so and back then it was the
only thing going with lists in it. FORTRAN, for example, which was born
at the same time had no such datatype. Nowadays, lisp has both arrays and
lists and strings (a kind of 1-d array, actually, in lisp) and hash tables
and user-defined types ... you use each when it is appropriate.
It happens to be that Lisp represents its own programs a lists, but
that's just an arbitrary decision that makes various things easy. It doesn't
mean you have to represent your own data for other things using lists unless
you feel that's the best structure.
> If I can understand lisp, "grok" it, then the rest is just syntax
> and functions.
Well, there's very little syntax. And even the list stuff is just functions.
I've seen people taught lisp and never told about lists and they can still
program fine. It's a little bizarre, since most lispers do know about lists,
but my point is that they are not a necessary thing to use--they're just
sometimes handy and you might as well know about them because they add power
to what you can do.
> I hope I'm explaining myself, what I'm looking for.
Yes, though you are looking at it from the wrong angle and I hope my post
here and those of others you'll surely get will help you get straightened
out. I'm glad you're interested, but you want to apply that interest on
worrying about the right issues so it's not wasted.
> If you have a pointer to some online material that explains the lisp
> "philosophy", I'd appreciate it if you would pass it on to me.
Start at the ALU web site.
> I'm not looking for a treatise, just something short, a couple of
> paragraphs or a page.
>
> Thank you for any suggestions you may have.
Make sure you check out the Common Lisp HyperSpec, btw.
http://www.xanalys.com/software_tools/reference/HyperSpec/Front/
You can even download your own copy from
http://www.xanalys.com/software_tools/reference/HyperSpec/
if you get tired of using it remotely. It is a hypertextified derivative
of ANSI CL, which defines the language, and will be an important reference.
It is _not_ intended as a tutorial, but it does contain at least some stuff
you'll need, and you may find a great deal of it to be more approachable
than many other language standards ...
Good luck.
Kenny Tilton
"Martin J. Brown, Jr." wrote:
> so lisp is list processing, so what?
you will be surprised how handy is that little data structure if you
give it a chance.
otoh, Lisp also has the best OO implementation of any language, so it
ain't /just/ list processing.
>
> How do I look at some problem as a list? If that's how to do it.
>
> If I can understand lisp, "grok" it, then the rest is just syntax and functions.
grok meta-programming (macros, functions as first-class objects).
> I'm not looking for a treatise, just something short, a couple of paragraphs or
> a page.
ah, the elevator pitch! I think the preface and chapter one of Paul
Graham's "On Lisp" will draw you in enough that you will keep reading.
It's on-line, but you may be too lazy to Google that up (and if so I
sure as hell am too lazy to do it for you).
:)
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
"Well, I've wrestled with reality for thirty-five years, Doctor, and
I'm happy to state I finally won out over it." Elwood P. Dowd
Software Scavenger
> lisp "philosophy" (??), a description of how to look at a problem through lisp
> colored glasses...
Here is what Common Lisp is best at: A good Common Lisp programmer
can develop and maintain sophisticated software faster and better than
a typical team of 100 programmers using a typical programming
language. Common Lisp doesn't get in your way. Most programming
languages and development environments impose obstacles causing you to
work much more slowly and erratically than you should be able to.
(This assumes you're an expert programmer. Otherwise lack of
programming skill would be getting in your way most.)
List processing is a red herring. Common Lisp has an extensive set of
datatypes, much better than in most other programming langauges, and
lists are just one of those. The name "Lisp" has been around for
decades, and the language has evolved since then, like monkeys
evolving into humans. But it's not easy to learn Common Lisp well
enough to be really good at it. The tradeoff is between learning and
productivity. You basically invest a lot into learning and reap big
rewards in productivity. But it's an investment most programmers
wouldn't make. Productivity is not their highest priority.
A typical team of 100 programmers, with various levels of management
as part of the team, would not want Common Lisp. Each manager wants
to manage as many programmers as possible, and to easily understand
what those programmers are doing. If the whole project can be done by
one programmer, the whole social fabric of the team unravels. And if
the managers have to invest serious effort into just learning the
programming language, they're not going to be happy about it. For
those reasons, Common Lisp is best used by one programmer working
alone, doing the work of 100.
To grok Common Lisp is to grok programming. If you're a really good
programmer, you can learn Common Lisp much faster than if you aren't.
You have to understand what most programmers do wrong, to understand
how Common Lisp can help them do things right. To start explaining
the Common Lisp paradigm, how to look at the world through CL-colored
glasses, we would have to start by explaining what most programmers do
wrong. But that's an education in itself, way beyond the scope of
this kind of discussion.
The best way to proceed is to start using Common Lisp for developing
sophisticated software. As a beginner you will make lots of mistakes,
so you should be prepared to redo big parts of your work as you learn.
As a general rule the more you program the more expertise you gain.
Keep the Hyperspec handy, read some other books as time permits, but
focus mostly on doing as much real development work as possible.
Coby Beck
"Software Scavenger" <cubic...@mailandnews.com> wrote in message
news:a6789134.02031...@posting.google.com...
> Here is what Common Lisp is best at: A good Common Lisp programmer
> can develop and maintain sophisticated software faster and better than
> a typical team of 100 programmers using a typical programming
> language.
While I am as big a fan of Common Lisp as the next guy here this kind of
hyperbole presented as fact is not a good thing. Common Lisp is an
excellent tool and I believe it can facilitate production of complicated
code at a much faster rate than the mainstream languages. While I wouldn't
personally try to put a number to something like that, if I did it would be
in the single digits.
Posting something like the above "one Lisper can do the work of 100 typical
language programmers" just looks like fanaticism and from a public relations
POV is not helpful.
--
Coby Beck
(remove #\Space "coby 101 @ bigpond . com")
Paolo Amoroso
Jr.) wrote:
> I've just started working with lisp. I've downloaded a number of tutorials
> from the web, some better than others. What I'm not getting from them is a
> lisp "philosophy" (??), a description of how to look at a problem through lisp
> colored glasses...
I can just tell you what I did. Even when I did not know the language well,
the most important decision for me was to invest my energies into learning
it, because I liked what I saw, understood, and grasped. Then I eventually,
naturally started looking at problems through Lisp's colored glasses. I
haven't stopped learning, and each day a shade of color appears on those
glasses. That rainbow is beautiful.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
P.C.
"Coby Beck" <cb...@mercury.bc.ca> skrev i en meddelelse
news:tz6l8.160247$kb.87...@news1.calgary.shaw.ca...
>
> Posting something like the above "one Lisper can do the work of 100 typical
> language programmers" just looks like fanaticism and from a public relations
> POV is not helpful.
Now we can't even tell truth anymore ;))
I read somwhere, that with a list structure and a Lisp evaluator, you can search
a big list ,very much faster, than with other programming means, and that this
shuld be the real pover of Lisp, that score low used with another concept.
That dividing A with B is acturly also faster done in Lisp to, but not 22
divided with 7.
even A is set to 22 and B 7.
Guess that's not true, and that the real pover come in recursive programming.
P.C.
http://d1o111.dk.telia.net/~u139600113/a
Rahul Jain
> Guess that's not true, and that the real pover come in recursive programming.
The real power, IMO, comes from what McCarthy originally designed lisp
for. Not just recursive functions, but symbolic computation. This
allows us to define our own syntax for operations we use commonly, and
to create unique identifiers to be used for adding
application-specific information to another application's data (of
course, the other application would have needed to set up a place in
which other application would store that data).
I don't know if it was genius or accident, but McCarthy really
discovered something great in 1960. Maybe the MacLisp community was
the strongest of the two major Lisp communities because they were the
ones who were interested in McCarthy's original goal, symbolic
processing of mathematical expressions, as opposed to the Interlisp
community which was more interested in user interface issues, IIUC.
--
-> -/ - Rahul Jain - \- <-
-> -\ http://linux.rice.edu/~rahul -=- mailto:rj...@techie.com /- <-
-> -/ "Structure is nothing if it is all you got. Skeletons spook \- <-
-> -\ people if [they] try to walk around on their own. I really /- <-
-> -/ wonder why XML does not." -- Erik Naggum, comp.lang.lisp \- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
(c)1996-2002, All rights reserved. Disclaimer available upon request.
Kenny Tilton
Coby Beck wrote:
> Posting something like the above "one Lisper can do the work of 100 typical
> language programmers" just looks like fanaticism and from a public relations
> POV is not helpful.
But there are two factors in there. Lisp itself is one order of
magnitude better, and a Lisper over a "typical language programmer" is
another. And we are cheating a litle; if we are talking about a single
project, the last ninety programmers on a hundred-programmer project add
nothing.
Frank A. Adrian
> I've just started working with lisp. I've downloaded a number of
> tutorials
> from the web, some better than others. What I'm not getting from them is
> a lisp "philosophy" (??), a description of how to look at a problem
> through lisp colored glasses...
Look at the first few chapters of Norvig's Paradigms of AI Programming. He
touches on subjects that are not all that AI'ish today, but gives a good
flavor of how to solve programs in a "Lispish" way. After reading the
first few chapters, read the next few. In fact, read the whole book. It's
a good into to Lisp programming...
faa
Alain Picard
> Posting something like the above "one Lisper can do the work of 100 typical
> language programmers" just looks like fanaticism and from a public relations
> POV is not helpful.
Indeed. "Pousse, mais pousse égal". :-)
I _did_ work on an 18 month, 30 man project (in C++) which
I now think could have been done by 3 lispers and 1 C guy
in 12 months or so. So, maybe not 100 to 1, but definitely a plus.
But then again, all 4 individuals would have to be of very
high caliber; indeed, perhaps firing the 26 lamest programmers
in the original project would have been the optimal strategy.
Projects on large teams seem doomed almost from the start, and
are certainly no fun to work on, so I now look at ways to accomplish
the same tasks with smaller teams (e.g. Lisp, XP, whatever else).
Irrelevant tangent:
How in the _world_ do *really* *large* systems (airline reservation,
IRS, etc) ever get constructed? Anybody been involved in a
1000+ manyear (successful) project want to tell the tale?
--
It would be difficult to construe Larry Wall, in article
this as a feature. <1995May29....@netlabs.com>
Software Scavenger
> Posting something like the above "one Lisper can do the work of 100 typical
I didn't mean 100 times as much work. I meant it's better for one
programmer to do a big project alone, and that's where Common Lisp
would excel. A team of 100 programmers works very inefficiently.
I don't think this is hyperbole. I have experience working with that
many programmers. It's clear to me that it's a tremendous waste of
resources, and that one Common Lisp programmer working alone would be
able to work orders of magnitude more efficiently. I think this is a
conservative estimate, and that in reality the Common Lisp programmer
is likely to do a vastly better job in far less time. (That could
more reasonably be construed as hyperbole, but it's only to counter
the argument that the original 100 to 1 equivalence seemed to be.)
Erik Naggum
> Here is what Common Lisp is best at: A good Common Lisp programmer
> can develop and maintain sophisticated software faster and better than
> a typical team of 100 programmers using a typical programming
> language.
* "Coby Beck"
| Posting something like the above "one Lisper can do the work of 100
| typical language programmers" just looks like fanaticism and from a
| public relations POV is not helpful.
You may read it that way, but he actually qualified both the (Common)
Lisp programmer and the team of programmers and the language in a way
that makes the meaning quite different from your interpretation.
Thaddeus L Olczyk
wrote:
>I read somwhere, that with a list structure and a Lisp evaluator, you can search
>a big list ,very much faster, than with other programming means, and that this
>shuld be the real pover of Lisp, that score low used with another concept.
>That dividing A with B is acturly also faster done in Lisp to, but not 22
>divided with 7.
Nope. It is concievable that for a generic case with a predicate that
is general this might be the case, but for the case when the list is
sorted and the predicate is compatible with the sort, a binary search
would take O(nlogn) a simple scan ... first then second then third
could be used but then you have to take O(n).
A far cry from a different language with an array type searching a
sorted array, where it takes O(logn).
Damond Walker
> I've just started working with lisp.
[..snip..]
Lisp Philosophy? Lisp is what you want it to be -- pure and simple.
There are certain idioms that people follow but once you get to that
point Lisp becomes your own.
Damond
P.C.
"Damond Walker" <dwa...@syncreticsoft.com> skrev i en meddelelse
> There are certain idioms that people follow but once you get to that
> point Lisp becomes your own.
You are quite right, but you also get these idears about everything shuld be,
when you seen the concept in Lisp ; Now I hope you accept, that even I startet
with a 8088 and experienced Lisp with AutoCAD 2.6, I somtimes have fantasies
about just having a blank screen with a "hello". ----- then being able to
compose a button from a few standard functions I know is avaible on any system,
like when you program buttons for boring tasks or define functions in Lisp
manner, ------- that with a small number of standard functions, you can create
a button on the fly, that combine a standard word processor with an internet
protocol. Or create a button that will ofer just the tool you need here and
now, from a blank screen .
Sorry if I don't express this better, my english is not very good, ----- but
from my point of view, this would be the best way to use a Lisp syntax ; not
handeling things within other applications, but working with a system that work
simple aswell as advanced, all depending how many standard functions you know
and your ability to make new functions and place them as tool buttons on your
own workspace.
But this is a totally different concept, than the one where you try adabting
Lisp to somthing allready there.
Have a nice day.
Check a new and very exiing building method, that was develobed using Lisp ;
http://w1.1396.telia.com/~u139600113/a
Thien-Thi Nguyen
> If I can understand lisp, "grok" it, then the rest is just syntax and
> functions.
this approach is akin to understanding philosophy through memorizing events.
thi
Christian Lynbech
Alain> How in the _world_ do *really* *large* systems (airline reservation,
Alain> IRS, etc) ever get constructed? Anybody been involved in a
Alain> 1000+ manyear (successful) project want to tell the tale?
Isn't this what Fred Brooks "The Mythical Man Month" is basically
about? As I remember he relates his experiences from the construction
of the IBM 360, both HW and SW. One (still from memory) was a big
success and the other had huge problems, and both were big projects.
One of Fred Brooks observations was exactly that team size is
important. He speaks mostly of it in the context of the architectural
design, where he advocates that very few, preferably one or two, is in
supreme charge of that part.
He also talks about the "Surgical Team" which wants to organize
programming like surgery, ie. there is only one to wield the scalpel
and a bunch of people around him to make sure he has everything that
needs at the right time.
Allthough the book is more than 20 years old, it still has a lot of
good points to tell us, IMHO.
------------------------+-----------------------------------------------------
Christian Lynbech | Ericsson Telebit, Skanderborgvej 232, DK-8260 Viby J
Phone: +45 8938 5244 | email: christia...@ted.ericsson.se
Fax: +45 8938 5101 | web: www.ericsson.com
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- pet...@hal.com (Michael A. Petonic)
Alain Picard
> >>>>> "Alain" == Alain Picard <api...@optushome.com.au> writes:
>
> Alain> How in the _world_ do *really* *large* systems (airline reservation,
> Alain> IRS, etc) ever get constructed? Anybody been involved in a
> Alain> 1000+ manyear (successful) project want to tell the tale?
> Isn't this what Fred Brooks "The Mythical Man Month" is basically
> about?
Yes, of course. I've read that book (many times); it's one
of the few great pieces of literature about our field.
But I'm still curious about war stories by actual participants.
Erik Naggum
| Allthough the book is more than 20 years old, it still has a lot of good
| points to tell us, IMHO.
The 20th anniversary edition has four more essays that are worth reading,
too. http://www.amazon.com/exec/obidos/ASIN/0201835959