A few weeks ago I posted a question asking experienced Lisp programmers what
the advantages of Lisp's (very non-standard) prefix syntax are. At that time
I was learning Lisp in spare bits of time left over from other (C++ based)
work and loved the other things about it - the dynamic typing, macros,
closures, etc, but still found it rather odd to have say :
(setq a (+ b c))
instead of
a = b + c;
I didn't doubt my ability to write code this way, but I wondered whether it
had any compensating advantages. Lost of people pointed out the support this
syntax offers for automatic program generation and text editing. But I
thought it might be useful for anyone thinking of learning Lisp and
following the group, or perhaps searching on DejaNews, to have this
follow-up posting to read:
Prefix syntax is great. I now really miss having it in C++. Although it
looks a little over-complex in simple examples like the one above, it has
the vast advantage of never being ambiguous, and never being dependent on
anything like C++'s complex and implementation dependent precedence
hierarchy. You use a lot of parentheses in Lisp, but you can mostly ignore
them and read by the indenting. Whereas in C++, where parens are
disambiguators, you have to read them very carefully. I've seen this be a
major source of bugs for people, and it's a major hazard in porting and code
maintenance (there's no guarantee that even the same vendor will keep the
same precendence hierarchy forever outside of the relationships defined by
the ansi standard).
Lisp syntax also benefits from having optional keyword parameters, a
simplified flow of control that comes from dynamic typing and from being
able to provide multiple return values - so the same function for equation
solving can return floats or complex numbers or a nil value, indicating that
no valid answer exists, as the need is - if that's what you want.
Most importantly of all, Lisp has the ability to describe conceptual
structures more succinctly than C++. I know C++ has an outstanding ability
to enrich itself with new datatypes: Lisp can match it, but also has the
ability to enrich its semantics. C++ is like a language in which there can
only be new nouns: Lisp has first-rate support for adding nouns and verbs! A
new datatype is not the solution to every problem. (I'm not saying that C++
can provide other programming paradigms, but its support for them is very
weak, just as C allows OO, through manually created vtables etc, but only
weakly suports it. Similarly a cunning C++ programmer can code verbs as
strategy classes or functors, etc, but they're clumsy, expensive, fragile
and unsubtle things compared to the genuine article.)
Paul Graham's books are full of fairly serious example code - raytracers,
parsers - and although the code is almost comment free I can already read it
quite comfortably.
I might still discover reasons not to use Lisp - but it's syntax won't be
one of them. (I note a seeming lack of libraries compared to some
langauges - I need to use OpenGL under NT and haven't seen anything suitable
yet. I'm also worried about the price of compilers, which varies from a
little pricey to hugely expensive comapred to what I'm used to paying - I'm
especially affected by my need for a compiler that will produce standalone
exes with Fortran or C level floating point performance.) But the syntax is
great. Paul Graham's excellent books are full of fairly serious examples -
raytracers, parsers - and although the code is almost comment free I can
already read it quite comfortably. For non-trivial applications, I'd say
that Lisp produces the most readable code of any language I've ever seen. If
you're thinking of learning Lisp, I think you should count on feeling
comfortable with the syntax pretty quickly.
Jonathan Coupe
Jonathan -
If you're looking for a decent, but cheap, compiler for Windows apps, check
out www.corman.net
and Corman Lisp. Roger has a pretty complete implementation (he's still
working on a few things, but the code is fairly efficient - at least it's
efficient enough for me, it has a good native Win32 API I/F, and it's
inexpensive).
faa
Jonathan <········@meanwhile.freeserve.co.uk> wrote in message
·················@news7.svr.pol.co.uk...
> A few weeks ago I posted a question asking experienced Lisp programmers
what
> the advantages of Lisp's (very non-standard) prefix syntax are. At that
time
> I was learning Lisp in spare bits of time left over from other (C based)
> work and loved the other things about it - the dynamic typing, macros,
> closures, etc, but still found it rather odd to have say :
>
> (setq a ( b c))
>
> instead of
>
> a = b c;
>
> I didn't doubt my ability to write code this way, but I wondered whether
it
> had any compensating advantages. Lost of people pointed out the support
this
> syntax offers for automatic program generation and text editing. But I
> thought it might be useful for anyone thinking of learning Lisp and
> following the group, or perhaps searching on DejaNews, to have this
> follow-up posting to read:
>
> Prefix syntax is great. I now really miss having it in C. Although it
> looks a little over-complex in simple examples like the one above, it has
> the vast advantage of never being ambiguous, and never being dependent on
> anything like C's complex and implementation dependent precedence
> hierarchy. You use a lot of parentheses in Lisp, but you can mostly ignore
> them and read by the indenting. Whereas in C, where parens are
> disambiguators, you have to read them very carefully. I've seen this be a
> major source of bugs for people, and it's a major hazard in porting and
code
> maintenance (there's no guarantee that even the same vendor will keep the
> same precendence hierarchy forever outside of the relationships defined by
> the ansi standard).
>
> Lisp syntax also benefits from having optional keyword parameters, a
> simplified flow of control that comes from dynamic typing and from being
> able to provide multiple return values - so the same function for equation
> solving can return floats or complex numbers or a nil value, indicating
that
> no valid answer exists, as the need is - if that's what you want.
>
> Most importantly of all, Lisp has the ability to describe conceptual
> structures more succinctly than C. I know C has an outstanding ability
> to enrich itself with new datatypes: Lisp can match it, but also has the
> ability to enrich its semantics. C is like a language in which there can
> only be new nouns: Lisp has first-rate support for adding nouns and verbs!
A
> new datatype is not the solution to every problem. (I'm not saying that C
> can provide other programming paradigms, but its support for them is very
> weak, just as C allows OO, through manually created vtables etc, but only
> weakly suports it. Similarly a cunning C programmer can code verbs as
> strategy classes or functors, etc, but they're clumsy, expensive, fragile
> and unsubtle things compared to the genuine article.)
>
> Paul Graham's books are full of fairly serious example code - raytracers,
> parsers - and although the code is almost comment free I can already read
it
> quite comfortably.
>
> I might still discover reasons not to use Lisp - but it's syntax won't be
> one of them. (I note a seeming lack of libraries compared to some
> langauges - I need to use OpenGL under NT and haven't seen anything
suitable
> yet. I'm also worried about the price of compilers, which varies from a
> little pricey to hugely expensive comapred to what I'm used to paying -
I'm
> especially affected by my need for a compiler that will produce standalone
> exes with Fortran or C level floating point performance.) But the syntax
is
> great. Paul Graham's excellent books are full of fairly serious examples -
> raytracers, parsers - and although the code is almost comment free I can
> already read it quite comfortably. For non-trivial applications, I'd say
> that Lisp produces the most readable code of any language I've ever seen.
If
> you're thinking of learning Lisp, I think you should count on feeling
> comfortable with the syntax pretty quickly.
>
> Jonathan Coupe
>
>
>
>
>
>
Frank A. Adrian wrote in message
<·······················@news.uswest.net>...
>Jonathan -
>
>If you're looking for a decent, but cheap, compiler for Windows apps, check
>out www.corman.net
>and Corman Lisp. Roger has a pretty complete implementation (he's still
>working on a few things, but the code is fairly efficient - at least it's
>efficient enough for me, it has a good native Win32 API I/F, and it's
>inexpensive).
>
>faa
>
That's *very* interesting. My impression from DejaNews searches was that
Corman Lisp wasn't ready for commercial use, but of course things can change
very fast and those posts might have been a couple of years old.
Buying a Lisp compiler seems a real pain, to be honest:
The prices can be very high (I have a suspicion that Allegro quoted me for a
complier with more features than I need though - their top of the range
Enterprise, when a Professional with an add-on profiler and runtime might
be enough; this could bring the bill down a lot.)
It's very hard to know where to go for reliable independent information.
Lisp benchmarks are extremely difficult to interpret. I'm already aware that
Lisp efficiency tuning is very implementation specific (how often I have to
type that phrase; how much I hate it) so that a benchmark often reflects how
well tuned the implementation was for a compiler rather than the compiler's
real capability compared to its rivals - cons'ing, GC in general, and the
correct use of type information seem to be real problems here.(?) So you've
really got to get to know a complier before you can benchmark it correctly!
(And we really need speed for this app, otherwise it probably get written in
Python.) For our purposes, John Watton's point inside a polygon test and the
Lisp Team's decision tree generation benchmark both look very suitable - we
need to do a lot floating point t3D geometry, and we generate trees. If
anyone's ever tuned either of these benchmarks for a compiler, especially
Harlequin - the originals were written for Allegro - I'd love to hear from
you.
Jonathan Coupe.
From: Erik Naggum
Subject: Re: Follow up to "New To Lisp: Advantages of Lisp syntax"
Date:
Message-ID: <3138961746451885@naggum.no>
* "Jonathan" <········@meanwhile.freeserve.co.uk>
| A few weeks ago I posted a question asking experienced Lisp programmers
| what the advantages of Lisp's (very non-standard) prefix syntax are.
I'm curious why you still use "standard" about syntaxes.
| You use a lot of parentheses in Lisp, but you can mostly ignore them and
| read by the indenting. Whereas in C++, where parens are disambiguators,
| you have to read them very carefully. I've seen this be a major source
| of bugs for people, and it's a major hazard in porting and code
| maintenance (there's no guarantee that even the same vendor will keep the
| same precendence hierarchy forever outside of the relationships defined
| by the ansi standard).
this is an important observation. I mused that parens translate to pain
in Algol-like languages, culminating in C++, and that when people see
parens in Lisp, they _feel_ the excruciating pain from C++. now, we are
not all blessed with growing up with good parens, and psychotic parens
can have a dramatic effect on one's development, but most people realize
that it's the _particular_ parens that are good or bad, not all parens.
welcome to the world of good parens, Jonathan!
#:Erik
--
@1999-07-22T00:37:33Z -- pi billion seconds since the turn of the century
From: Fernando Mato Mira
Subject: Re: Follow up to "New To Lisp: Advantages of Lisp syntax"
Date:
Message-ID: <376E4F93.67584EBC@iname.com>
Jonathan wrote:
>
> langauges - I need to use OpenGL under NT and haven't seen anything suitable
> yet. I'm also worried about the price of compilers, which varies from a
> little pricey to hugely expensive comapred to what I'm used to paying - I'm
On NT, ACL is not much more expensive than all that `Visual' stuff, and you'll
make up several times for the difference really fast.
What's wrong is saying: "To deliver your app you'll have to pay $X royalties".
Even when including the compiler it doesn't make much sense. That's one of the
main reasons to use Lisp! So you can dynamically generate code inside you app
that runs fast! "Royalties only if you want to sell a program intended for
development of standalone apps." That should be the rule.
From: Charles Blair
Subject: Re: Follow up to "New To Lisp: Advantages of Lisp syntax"
Date:
Message-ID: <FDx4ry.Cu2@midway.uchicago.edu>
Jonathan (········@meanwhile.freeserve.co.uk) wrote:
: A few weeks ago I posted a question asking experienced Lisp programmers what
: the advantages of Lisp's (very non-standard) prefix syntax are. At that time
: I was learning Lisp in spare bits of time left over from other (C++ based)
: work and loved the other things about it - the dynamic typing, macros,
: closures, etc, but still found it rather odd to have say :
: (setq a (+ b c))
: instead of
: a = b + c;
what i'm about to add to this thread may seem almost trivial, and i'm
almost embarrassed to say it, but being a manager type these days, it's
what i have to contribute right now.
i use lisp in preference to microsoft excel to administer my budget. for
example, i can define variables such as the following:
; ITEM QUOTE P.O. REC'D
; Server Computer Expenditures
(defvar server (+
630.75 ; enki's 2nd 4.2 gb internal disk: 07/31 08/25 01/26
195.75 ; 2-32MB SIMMs for duras 04/07 04/08 04/28
229.99 ; Back UPS 650 for ninki 04/23 05/03
150.00 ; ScholarPAC w/ compiler support for ninki 04/27 04/27
(* 229.99 4) ; ups's for foo, bar, foobar and baz
[etc.]
))
i can keep creating variables like these for different categories of
expenditures, then do simple two-column bookkeeping by subtracting the
sum total of variables from the funds i have to spend. i can then craft
various statements to format a printed report. so although a = b + c might
seem more "standard," between lisp's prefix notation and its comment
notation, i have a straightforward and eye-legible method of bookeeping
from a unix platform. again, not the most earth-shattering use of lisp,
but one that keeps me happy, not to mention my boss. i use the same
procedure for compiling statistics for my annual report (boring--i know).
i might add that i learnt symbolic logic using prefix notation, which,
though odd at first, quickly became second nature (this notation is of course
by no means peculiar to lisp).
---
Charles Blair
Manager, Digital Library Systems ·······@uchicago.edu
The University of Chicago Library 773.702.8459
Chicago, IL 60637-1502 U.S.A. http://www.lib.uchicago.edu/~chas/