New to Lisp question: advantages of Lisp syntax?
Jonathan
thing I regret is that I'm having to take it slowly because of other (C++
based) commitments. The combination of dynamic typing, powerful data-types
and C++ speed from implementations like Allegro is very much the realization
of a dream for me - so enough of the plug. The only weak feature I've
discovered so far in Lisp is it's inability to attract attention to its
strengths. In particular, all the programmers I know mis-classify it as
impractically slow. I suspect a lot of people are taught this at university
in those silly courses which try to summarize the features of a dozen
different languages in fewer lectures, and which are often taught by someone
who's only used one of them. Perhaps the major vendors should get together
and re-launch the language?
So far it's Lisp semantics that have impressed me (dynamic typing,
associative arrays, closures.) I find its S-expression syntax fun to write,
but it hasn't grabbed me in the same way. At the moment it's something
that's fun, that I have to learn to get the semantic advantages of Lisp, but
which I don't really see the benefits of. And I know that there languages
which try to match Lisp semantics to Algol syntax. Python seems a clear
example, Dylan another... Perl *might* make a third if you squint when you
look at it and wear sunglasses. I'd be very tempted to use Dylan if there
was an implementation I felt matched the best Lisp compilers, and if its
future looked more secure. I'd love to use Python for the jobs I'm looking
at Lisp for, but it's much too slow.
What I'd like to know, are there advantages to S-expression syntax that I'm
going to come to know and love in the future? I'm already aware that Lisp is
ahead of the other languages I know in terms of some of its other
syntactical features - I'm thinking of macros here of course. It's
s-expression syntax, and any advantages its offers a practising programmer
that I'd like to know about, if someone feels like talking.
Jonathan Coupe, XWare
Johan Kullstam
[snip]
> What I'd like to know, are there advantages to S-expression syntax that I'm
> going to come to know and love in the future?
[snip]
> I'm already aware that Lisp is
> ahead of the other languages I know in terms of some of its other
> syntactical features - I'm thinking of macros here of course. It's
> s-expression syntax, and any advantages its offers a practising programmer
> that I'd like to know about, if someone feels like talking.
yes. lisp-expressions have an extremely regular (if a bit boring)
syntax. this is imho the whole advantage. you can easily make code
that generates more code, i.e., macros! you can also make your own
functions which act just like built-in functions (many built-ins are
lisp functions). contrast this to C++ where templates are rigid
cookie cutters and you only have a finite set of operators.
--
J o h a n K u l l s t a m
[kull...@ne.mediaone.net]
Don't Fear the Penguin!
R. Matthew Emerson
[...]
> So far it's Lisp semantics that have impressed me (dynamic typing,
> associative arrays, closures.) I find its S-expression syntax fun to write,
> but it hasn't grabbed me in the same way. At the moment it's something
> that's fun, that I have to learn to get the semantic advantages of Lisp, but
> which I don't really see the benefits of.
If it's fun, then be happy! I like the fully parenthesized prefix
notation---my editor formats it for me in a standard style automatically,
I don't have to remember a bunch of rules about where semicolons
go or don't go, and I don't have to think about operator precedence.
[...]
> What I'd like to know, are there advantages to S-expression syntax that I'm
> going to come to know and love in the future? I'm already aware that Lisp is
> ahead of the other languages I know in terms of some of its other
> syntactical features - I'm thinking of macros here of course. It's
> s-expression syntax, and any advantages its offers a practising programmer
> that I'd like to know about, if someone feels like talking.
I just re-read a paper by Steele, titled "Growing a Language" (I
printed it out a while ago, but have forgotten where I got it).
The argument of the paper was that the most important thing a language
designer can do is to plan for the growth of the language. He cites
Lisp as an example of a language that can grow: "In Lisp, new words
defined by the user look like primitives, and what is more, all
primitives look like words defined by the user! In other words, if
a user has good taste defining new words, what comes out is a larger
language that has no seams."
Contrast this (as Steele does) with APL, or with Roman numerals.
Doing addition with them is pretty easy. But they don't grow: try
doing multiplication with them. Or tallying the US national debt with
them.
Lisp just doesn't have much syntactic structure. I've found a comment
in the preface of SICP to be true: with Lisp, since there is hardly
any syntax, you just forget about it and get on with the business of
programming.
Syntactic sugar causes cancer of the semicolon.
(attributed to Alan Perlis)
Lisp is a programmable programming language.
--John Foderaro
-matt
Erik Naggum
| The only weak feature I've discovered so far in Lisp is it's inability to
| attract attention to its strengths.
well, how did _you_ discover it? and why don't you think that's relevant?
| In particular, all the programmers I know mis-classify it as
| impractically slow.
but why does this matter to you? do they know anything about Lisp at all?
| I find its S-expression syntax fun to write, but it hasn't grabbed me in
| the same way.
if you use an editor that supports movement based on parentheses, like
Emacs, you may find yourself appreciating it more. e.g., the ability to
skip whole forms, move up and out of a form, or forward and down, and
with some packages, to raise a form up a level, etc, you might find that
navigation in code is much simplified by a regular use of delimiters.
| What I'd like to know, are there advantages to S-expression syntax that
| I'm going to come to know and love in the future?
the simple answer is yes. patience and willingness to learn and observe
is all you need, and it will come to you. if you push, you'll miss it.
#:Erik
--
@1999-07-22T00:37:33Z -- pi billion seconds since the turn of the century
Kent M Pitman
> I find its S-expression syntax fun to write,
> but it hasn't grabbed me in the same way.
Stick with it and you will understand. I promise this is not a minor
matter. However, you *must* learn Emacs and get used to using matching
paren flashing, and the various lisp-mode commands, including those
for indentation and motion and killing. The ability to manipulate lisp
expressions as units and not individually as areas of text is massively
empowering when you get it down. I have had specific probjects in which
this choice of syntax has improved my throughput, I estimate, by at least
one and maybe two orders of magnitude because of the way it works in
combination with keyboard macros. If you have to write keyboard macros
that search for the end of an expression and kill the intervening text,
they will never work reliably when you nest expresssions. Consider being
at this point:
cruft
foo xxx
end foo
[CURSOR]
foo blah
bar whatever
baz
baz
bar quux
foo something
etc
etc
end foo
end bar
end bar
end foo
cruft
and imagine the difficulty of writing something that manipulates balanced
sets of foos or bars in some interesting way interactively.
the problem is that you can't. but in lisp, you can press control-meta-t
in emacs at the same point
(...
(cruft)
(foo xxx)
(foo (bar whatever
(baz)
(baz)
(bar quux)
(foo something
(etc)
(etc))))
(cruft)
...)
and it can be done trivially. **SEE TRANSCRIPT AT END**
(...
(cruft)
(foo (bar whatever
(baz)
(baz)
(bar quux)
(foo something
(etc)
(etc))))
(foo xxx)
(cruft)
...)
** TRANSCRIPT FOLLOWS ** This is an exact keystroke log of what I had to
do to make the output expression with an empty buffer below the point
that says ** SEE TRANSCRIPT AT END ** and beginning with the cursor at the
end of that line.
control-a // move to start of line
esc control-b // back over s-expression
esc control-k // kill s-expression in front of cursor
control-y // restore killed s-expression, keeping copy on kill ring
control-u 4 control-n // go down four lines
control-y // restore copy of killed s-expression
esc control-b // back over [copied] s-expression
control-u 3 control-n // go down three lines
control-meta-t // transpose s-expression before cursor with one after cursor
Total of 16 keystrokes (not really optimal--i could have done better but
it would have been harder to explain), but the really key thing is that
this is the kind of edit you could automate. You can make the superficial
claim that by pointing and clicking you can move the text in less time,
but in so doing you can never remove the human from the loop. What is cool
about Lisp syntax isn't the look per se but what you can do with it, and
until you allow yourself to learn how to use it, you aren't going to get it.
Sorry if this message is a bit hard to parse. It's hard to contrive an
interactive example on the fly and then express it in text. I think
there is enough information here for you to reconstruct what I'm saying.
Ask if you have questions.
thi
is groovy because each rung of the ladder is perfect in its own right,
recursive nature is cleanly mapped; it is fine because you can easily
M-C-climb-inside-a-tree.
these are opinions, and only advantageous if they support your goals.
what are the goals of the other programmers?
thi
Martin Rodgers
scrawled in the dust by R. Matthew Emerson in a flowery script, reading:
> I just re-read a paper by Steele, titled "Growing a Language" (I
> printed it out a while ago, but have forgotten where I got it).
It's available from Philip Wadler's homepage:
http://achille.research.bell-labs.com/cm/cs/who/wadler/steele-oopsla98.ps
There's also a video:
http://www.uvc.com/videos/oo98Steele.video.html
--
Please note: my email address is munged; You can never browse enough
"There are no limits." -- ad copy for Hellraiser
Jonathan
Erik Naggum wrote in message <31372718...@naggum.no>...
>* "Jonathan" <jona...@meanwhile.freeserve.co.uk>
>| The only weak feature I've discovered so far in Lisp is it's inability to
>| attract attention to its strengths.
>
> well, how did _you_ discover it? and why don't you think that's
relevant?
>
Because it has nothing to with the advantages of Lisp syntax, the subject of
the post. The info that I'm new to Lisp
but like it a lot was added to provide context (ie I'm fairly clueless about
Lisp, and this is not a flame.)
>| In particular, all the programmers I know mis-classify it as
>| impractically slow.
>
> but why does this matter to you? do they know anything about Lisp at
all?
It bothers me because
(1) I want the world to be a better place, when I can arrange it at no
particular inconvenience to myself.
(2) More lisp users = better support at lower cost (compare the cost of
Allegro to even an excellent C++ compiler - KAI for
Linux is peanuts (I should add I only know the Windows prices for Allegro)),
even more importantly compare CPAN to the code
available for Lisp. Even stuff like buying Lisp books is a pain - I found
one *copy* of a book on CL in all of Manchster, which is one
of the biggest university towns in the UK, plus home to a fair number of
software companies. Even "Advanced Lisp" is a special order
(takes weeks, may never get it) at amazon.co.uk, I think.
And there are some other reasons as well, involving the logistics of funding
and hiring for projects.
Jonathan
john....@alcoa.com
Kent M Pitman <pit...@world.std.com> wrote:
> Stick with it and you will understand. I promise this is not a minor
> matter. However, you *must* learn Emacs and get used to using
In the Windows world both Allegro and Lispworks come with integrated
Emacs like editors. I think that they are good enough, especially for
the beginner. There is no need to use the real Emacs and in fact of the
two only Allegro makes allowances for using GNU Emacs or Xemacs as
optional editors with a high degree of intercommunication with the Lisp
process.
John Watton
ALCOA
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Jeffrey Mark Siskind
When I teach Lisp/Scheme I start the course as a dictator. Among other things,
I require the students to use Emacs and require them to hand in assignments
that have been automatically formatted with c-x h c-m-\. And they get zero if
they hand in an assignment and I run c-x h c-m-\ and the file contents change.
Students complain bitterly, at first.
One of the assigments that I give is to write factorial in the pure lambda
calculus. With Peano arithmetic, Church numerals, and the Y combinator. I
suggest that they write it by successively transforming the straightforward
Scheme implementation. And I teach them all of steps. One of the
transformations is
(let ((X E1)) E2) --> ((lambda (X) E2) E1).
I remember students spending a dozen hours applying the above transformation
by hand, even in Emacs, using the cursor keys. And dozens of students came for
help because such hand editting introduced numerous bugs that were hard to
track down. (It really is difficult to debug lambda calculus programs because
everything is a closure.) And they spent several dozen hours applying all of
the transformation needed for the problem set. And they complained bitterly.
Then I showed them how they could do it all with a simple Emacs keystroke
macro. And it took about 45 seconds. (Writing that macro is left as an
exercise for the reader.) Some of the students get it and are blown away. And
they understand and appreciate why I start the course as a dictator. Others
don't. One of the students who was blown away said: `Its a shame that the
students of our generation grew up with windows and mice because that tainted
our mindset not to think in terms of powerful tools. Some of us are just so
tainted that we will never recover.'
john....@alcoa.com
"Jonathan" <jona...@meanwhile.freeserve.co.uk> wrote:
> software companies. Even "Advanced Lisp" is a special order
> (takes weeks, may never get it) at amazon.co.uk, I think.
Never heard of "Advanced Lisp". I suggest that you stick with more
current Lisp texts. Amazon.com's top four sellers are my
recommendations:
1) ANSI Common Lisp, Paul Graham
2) Paradigms of Artificial Intelligence Programming: Case Studies in
Common Lisp, Peter Norvig
3) On Lisp, Paul Graham
4) Common Lisp the Language, 2nd Ed., Guy Steele
--
John Watton
Alcoa Inc.
Sashank Varma
Matthew Emerson) wrote:
[snip]
> I just re-read a paper by Steele, titled "Growing a Language" (I
> printed it out a while ago, but have forgotten where I got it).
[snip]
it can be found at:
http://cm.bell-labs.com/cm/cs/who/wadler/steele-oopsla98.ps
sashank
Erik Naggum
| Because it has nothing to with the advantages of Lisp syntax, the subject
| of the post.
my reason for asking you how _you_ found Lisp was that you did find it
despite the negative impressions. others do the same. all the time.
| It bothers me because
|
| (1) I want the world to be a better place, when I can arrange it at no
| particular inconvenience to myself.
well, the world becomes a better place if you make it a better place for
you and those around you. you can't cure stupidity or prejudice, and
trying will bring you particular inconvenience. if you want to try, at
least do it with something that _actually_ hurts others. people's bad
impressions of Lisp don't hurt anybody (actively), but any change of
impression will win big.
| (2) More lisp users = better support at lower cost
this is not quite true, for a whole number of complex reasons.
| (compare the cost of Allegro to even an excellent C++ compiler ...)
well, compare the cost of using them, instead. Allegro CL is cheaper
than even a _free_ C++ compiler.
| Even stuff like buying Lisp books is a pain
no, but you _make_ it a pain. you look in the wrong place and don't find
what you want and then think it should be there and become inconvenienced
and unhappy. just don't do that. use the Lisp community, instead. find
people who _share_ you fun, don't go look for people in general and
complain that they don't share your fun. nothing worthwhile is ever
shared by the majority of people. and if it's mass-marketed, you better
not care personally about it -- nobody else does.
| Even "Advanced Lisp" is a special order (takes weeks, may never get it)
| at amazon.co.uk, I think.
well, the problem with the Internet and these online book stores is that
they tell you what you can't get, so you can complain about it. would it
be better not to tell you about that book unless they could provide it?
| And there are some other reasons as well, involving the logistics of
| funding and hiring for projects.
very true, but a suddenly higher demand for Lisp programmers right now
would mean a lot of people would have to lie about their skills, the way
they lie about their C++ skills. _most_ people who seriously want to do
Common Lisp for pay, can do it. those who know Common Lisp and would
prefer it if given the opportunity, do number some people, but not a lot.
if this "Common Lisp reserve" was called into duty, we would have a
problem. but I'll tell you what. three years ago, I knew of no
commercial Common Lisp activity in Oslo, but a lot of people had been
talking about Common Lisp (within my earshot) for a decade or more. I
argued Common Lisp into a project, but it turned out that the management
was allowing me to do whatever I wanted because they were ripping off the
government printing office instead of doing solid business. oh, well.
another project started better, and now hires a lot of programmers. my
current project has spawned interest from yet others. as of right now, I
know of more than 10 people who do Common Lisp work for money, and I get
phone calls about once a month for new projects or ideas from people who
have heard about me or read my web pages -- no advertising here at all.
the demand _is_ rising, but not faster than skilled programmers are
formed -- there are a bunch of promising people at the U of Oslo. (not
in the CS Dept, of course -- one leading figure there caused the AI and
Lisp folks to leave for another department, but he has since expired, and
there are promising changes.) I'm not sure I can even relate to people
who think Lisp is in a rut. I have a lot of contact with Franz Inc, and
it they are generating more business, too. this is a good time to be
upbeat about Common Lisp.
Jonathan, you've made the important first step. please accept my welcome
into the Lisp community, but don't start off wanting a better world;
start _making_ a better world: become a great Common Lisp programmer.
Martin Rodgers
scrawled in the dust by Jonathan in a flowery script, reading:
> Even stuff like buying Lisp books is a pain - I found
> one *copy* of a book on CL in all of Manchster, which is one
> of the biggest university towns in the UK, plus home to a fair number of
> software companies.
I had to order most of my Lisp books, and the bookshop people are
sometimes suprised that an individual is making the order. This doesn't
hinder the order, of course.
In the last 15 years, I've watched the computer bookshelves slowly shift
away from programmers. However, it's still possible to sometimes find a
programming gem. I even found a copy of SICP in my local Waterstones a
few years ago.
So, my advise is to still look at the bookshelves but also read book
recommendations in places like this, and then order the books you want.
Arthur Lemmens
> What I'd like to know, are there advantages to S-expression syntax
> that I'm going to come to know and love in the future?
Definitely.
S-expression syntax makes programs and data look the same. Combined
with macros and READ/WRITE, this gives you a lot of flexibility when
attacking new problems. With S-expression syntax, you can grow your
own problem-specific language on the spot, while you're still
exploring your problem space.
Suppose you want to generate HTML.
Then something like the following notation seems quite natural:
(body ()
(h1 () "Big fat title")
(table (:width "80%")
(tr ()
(td (:align "right")
"Some table contents.")
(td (:align "left")
"More of the same."))))
Now, is this a program or is it just a datastructure?
There's no way to tell. It depends on the context.
And THAT'S THE BEAUTY OF IT.
You can write down relevant facts in your just-invented
notation even before you've decided upon the best way to
deal with those facts.
As long as you use a reasonably consistent notation (here we
always put the element name in the first, attribute list in
the second and child elements in the rest of the list), you
can be sure that it will be quite easy to process your notation.
You could put this S-expression in a file, use READ to get a
nice tree-shaped datastructure and generate the HTML from there.
Or maybe you decide it's better to define a few macros that
expand into functions that generate HTML on the spot.
In this case, you might even decide to define a macro-defining
macro, as in:
(def-html-element table '(width "100%" align "left"))
which could expand into something like:
(defmacro table ((&key (width "100%") (align "left")) &body children)
;; Generate HTML-ish strings.
;; In real life, this would be more complicated.
(format nil "<TABLE width='~A' align='~A'>~A</TABLE>"
width align children))
In a way, S-expression syntax is one more demonstration of the
advantages of late binding. It allows you to defer decisions
until you're ready to handle them. It allows you to gain experience
and do useful work at the same time.
Arthur Lemmens
Kenny Tilton
> Thanks for the enthusiastic welcome
>
<heh-heh> anyway...
FWIW, yup, it took a while to get used to starting with "(", but now:
myFunc( 1, 2, 3);
looks perfectly incoherent to me. That "myfunc" looks like it is going
to drop off or drift away. What are those commas doing there? What's
with that semi-colon? Oh! The syntax requires them...
You want to know one of the incredible things about this syntax? I feel
silly bringing it up, but it seems to me about half my code revisions
involve double-clicking one s-expression, cutting or copying it,
double-clicking another, pasting it....
As for proselytizing for Lisp, well, yeah, that shows you are a True
Lisper...your first reaction upon getting to know it is, jeez, people
should know about this! Welcome to the club!
My only thought is, gosh it's hard to redirect a stampede. And i think
cattle are more coachable than humans. :)
ken
Tim Bradshaw
> What I'd like to know, are there advantages to S-expression syntax that I'm
> going to come to know and love in the future? I'm already aware that Lisp is
> ahead of the other languages I know in terms of some of its other
> syntactical features - I'm thinking of macros here of course. It's
> s-expression syntax, and any advantages its offers a practising programmer
> that I'd like to know about, if someone feels like talking.
Macros! Because Lisp has such a minimal and boring syntax it's really
easy to write programs that manipulate Lisp source code, and
essentially custom build your own language. Common Lisp is just such
a custom built language.
It's quite possible to do this in languages with richer syntaxes too,
but there is a danger in a language like that of having the syntax
make a commitment to what sort of thing a bit of source is. for
instance if you see:
((foo bar)
(henry bater))
it could be a set of binding clauses of some kind, or possibly some
kind of dispatch in a case-type statement, whereas if C had a macro
language worth speaking of, it would be much less convincing to say
that:
{x; y;}
was anything other than a block.
The point I'm trying to make is that Lisp syntax, by not committing
you to very much, allows you to develop entirely new constructs in
your custom-built language. Binding clauses are really such a thing
(although I don't know if the development happened like this
historically). You start with a lower-level thing like
((lambda (x y) ...)
a b)
and end up with
(let ((x a) (y b)) ...)
where the ((x a) (y b)) is a whole new kind of animal in your
language.
--tim
Jonathan
Erik Naggum wrote in message <31373299...@naggum.no>...
>* "Jonathan" <jona...@meanwhile.freeserve.co.uk>
>| Because it has nothing to with the advantages of Lisp syntax, the subject
>| of the post.
>
> my reason for asking you how _you_ found Lisp was that you did find it
> despite the negative impressions. others do the same. all the time
Who can argue with that? Actually I found out by accident. I was hunting
down scripting language resources, someone suggested I checkout Kawa or Lava
(JVM Schemes) and that lead to a very interesting set of decision tree
algorithms that told me that CL's old slow execution speed problems have
been solved. (Excution speed is critical for my work. Lisp is going to have
to work with C and assembly on projects I might use it for.)
>| It bothers me because
>|
>| (1) I want the world to be a better place, when I can arrange it at no
>| particular inconvenience to myself.
>
> well, the world becomes a better place if you make it a better place for
> you and those around you. you can't cure stupidity or prejudice, and
> trying will bring you particular inconvenience. if you want to try, at
> least do it with something that _actually_ hurts others. people's bad
> impressions of Lisp don't hurt anybody (actively), but any change of
> impression will win big.
>
I agree with most of this - splendid stuff. But even as someone who finds
programming in C++ easy, comfortable, and familiar, I would like people to
have more information on truly alternative programming systems. Different
tools for different jobs and all that - I'm thinking about design
possibilities more than libraries. C++ is very over-used - it's a language
way beyond the skills and discipline of many of its users, and is often
inappropriate for the projects its chosen for. I suspect that Dylan
(Algoloid with a Lisp-ish machine, I understand?) would be a more
appropriate choice for most of this stuff - Lisp I see as more of a niche
product for cutting edge work.
[Re buying Lisp Books -something I've found very hard to find]
> no, but you _make_ it a pain. you look in the wrong place and don't find
> what you want and then think it should be there and become inconvenienced
> and unhappy.
Well, if you can tell me where to buy Lisp books either in Manchester (UK)
so I can look them over before paying, or via the net from a store with
cheap UK deliveries, good security, and a two week plus refund facility like
Amazon's - great.
Thanks for the enthusiastic welcome
Jonathan
Kent M Pitman
5*A+B
^
Cursor here
Imagine trying to write a "go forward over next expression" command
in the editor. You can't. That cursor position is punning. It
refers to two starts of expressions at the same time (just as surely
as using the same line number to end two DO loops in Fortran is
punning... if anyone still knows what I'm talking about.) But in
Lisp:
(+ (* 5 A) B)
^ ^
1 2
There are two points your cursor would have to be and they are distinct.
Yes, it's more verbose. But it allows much more flexible cursor motion
because it is generally ambiguity-free what "next expression" means.
Erik Naggum
| Actually I found out by accident.
that's good, because almost everything good in life happens by accident.
| I was hunting down scripting language resources, someone suggested I
| checkout Kawa or Lava (JVM Schemes) and that lead to a very interesting
| set of decision tree algorithms that told me that CL's old slow execution
| speed problems have been solved. (Excution speed is critical for my
| work. Lisp is going to have to work with C and assembly on projects I
| might use it for.)
earlier you said they said "Lisp is slow", now you're modifying it to
"Common Lisp is slow". the latter has _never_ been true. the former is
true of interpreted Scheme environments and other toy stuff that wants to
enjoy the "Lisp" label. of course, older Lisp environments were serious
enough, but predate several important advances in Lisp technology. one
such example is Emacs Lisp, which is based on an old Lisp in use at MIT,
which was for all practical purposes superseded by Common Lisp.
so saying that Common Lisp is slow is like saying that C++ doesn't have
classes, because Lisp is slow and C doesn't have classes. one of the
more important things you'll observe from the Lisp community is that it
is a _union_ of communities, with all that that implies, such as not
having all that much in common. Common Lisp is a _particular_ Lisp,
which means it shares a host of qualities with other Lisps, most of them
being quite abstract. however, it also means there are differences from
the other Lisps, and one of them is that it is not a toy Lisp best suited
for students to make implementations of in a one-semester class.
if you object to your peers thinking that Common Lisp is slow, I would
agree that they deserve to be corrected. we can live with the history of
Lisp: yes, it once was slow and resource-intensive, and misconceptions
from that history are legitimate. it is not, however, legitimate to
believe that changes important enough to change the name of the language
were unimportant.
now, the reason I'm being quite heavy on this is that execution speed is
not critical for more than 0.01% of the work people do with computers,
despite beliefs to the contrary. there are several ways to know whether
speed is _really_ critical to your work: (1) you upgrade to the top of
the line processor the day it is announced, (2) you port your application
to new environments when it can save you 5% execution time, (3) you spend
99% of the time on developing the application in the time profiler, (4)
you do custom compilation, and (5) you have enough memory that you will
never hit the disk in paging and all your file systems are in memory. if
even one of these isn't true for you, execution speed is not critical,
but some other choice is. if all you're really after is "fast enough",
which is what most people are, the important word is "enough" not "fast",
strange as that may seem to someone from the C++ world. if you want
immediate response at the front-end of your application, but back-end
stuff can be scheduled for less-critical execution time, you will win big
by putting requests on the "dregs queue". it's hard to do this in
languages other than Common Lisp, so most people don't consider that
possibility, but operating system designers have thought in just these
terms for decades. using Allegro Common Lisp (www.franz.com) and its
very strong multiprocessing support, I have managed to layer my code such
that response times are extremely low, but the system keeps working for
up to 5 seconds after servicing a request, without hurting the response
time for the next request at all. of course, we pay for this in terms of
total CPU time spent and the internal scheduling is far from cheap, but
the end result is actually _far_ better response times than I could
imagine myself getting from a C-based application, and let's heed the old
adage: if you don't use the CPU power now, it's gone forever, so whether
the CPU is idle or performs low-priority tasks when not servicing
high-priority tasks is quite literally irrelevant. you can and should
use such unlikely relations to your advantage if you want high
performance, as distinctly opposed to high speed.
BPer...@computasoft.com
m...@wildcard.butterfly.demon.co.uk (Martin Rodgers) wrote:
> There is a message <7j375m$90q$1...@news8.svr.pol.co.uk>
> scrawled in the dust by Jonathan in a flowery script, reading:
>
> > Even stuff like buying Lisp books is a pain - I found
> > one *copy* of a book on CL in all of Manchster, which is one
> > of the biggest university towns in the UK, plus home to a fair
number of
> > software companies.
>
> I had to order most of my Lisp books, and the bookshop people are
> sometimes suprised that an individual is making the order. This
doesn't
> hinder the order, of course.
Well in this respect I've been lucky. Out of the 10 Lisp (common and
scheme) books that I've purchased I've only had to place orders for 2
of them - essentials of programming languages, which I could have
bought off the shelf at Foyles had I looked hard enough, and
object oriented programming in common lisp that I ordered from
amazon.co.uk with an estimated shipping time of 3 weeks and an actual
shipping time of 1 week.
> So, my advise is to still look at the bookshelves but also read book
> recommendations in places like this, and then order the books you
want.
This is good advice. Look at the ALU home,
http://www.elwoodcorp.com/alu/table/contents.htm
Also David Lamkins has some good reviews of lisp books, that you can
get to from the ALU site.
Barry
Sunil Mishra
> In the Windows world both Allegro and Lispworks come with integrated
> Emacs like editors. I think that they are good enough, especially for
I find them rather limiting, since all you can do on them is program lisp
code. Currently I have to manage programs in lisp, C, matlab, and sometimes
C++, to get any work done. Emacs provides so many facilities for this
variety of tasks. Beginner or not, starting with emacs IMHO is the better
way.
> the beginner. There is no need to use the real Emacs and in fact of the
> two only Allegro makes allowances for using GNU Emacs or Xemacs as
> optional editors with a high degree of intercommunication with the Lisp
> process.
Harlequin shipped ilisp with lw-4.1. I believe they had a package for emacs
with 3.2 as well, but I never used or even looked at it. ilisp has a few
quirks, but I generally find it quite robust and sufficient for my needs.
Sunil
Hartmann Schaffer
m...@wildcard.butterfly.demon.co.uk (Martin Rodgers) writes:
> ...
> I had to order most of my Lisp books, and the bookshop people are
> sometimes suprised that an individual is making the order. This doesn't
> hinder the order, of course.
I never had the problem (maybe because the clerks of the 2 bookstores I
frequent know me by now). The only reaction I found a few times is
"what is this?", which in one case eventually led to the store switching
from SCO to Linux)
> ...
Hartmann Schaffer
Lieven Marchand
> I had to order most of my Lisp books, and the bookshop people are
> sometimes suprised that an individual is making the order. This doesn't
> hinder the order, of course.
>
> In the last 15 years, I've watched the computer bookshelves slowly shift
> away from programmers. However, it's still possible to sometimes find a
> programming gem. I even found a copy of SICP in my local Waterstones a
> few years ago.
Some bookshops remain programmer friendly. There's one here in
Brussels where I have seen SICP, CLtL 2nd Edition, On Lisp, besides
books on Eiffel, ML, Ada95 and some very academic texts on type theory
and other advanced subjects. Off course, they also have metres and
metres of shelves devoted to C++, Java, Visual Whatever for Dummies
etc.
--
Lieven Marchand <m...@bewoner.dma.be>
If there are aliens, they play Go. -- Lasker
Martin Rodgers
scrawled in the dust by Hartmann Schaffer in a flowery script, reading:
> I never had the problem (maybe because the clerks of the 2 bookstores I
> frequent know me by now).
My local Waterstones may know me by now...The staff are different each
time I visit, but I may have developed a reputation! The last book I
ordered was "The Commissar Vanishes : The Falsification of Photographs
and Art in Stalin's Russia". At least one of their staff was impressed.
Most of the technical books that I've bought off the shelves, in the last
5 years, have been about Linux & Unix. A few firewall books, too.
It's time I bought another Lisp book. Where's my list...? ;)
Martin Rodgers
scrawled in the dust by Lieven Marchand in a flowery script, reading:
> Some bookshops remain programmer friendly. There's one here in
> Brussels where I have seen SICP, CLtL 2nd Edition, On Lisp, besides
> books on Eiffel, ML, Ada95 and some very academic texts on type theory
> and other advanced subjects. Off course, they also have metres and
> metres of shelves devoted to C++, Java, Visual Whatever for Dummies
> etc.
Alas. The lowest common denominator is very well catered for. In fact,
the choice is bewildering, or would be if I thought I needed any of it.
I used to visit Foyles in London to find the really good books. That's
where I found W&H 3rd ed., on my last visit to a number of London
bookshops. Now I order almost all of my books. Thanks to newsgroups like
this one, I have a long list to work thru.
If you like academic texts, there are one or two online papers that'll do
very nicely. ;) Perhaps that's why I have so few academic _books_.
Jonathan
>Never heard of "Advanced Lisp". I suggest that you stick with more
>current Lisp texts. Amazon.com's top four sellers are my
>recommendations:
I realized just after I posted that I actually meant "Paul Graham's advanced
lisp book, On Lisp." Thanks for the extra suggestions.
Jonathan
Paolo Amoroso
<jona...@meanwhile.freeserve.co.uk> wrote:
> What I'd like to know, are there advantages to S-expression syntax that I'm
> going to come to know and love in the future? I'm already aware that Lisp is
Some interesting thoughts about Lisp syntax may be found in the following
paper by Henry G. Baker:
"Pragmatic Parsing in Common Lisp"
ftp://ftp.netcom.com/pub/hb/hbaker/Prag-Parse.html
The well known paper "The Evolution of Lisp" by Richard Gabriel and Guy L.
Steele:
ftp://ftp.cs.umbc.edu/pub/Memoization/Misc/Evolution-of-Lisp.ps.Z
tells something about failed attempts at changing Lisp syntax.
Have fun,
Paolo
--
Paolo Amoroso <amo...@mclink.it>
Paolo Amoroso
<jona...@meanwhile.freeserve.co.uk> wrote:
> software companies. Even "Advanced Lisp" is a special order
> (takes weeks, may never get it) at amazon.co.uk, I think.
Aren't Amazon's foreign branches such as amazon.co.uk supposed to have in
stock mostly--local books (I don't know where "Advanced Lisp" was
published)? For books by American publishers it may be better to use
amazon.com. And yes, I know that in this case shipping charges are often
higher than book prices themselves.
By the way, have a look at the online book "Successful Lisp" by David
Lamkins:
http://www.teleport.com/~dlamkins/sl/html/cover.html
Paolo Amoroso
hasn't shown up yet in me news feed - Paolo]
On 03 Jun 1999 04:50:33 +0000, Erik Naggum <er...@naggum.no> wrote:
> * "Jonathan" <jona...@meanwhile.freeserve.co.uk>
[...]
> | speed problems have been solved. (Excution speed is critical for my
> | work. Lisp is going to have to work with C and assembly on projects I
> | might use it for.)
If users complain because the application is slow, give them something else
to do while the system is doing its job :-)
I seem to remember that user interface designer Bruce Tognazzini told the
following anecdote. At the beginning of the century, people complained that
elevators in a skyscraper were too slow, making waiting times at floors
intolerably long.
According to engineers, it was not possible to speed the elevators or
install better ones. So an interior decorator was called to solve the
problem. He covered the walls around the elevators at floors with huge
mirrors so that people could admire themselves and other people while
waiting for the elevators to arrive. Complaints ceased.
Jonathan
Erik Naggum wrote in message <31373742...@naggum.no>...
>* "Jonathan" <jona...@meanwhile.freeserve.co.uk>
>| Actually I found out by accident.
>
> that's good, because almost everything good in life happens by accident.
>
Well, that's emergence for you...
>
> earlier you said they said "Lisp is slow", now you're modifying it to
> "Common Lisp is slow". the latter has _never_ been true. the former is
> true of interpreted Scheme environments and other toy stuff that wants to
> enjoy the "Lisp" label. of course, older Lisp environments were serious
> enough, but predate several important advances in Lisp technology. one
> such example is Emacs Lisp, which is based on an old Lisp in use at MIT,
> which was for all practical purposes superseded by Common Lisp.
>
Perhaps we have a different defintion of slow. Those benchmarks I referred
to showed Allegro 3 running at a quarter of C++/STL speed. To me that's
very, very slow. I make my living optimizing code and I can usually beat the
library and compiler combination in question by more than an order of
magnitude - sometimes several. Allegro 4 showed a slight advantage. That's
good going. And execution speed matters in my markets - an awful lot.
Jonathan
Erik Naggum
| Perhaps we have a different defintion of slow.
no, but we do have a different definitions of performance. I want total
system performance: short response times to actual requests and never a
failure to perform as required. you want fast individual function
execution. and never the twain shall meet...
| Those benchmarks I referred to showed Allegro 3 running at a quarter of
| C++/STL speed.
since you aren't going to get hold of Allegro 3, why do you base anything
on such ridiculously out-dated statistics? has it occurred to you that
those who create and publish unfavorable benchmarks have an axe to grind?
| To me that's very, very slow.
_why_? this doesn't make sense at all. what would you say if I took one
of my examples and showed that the simple, direct, heavily optimized C
version is a whopping 16 times _slower_ than the simple, direct, heavily
optimized Common Lisp version of the same _problem_? (not at all the
same solution, of course, but what good is comparing _languages_ if you
don't do the most natural thing as well as possible in it?)
don't take this personally, Jonathan, but benchmarks are only good for
measuring the performance changes of a _single_ test subject under
various conditions, and those who believe otherwise are generally fools.
(you've discovered Lisp, so you're exempted.) benchmarks are good at
stuff like the same code given to Pentium II and Pentium III at the same
clock rate, like Pentium II at 400 and at 450 MHz, with 66MHz bus and
memory or with 100MHz bus and memory, etc. like the same C code given to
umpteen different compilers at their maximal optimization. or like the
same operating system and system hardware and performance of different
network cards, etc. benchmarks are only good under carefully controlled
conditions. lose that control, and you can prove just about anything.
| I make my living optimizing code and I can usually beat the library and
| compiler combination in question by more than an order of magnitude -
| sometimes several.
what a magnificent waste. why don't you go work for a Lisp vendor?
| And execution speed matters in my markets - an awful lot.
having heard this line from people who subsequently could neither defend
their actual speed need nor prove to be doing anything serious about it
(which means sacrificing something else to get it), I have very serious
doubts about this claim. in fact, I think it's a myth, and that those
who perpetuate the speed myths are incompetent at anything but optimizing
individual operations, and the problem is: that's damn easy. it's also
very, very rewarding once you set your mind on that track, like a drug
addiction, not the least because you can always shave off one more cycle.
recently, I cut the CPU expenditure on one piece of functionality in my
application by a factor of 13,000. one of the speedups meant that all
but the fastest cases took a pretty high constant delay, but the overall
result was a factor 90 performance improvement. this would not have been
a smart move unless I knew that the complex memoization technique I used
would pay off. in the general case, it's wasteful and costly, and not
the kind of thing a C programmer would think about doing. for my needs,
the total cost of the function in C is twenty times higher than the total
cost of the function in Common Lisp, even though the first call is about
3.5 times more expensive than the C version. and as we connect more
clients, the more the Common Lisp version will outpace the C version.
the funny thing about this is that I probably wouldn't have chosen to use
a complex memoization technique if the code had been "fast enough"...
Stefan Kain t4247
> Some bookshops remain programmer friendly. There's one here in
> Brussels where I have seen SICP, CLtL 2nd Edition, On Lisp, besides
I have ordered it at amazon.de, but they say, the main supplier from
UK is in trouble to provide imports from the US.
Dear Mr. Marchand,
Do you think, there's a way, that I could order this book with your
help from this particular (lisp friendly) bookstore??
I would really appreciate your help.
Bye,
Stefan
--
=============================================================================
Stud. Stefan Kain Universitaet Regensburg
Institut fuer Experimentelle und Angewandte Physik D-93040 Regensburg
e-mail Stefa...@physik.uni-regensburg.de Germany
=============================================================================
Jonathan
> Amazon.com's top four sellers are my
>recommendations:
>
>2) Paradigms of Artificial Intelligence Programming: Case Studies in
>Common Lisp, Peter Norvig
>3) On Lisp, Paul Graham
>4) Common Lisp the Language, 2nd Ed., Guy Steele
>
>--
>John Watton
>Alcoa Inc.
>
I'd like to add a suggestion to these. But anyone who reads this on dejanews
shoul note that I'm new to Lisp and asked for book suggestioons in the
first place - this is not the advice of someone who already knows Lisp! But
David Lamkins has placed an excellent, book length tutorial on his site.
Work's still in progress but there's a lot there. Looks very good to me and
you can go there now. A cd containing the full text may be available some
day.
Thanks, David.
It's at
http://www.teleport.com/~dlamkins/
Jonathan
Jonathan
>| C++/STL speed.
>
> since you aren't going to get hold of Allegro 3, why do you base anything
> on such ridiculously out-dated statistics? has it occurred to you that
> those who create and publish unfavorable benchmarks have an axe to grind?
>
You said that CL had *never* been slow. I quoted those stats to show why I
consider that it has in the past, by my standards. The guy who published
those stats was grinding an axe by the way - he was pro-Lisp. The benchmarks
were simply honest. He added Allegro 4's figures asap and they were, as I
said, excellent.
>| To me that's very, very slow.
>
> _why_?
Because where I make my living the guy with the fastest code usually wins.
1/12 (CL as was, not is, compared to likely C performance) would have ruined
me. We'll often put man-years into getting a factor of 10 speed-up.
Jonathan
Michael Schuerig
> Aren't Amazon's foreign branches such as amazon.co.uk supposed to have in
> stock mostly--local books (I don't know where "Advanced Lisp" was
> published)? For books by American publishers it may be better to use
> amazon.com. And yes, I know that in this case shipping charges are often
> higher than book prices themselves.
No, judging from my experience with amazon.de they have no problem at
all getting US books. I hope this works out for "On Lisp", too...
Michael
--
Michael Schuerig
mailto:schu...@acm.org
http://www.schuerig.de/michael/
Thomas A. Russ
>
> If users complain because the application is slow, give them something else
> to do while the system is doing its job :-)
I encountered an anecdote about the Think C compiler for the Macintosh
that has some similarities to your anecdote.
Apparently users were complaining about the slow speed of the compiler
and the long waits until it finished compiling projects. The compiler
writer was able to not only eliminate the complaints, but also impress
people with the speed of the compiler by adding a dialog box that
counted up the number of lines of source code processed.
Although the need to update the interface actually lengthened the time
needed to compile the project, seeing the number of lines incrementing
faster than could be read gave the impression of great speed.
--
Thomas A. Russ, USC/Information Sciences Institute t...@isi.edu
Kenneth P. Turvey
> who think Lisp is in a rut. I have a lot of contact with Franz Inc, and
> it they are generating more business, too. this is a good time to be
> upbeat about Common Lisp.
I hope you are correct, but Franz is a privately held company. How do
you know what their earnings are? If the information has been made
public, I would be interested in it myself.
--
Kenneth P. Turvey <ktu...@SprocketShop.com>
----------------- http://www.tranquility.net/~kturvey
I find it rather easy to portray a businessman. Being bland, rather
cruel and incompetent comes naturally to me.
-- John Cleese
Lyman S. Taylor
>
> On 02 Jun 1999 16:31:59 +0000, Erik Naggum <er...@naggum.no> wrote:
> > who think Lisp is in a rut. I have a lot of contact with Franz Inc, and
> > it they are generating more business, too. this is a good time to be
> > upbeat about Common Lisp.
>
> I hope you are correct, but Franz is a privately held company. How do
> you know what their earnings are?
He knows what Franz says they are. This hasn't been authenticated by
indepedent auditors. If you have a business relationship with a private
company then it is prudent to ask "how are you doing?" from time to time.
It isn't a SEC filing, but if trustworthy folks, it can be a general
indication.
I bet if you ask nicely they'd tell you in general terms too. ;-)
By the way, I get the same general impression from my interactions also.
It isn't like Franz has a Microsoft sized slush fund, but it isn't like
they
don't have two nickels to rub together either.
---
Lyman
Robert Swindells
>> There is a message <7j375m$90q$1...@news8.svr.pol.co.uk>
>> scrawled in the dust by Jonathan in a flowery script, reading:
>>
>> > Even stuff like buying Lisp books is a pain - I found
>> > one *copy* of a book on CL in all of Manchster, which is one
>> > of the biggest university towns in the UK, plus home to a fair number of
>> > software companies.
>>
>> sometimes suprised that an individual is making the order. This doesn't
>> hinder the order, of course.
>Well in this respect I've been lucky. Out of the 10 Lisp (common and
>scheme) books that I've purchased I've only had to place orders for 2
>of them - essentials of programming languages, which I could have
>bought off the shelf at Foyles had I looked hard enough, and
>object oriented programming in common lisp that I ordered from
>amazon.co.uk with an estimated shipping time of 3 weeks and an actual
>shipping time of 1 week.
I'm not very impressed with the bookshops in Manchester. Blackwells
just seems to have course texts and Waterstones mostly just has idiots
guides to whatever is currently fashionable.
Waterstones has one small shelf of professional level books hidden
behind the sales counter, presumably so they don't frighten people.
As a comparison, how many copies of Ellis & Stroustrup would you
expect to find in an average bookshop. I'm pretty sure I had to order
mine.
One other thing to consider is that Manchester used to be a big prolog
site. The Blackwells in Liverpool used to order one of any new lisp
book that came out since there was a fair chance of someone buying it.
Most of the computing books that I have bought off the shelf have been
either from Heffers in Cambridge or from the Gower St. branch of
Dillons (opp UCL). Heffers will do internet orders as well.
Robert Swindells
Erik Naggum
| I hope you are correct, but Franz is a privately held company. How do
| you know what their earnings are?
why do you assume I do? what the hell does public disclosure of earnings
figures have to with statements like "they are generating more business"?
do you _want_ to give the impression that Lisp is failing and people who
say they are generating more business are lying because you can't verify
it through public earnings earnings figures, or does it just look that
way? considering your attitude, your signature quote has added meaning.
Paolo Amoroso
> Although the need to update the interface actually lengthened the time
> needed to compile the project, seeing the number of lines incrementing
> faster than could be read gave the impression of great speed.
Bruce Tognazzini's Web site http://www.asktog.com/ discusses similar
interesting user interface design issues.
charliew
R. Matthew Emerson wrote in message <87vhd7i...@nightfly.apk.net>...
>"Jonathan" <jona...@meanwhile.freeserve.co.uk> writes:
>[...]
>> So far it's Lisp semantics that have impressed me (dynamic typing,
>> associative arrays, closures.) I find its S-expression syntax fun to
write,
>> but it hasn't grabbed me in the same way. At the moment it's something
>> that's fun, that I have to learn to get the semantic advantages of Lisp,
but
>> which I don't really see the benefits of.
>
(big cut)
>Lisp just doesn't have much syntactic structure. I've found a comment
>in the preface of SICP to be true: with Lisp, since there is hardly
>any syntax, you just forget about it and get on with the business of
>programming.
This is one of the things that I most like about Lisp. Due to this lack of
syntax, I can easily formulate function definitions that conform to the
problem at hand, rather than worry about how to formulate the problem to
conform to the demands of the programming language that I am using. Thus,
even if Lisp does suffer from a lack of speed (which I don't happen to
believe), I tend to make up for this by being very much faster at
programming and debugging the problem at hand. From a "global" perspective,
the few minutes of increased run time compared to other languages (if this
effect actually exists) are far more than offset by the several hours of
time I saved in writing the program.
Just my $0.02 worth!
Raymond Toy
Michael> No, judging from my experience with amazon.de they have
Michael> no problem at all getting US books. I hope this works out
Michael> for "On Lisp", too...
Unfortunately, I understand that "On Lisp" may be out of print[1], so
getting a copy may be hard....
Ray
Footnotes:
[1] Mentioned in this group a year or two ago, shortly after I bought
my own copy. :-)
Stig E. Sandų
>>>>>> "Michael" == Michael Schuerig <schu...@acm.org> writes:
>
>
> Michael> No, judging from my experience with amazon.de they have
> Michael> no problem at all getting US books. I hope this works out
> Michael> for "On Lisp", too...
>
>Unfortunately, I understand that "On Lisp" may be out of print[1], so
>getting a copy may be hard....
I got mine a few weeks ago. Ordered at the local bookshop and despite
a delay it came in one piece and is imho at least as mind-blowing as
Coplien's "Advanced C++ Programming Styles and Idioms" is to C++. Setting
ones time-system to separate clearly before reading "On Lisp" and after
reading it, is quite appropriate to me :)
--
------------------------------------------------------------------
Stig Erik Sandø Institute of Art History, UiB Norway
Hartmann Schaffer
Raymond Toy <t...@rtp.ericsson.se> writes:
>>>>>> "Michael" == Michael Schuerig <schu...@acm.org> writes:
>
>
> Michael> No, judging from my experience with amazon.de they have
> Michael> no problem at all getting US books. I hope this works out
> Michael> for "On Lisp", too...
>
> Unfortunately, I understand that "On Lisp" may be out of print[1], so
> getting a copy may be hard....
That's what I was told here when I was asking. It turned out that I had
no problems getting it (Chapters; I don't know whether they sell
outside Canada, but I don't see why other bookstores can't get it when
they can)
Hartmann Schaffer
Paolo Amoroso
> Unfortunately, I understand that "On Lisp" may be out of print[1], so
> getting a copy may be hard....
[...]
> Footnotes:
> [1] Mentioned in this group a year or two ago, shortly after I bought
> my own copy. :-)
Last week end I ordered "On Lisp" from Amazon.com (USA). I've just received
their confirmation message informing me that the order has been shipped
(the book was classified as "usually ships within 24 hours"). A few months
ago Graham told me that the book was still available at Amazon.com.
I hope that print on demand will make it less cumbersome to purchase
interesting but hard to find technical books.