Papers on LISP

Comments on:

McCarthy, J. (1978). History of LISP. ACM SIGPLAN Notices 13(8), pp. 217-223.

Graham, P. (2002). Revenge of the Nerds. Web essay at http://www.paulgraham.com/icad.html (dated May 2002; visited 1 February 2006).

Comments from:

Peter Brown, Michael Claveria, Davis Hart, Alex Leach, Brad Miller (-), Angeline Namai (*), Mark Nettling, Dimitar Tasev, Dave Ventresca.

Lisp is awesome. That is what Graham essentially says throughout this entire reading. He throws in the occassional disclaimer that each task has a tool that works better than another. However, in every example he gives he glorifies Lisp. He states that all lanuage are converging, becoming more list Lisp. His code examples seem biased as well. For instance, when he increments something in Java, he is sure to use all the complicated Java tricks like anonymous inner classes when it seems that he could have written it much simpler. Then again, maybe I do not understand completely what he is trying to achieve, as seems to be his attitude towards people that do not accept Lisp as their programming savior.

First the Revenge of the Nerds article in which i found a few interesting things. The first of which was how the author mentioned that some langueages are better for some things then others, he then goes on to talk mainly about how LISP is so much better then any other language that that with each new language they are getting closer to LISP. Secon thing i found interesting in that article was how some of the most unique features of LISP were not planed, they just appeared when certain design choices were made. As for the History of LISP article I found this one interesting primarily because it discused how LISP evolved from a mathmatical exercise to a compiled language.

Revenge of the Nerds offers a rather interesting perspective on the power of Lisp. Personally, my experience with Lisp is at the lowest level possible, so I find myself unable to comment the most of the information given. However, I am amazed that even nowadays (at least according to Graham), many of the widely used programming languages are far behind Lisp in terms of functionality and simplicity of code. Additionally, I would most certainly disagree that code size should be a benchmark for comparing Lisp to the other programming languages; indeed Lisp programs may be 7x-10x shorter than those of C, but one must also consider that unlike C, which resembles our natural way of expressing ourselves mathematically, Lisp uses a functional approach which some users might not feel comfortable with.

The Graham article makes it sound as though programmers have essentially been duped into using bad languages for the last 40 years, while an elite group of LISP users have been off efficiently producing programs. Perhaps it's just my knee-jerk defense to this attack on the programming profession, but it seems as though LISP isn't ideal for everything. While there have certainly been some projects could have been improved and/or written faster with LISP, I feel that with the increasing use of web applications, sometimes languages such as Java and Perl, which were built for servers and applets, can be used more efficiently. Even if these languages are moving towards LISP with regard to some features, they still have their specific purposes, which are unrelated to LISP. I doubt, as Graham seems to be saying, that all languages will become LISP one day. It is important to point out that there are choices, for as Graham says himself, some languages are better, for certain problems, than others.

Additionally, as we discussed in class, one of the primary goals of programming languages can be to be easily understood by someone with little or no experience in a language. Granted, if everyone taught LISP, more people would be able to read it, but Graham makes it seem as though currently LISP is a much more elite language than say Java and as a result, sharing and collaboration becomes much more difficult, possibly cutting into the massive efficiency boost proposed by Graham.

Lastly, I'm confused about the eval command talked about by McCarthy in terms of why it is critical to LISP and whether other languages now have similar constructs.

The eval command is related to the key idea that Lisp does not distinguish between data and code. When you call eval on an S-expression, that S-expression gets evaluated (typically in the current environment, although there are variations).

One of the justifications Graham gives for his high opinion of LISP is that it was the first programming language to support recursion. McCarthy himself states that recursion was a key idea on which he based the development of LISP. In last week's reading, Sebesta claimed that, in functional language programs, "iterative processes can be specified with recursive function calls, making loops unnecessary" (p. 53), and he seemed to suggest that this support for recursion places functional languages such as LISP ahead of other languages. I was under the impression that iteration is an equally effective alternative to recursion, so I am not sure why the recursive feature makes LISP any more powerful than other languages. Perhaps I did not quite understand what McCarthy means by "the recursive use of conditional expressions" (217), but it would be interesting to find out why loops are undesirable, and what circumstances would lead an experienced programmer to choose a recursive approach over an iterative one.

Mathematicians often find recursion to be a more elegant (and even clearer) way to express repetition. Some find it easier to analyze, but others find it more difficult. Perhaps we'll look at some examples.

It is certainly evident that Paul Graham and John McCarthy are advocates of LISP. But other than that what is the point? Graham brought into light a few important ideas about Software development, namely that choosing difficult problems and powerful, efficient languages to code solutions in was the way to go. However, aside from this and praising LISP, there was little else in his paper. The code comparisons he did were informative, though i'm not entirely convinced that one line of LISP = 20 lines of C...The McCarthy paper, as it is entitled, is a history of LISP. It is certainly strange to think that before LISP many of the attributes of languages that we take for granted today simply did not exist, recursion being the most shocking (I think) example. On another positive note, i have gained a more intimate knowledge of why exactly certain elementals of LISP (Dr. Scheme, anyway) exist/were created/why they are better/etc such as car and cdr, lists, etc. It was also interesting to learn that LISP was never intended as a programming language, but more as an alternative representation of Turing Machines (lambda calculus).

My main point for you doing these readings was for you to see what Graham and McCarthy consider the key features of LISP as compared to other languages.

I think what I found most interesting about the readings was the insistence that less common languages (LISP, Perl and Python to an extent) are much more powerful than the more common Java and C++. While programs can be written much quicker in LISP than in other languages, the amount of support Java and C++ have, as far as things like libraries, seem to diminish the power of LISP over them.

I really found a comment in the last section of "Revenge of the Nerds" (Appendix: Power) interesting. The author mentions that "power is the ultimate elegance." I'm curious as to how easy non-elegant programs are to read, which probably has some bearing as to how often companies would be willing to use LISP or Perl.

Graham's argument that it is the pointy-haired boss who prevents LISP's adoption by industry serves as a classical example of a principal-agent problem. In this argument, the principle - the corporation which attempts to produce and market software applications - is kept from acclaim and profits by the agent - the boss - who is concerned more with selfish matters such as employment longevity than the success of the company. However, I question the validity of this argument because economic theory suggests that in very competitive markets, innovation is a natural byproduct of competition. If Graham is correct with his numbers then use of new and innovative ideas, and efficient languages, especially in the online services market where costs to entry are low and talent is readily available, would necessitate the use of LISP to maintain competitiveness. Why does Google use C and C++ if LISP is so much more efficient? Maybe in a few years Google will learn its lesson if Graham is right.

I'll admit that I don't know what languages Google uses. I do know that Graham had an early and successful business that beat competitors to market because he used Lisp (or so he claims).