

Kent M. Pitman Answers On Lisp And Much More - udzinari
http://slashdot.org/developers/01/11/03/1726251.shtml

======
gjm11
Very good stuff, but note that it's from 2001.

(Kent Pitman was involved in the ANSI CL standardization process, was the lead
author for the standard itself, and created the HyperSpec --
[http://www.lispworks.com/documentation/HyperSpec/Front/index...](http://www.lispworks.com/documentation/HyperSpec/Front/index.htm)
\-- which is possibly the best programming language standard document ever.)

------
gjm11
KMP's answers to the Slashdot questions were very long, so they split them
into two parts. There doesn't appear to be a link from the first part (which
is the thing linked here) to the second part, so here is one:
[http://developers.slashdot.org/article.pl?sid=01/11/13/04202...](http://developers.slashdot.org/article.pl?sid=01/11/13/0420226)

------
hvs
The questions from people that have obviously never used Lisp haven't changed
in 50 years.. "Why all the parenthesis" "Lisp is too arcane" etc. I can't be
too hard on them, I used to think the same thing. But once you make a
commitment to actually learn the language (just like any other language), you
find a beautiful language that allows you to write very compact code with a
minimum of boilerplate.

I'm constantly amazed at how many ideas that Lisp came up with years ago that
are just now starting to gain wider acceptance in more mainstream languages.
It's unfortunate that superficial complaints about syntax prevent so many
developers from giving this language a chance.

~~~
gfodor
Arguably having slightly unfamiliar syntax that has long term benefits (like
lisp's parens) provides an excellent filter against programmers who you really
_don't_ want in your community, anyway. I find that people who obsess over
syntax are often the ones who know the least about programming and computer
science in general.

That said, some syntax choices are horrifically bad, and make simple things
hard. But lisp's parens are not an example of this, just the opposite.

------
cageface
I've always very much admired the elegant simplicity of Lisp and Scheme. I've
done a bit of CL and, lately, Clojure hacking and I do think that learning
Lisp is an enlightenment that no good programmer should deny himself.

However, I'm also less and less convinced that the one really killer feature
that Lisp allows, macros, really makes up for the downsides of the s-expr
syntax. Modern languages with closures and first-class functions and easy,
powerful metaprogramming facilities give you enough flexibility without macros
and history has shown that s-expr prefix notation is just not something that
many people enjoy.

A previous poster's claim that Lisp makes a good extension language because
it's scriptable is a good case in point. Dealing with the s-expr syntax in a
capable editor like Emacs isn't a problem but entering complex, ad-hoc s-expr
expressions on a command line is just gross. I'd _much_ rather use something
like Python or Ruby or Lua for that purpose.

I'm not sure that any of the existing statically typed, type inferencing
languages have really found the sweet spot yet but, as much as I enjoy the
current crop of dynamic languages, I'm still much more inclined to believe
that the next step in the evolution of highly productive languages is going to
involve reintroducing static typing in a less cumbersome way, not revisiting
the Lisp paradigm in a new context. When I look at the work that the Rails 3
team is doing to clean up and modularize the Rails internals I just have to
think that their task would be much easier in a language with explicit, static
support for interfaces.

~~~
anonjon
_However, I'm also less and less convinced that the one really killer feature
that Lisp allows, macros, really makes up for the downsides of the s-expr
syntax._

Sorry, what is the downside? (foo x) vs. foo(x) doesn't make a difference to
me.

Is this an implied downside that amounts to not having used the language very
much?

~~~
cageface
There are two downsides. First, lisp syntax requires a lot more parentheses
because every expression must be parenthesized. Infix languages eliminate most
of these. Admittedly this also occasionally introduces some problems with
operator precedence but in practice these aren't that big of a deal. S-expr
syntax just isn't as readable.

Second, prefix notation is terrible for complex arithmetic. Even the most
ardent admirers of s-expr syntax will concede this.

I certainly haven't done as much lisp hacking as some people but I've written
a complete html-mail archiver: <http://github.com/cageface/macho>

a standalone xml parser: <http://github.com/cageface/xmls>

and an s-expr syntax for python: <http://github.com/cageface/lython>

So I think I'm entitled to an opinion.

~~~
anonjon
_Infix languages eliminate most of these._

No, they don't.

They eliminate some of them, mostly ones associated with math. The rest of
them they replace with different types of parenthesis.

Brackets, braces, tabbing and carriage returns, semicolons. They are all
structure delimiters. In lisp you have one structure delimiter "()", in non-
lisps you have many.

I don't see how it is terrible for complex arithmetic. Lisp order of
operations is explicit. Code does not become more clear because you add a
bunch of implicitly defined structure, (no matter how much you were drilled in
math school, it is still another thing to remember). Besides, what makes math
different from anything else? I end up parenthesizing infix math anyway,
simply because it is hard to keep track of the order of operations.

You are certainly entitled to your opinion, and I didn't meant to imply that
you aren't, I was just interested in your reasoning.

To me, 'readability' is a vacuous claim, being that they only thing that
'readability' really means is 'what I am used to'. (I write lisp code for a
living, am used to lisp code (lisp was my first language), and I find it much
easier to decipher than other languages).

~~~
cageface
The great thing about using a variety of different structure delimiters
instead of one is that they delimit different kinds of structure and make
those delimitations more clear and explicit. Real Lisp code makes liberal use
of redundant whitespace to indicate structure for similar reasons. In fact, a
lot of Lispers will tell you they don't even see the parentheses after a
while. If this is really so, why not just eliminate them and use Python
instead? You lose macros but gain a lot of syntactic clarity.

As for arithmetic, most people will find this: (/ (+ (- b) (sqrt (- (* b b) (*
4 a c)))) (* 2 a))

less readable than this: (-b + sqrt(b * b - 4 * a * c)) / 2 *a

It may be that readability is relative but those that find prefix notation
more readable in general have been in the minority since Lisp was first
invented.

------
dkarl
_Further, the package system is missing certain kinds of inheritance
capabilities I've often wished for, but I recently sat down and did the work
of writing my own versions of defpackage for my own use, adding the
capabilities I wanted in a way that my own tools can use, and I had no
difficulty._

A tendency of all Lisp gurus is to shrug off the lack of any facility that
they can easily write themselves. Where is this new defpackage? Is it
documented? Does it work for anybody else's needs, or just his? Is it even
available? The fact that he considered these issues to be not worth mentioning
in the context of the question is really frustrating.

 _For the most part, I've found the limitations of Common Lisp's abstraction
capabilites to be incidental, and not deep, and I've found its syntactic
reorganization capabilities more than capable of making up for it._

For most development there's no level of language power that makes up for
being able to build 95% of your environment and 90% of your code by
downloading tools and libraries used by thousands of other people, instead of
(say) 80% and 70%.

