Kent M. Pitman Answers On Lisp And Much More | Hacker News Reader

Kent M. Pitman Answers On Lisp And Much More

slashdot.org

14 pointsudzinari10 comments

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... -- which is possibly the best programming language standard document ever.)

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...

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.

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.

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.

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?

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.

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).

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.

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%.

Reply on news.ycombinator.com