Oddly enough, I can't tell. It seems to be a portrait expressed in terms of the broken reinventions of the Lisp wheel that currently occupy the median programmer's head. Sort of like describing a car as a "horseless carriage." But since I don't know those reinventions well, I can't say if this is an accurate portrait.
For example, someone recently told me that in Python you can't have conditionals within math expressions. E.g. you can say the equiv of
(if foo (+ x 1) (+ x 2))
but not
(+ x (if foo 1 2))
To me this just seems gratuitously restrictive. But I
suppose it would at least be an accurate, if rather long,
description of Lisp to teach people Python, and then say
e.g. "Ok, now imagine if you could also just put any
expression anywhere." Plus a few other things, of course...
"For example, someone recently told me that in Python you can't have conditionals within math expressions."
You can, but until Python 2.5 you needed to use a somewhat opaque idiom:
x + (foo and 1 or 2)
This works because the short-circuiting boolean operators return their second operand. So if foo is true, it'll evaluate 1, find that it's true, and return 1. If foo is false, it short-circuits over the 1, evaluates the 2, finds that that is a true value, and so returns 2. It's not intuitive at all, but most serious Pythonistas are familiar with it.
I agree that this is gratuitously restrictive, and evidently the Python developers did too. As of Python 2.5, you can do this:
x + (1 if foo else 2)
It's a shame that it took so long for them to add it, though.
Thanks very much for your response. I don't think it's odd because this article (even with it's length) would probably benefit people coming from entirely different environments. They might know something about programming but need some help grasping the fundamental differences between writing programs in say C# vs. Lisp or Python.
Oddly enough, after reading his article and letting is sink in a little bit more, I was able to understand your writing better. That's no fault of yours, I just think it's a little bit of a shortcut to getting over that initial confusion.
I think the article does a good job of conveying what Lisp is to someone who just can't get it. I agree, however, that it is a bit on the verbose side. I think that at least a third of the text could have been removed without taking out any content. Heck, some of the content could have probably been removed without taking away from the point the author is trying to convey.
To make the analogy even more succinct, I will first ask you a different question. Have you switched to Firefox? It wasn't long ago that I went from using IE6 to using Firefox. Before too long, between tabs, quick searches, customizable toolbars, incremental page search, and more, I found myself saying, "Wow, this is what browsing should be. How did I ever use IE?" Lisp is the same way.
I disagree with the article's conclusion, "Learning Lisp is an uphill battle." If you have a good reference, it is not hard to start programming in Lisp. You could learn Lisp by writing trivial code in about the same amount of time it would take to learn C or Java. In fact, your code would probably be structured in much the same way. Once you've learned enough Lisp, however, and once you get to the chapter on macros (of whatever Lisp reference you're using), something will click. Then you will realize that you have been programming all wrong all along, and you will instantly rewrite everything you've ever done in one red-eyed night. The next morning, you will be reborn.
But seriously, if you really want to learn Lisp, drop the $40 (or whatever it costs at the moment) on ANSI Common Lisp; it's a great read. Once you plow through that and are hungry for more, look for On Lisp or Practical Common Lisp; both of them are available online.
If it wasn't for my classes with their requirements to program in C++ or Java, I never would have looked back after learning Lisp. I think any good programmer who gives Lisp an honest try will feel the same way.
The Java language is so verbose that its programmers can tolerate hand-editing XML files for builds. This perhaps points out that it is not the parens that are holding back lisp. Maybe to test this someone should make XMLLisp where every expression is angle bracketed instead of parensed.
Being primarily a microsoft developer, I'm probably in the minority here. My coworker and I have been talking about branching out and learning completely different languages to stay fresh and learn some different views.
It took me 3 read throughs of this article to begin to get a sense of what makes people rave about LISP. I've also read Chapter 2 of PG's book. From what I can see, I like.
I'm not saying I'm a convert (yet!) but I absolutely plan on reading Paul's book and working through the examples and excercises there.
In the meantime, is the article a good way to think about Lisp?
The article is too long and not that well written. The biggest problem is that, however good the writer they are never going to be able to communicate the power of lisp in prose. It's upto the audience to see it. For those who know lisp, they already know. For those who don't it's like coming in contact with something alien and you can't tell if it solves any problem at all. It's almost as if ones' come in contact with a cult.
Though lisp provides a lot of syntactic flexibility. The beauty of lisp is in giving the programmer confidence that you can create a prototype extremely quickly and then optimize it when needed.
I find the hardest thing in the world is getting started. Once I start its never as hard as I thought it was going to be. In a nutshell, Lisp helps me get started and then lets me get the code ready for prime time.
If you are a web developer, I'd say spend a weekend trying out UCW, write a reddit clone in it. Then try to write it in python. It'll be obvious what lisp has to offer.
I'd start by reading SICP by Sussman and Abelson. Their lectures are available in video. I had a profound experience at the end of lecture 2b where they explain how car, cdr and cons are defined, thus explaining that in lisp, code is data.
The above comes with a warning... Lisp is truely the red pill. Once you've figured it out, you'll find it physically impossible to code in any other language.
I've never been afraid of the red pill. If it'll improve my ability to be effective, I'll gladly take it. :)
Without knowing much about Lisp, it seems that trying to describe it is like to trying to tell someone about Buddhism, or Jazz. Talking about it is just not the same thing as "getting it".
Thanks for your thoughts vikram, If I do become a convert I'll be sure to make a special post to news.yc :)
If you have Lisp, you don't need the plethora of XML mini-languages you need in Java and many other languages. You can just keep everything Lisp, and give up nothing in flexibility and still succintly express ideas in your problem domain.
This is what is often referred to as "Domain Specific Languages". With Lisp, you can create a DSL and its still Lisp.
That is what the article is saying, but much more verbosely. In the article's defense, I think it takes something as long as that for people who don't know Lisp to really understand the point.
I came away from it thinking "Okay, yeah, I already knew that much. What's this nirvana you're talking about?" I suspect I'm not the only one who has been exposed to lisp but hasn't really comprehended it. This article did little to convince me or help me along the path to lisp enlightenment.
For example, someone recently told me that in Python you can't have conditionals within math expressions. E.g. you can say the equiv of
(if foo (+ x 1) (+ x 2))
but not
(+ x (if foo 1 2))
To me this just seems gratuitously restrictive. But I suppose it would at least be an accurate, if rather long, description of Lisp to teach people Python, and then say e.g. "Ok, now imagine if you could also just put any expression anywhere." Plus a few other things, of course...