
How I lost my faith (in Lisp) - bootload
http://groups.google.com/group/comp.lang.lisp/msg/6f75cfb5a289d3f6
======
pg
Without being able to see this code that was easier to write in Python than
Lisp it's impossible to say for sure, but it seems likely that the
differentiating factor was libraries, not the core language.

~~~
cstejerean
Lisp code is written to be easily parsed and manipulated by software. Python
is written to be easily parsed and manipulated by humans.

When I first came to Python I didn't need to become an expert Python
programmer to understand Python source code without much effort. But I still
haven't gotten to the point of looking at a piece of Lisp code and right away
having an idea of what it does. Eventually your brain recognizes the patterns
(but heck if you write assembly long enough you start to see the patters of
common C control structures).

But I think it all depends on the problem at hand. Certain things I can write
faster in Java than Python (occasionally static typing and interfaces can make
large programs easier to keep in one's head and work with). Most things I can
write easier in Python. And a few things I can write easier in Lisp (primarily
writing programs that manipulate trees and essentially create mini-languages).

~~~
curi
in lisp you write trees.

in other languages, you write weird things that get turned into trees,
seemingly by magic.

other languages _seem_ easier to understand, to most people. this is because
they have a lot of experience with all that magic -- it has become a
tradition. if you're better at normal languages, go ahead and use them. i
don't care. but they are not objectively easier to read, they are much harder
and more complicated.

~~~
greendestiny
Yeah I know the lisp trees thing is something that gets said a lot, but I
really don't see how inexplicable the transformation of other languages into
trees is. Ultimately in lisp you have the most flexibility in manipulating the
tree, but a little study in compilers and formal languages and its obvious
that all languages are describing trees.

Objectively easier to read? Thats a strange road to go down. Theres no reason
that languages with grammars that generate strange and wacky trees might not
suit a human's ability to describe formal solutions better. I think the reason
people find languages like C easier to understand is all in the state handling
anyway.

~~~
curi
the reason people put so much state and local variables in their program is
that non-lisp languages get hard to read if you nest a lot, so they have to.

and that is basically what i mean about lisp being objectively easier to read:
the notation actually works better. so you can nest a lot and it doesn't get
horrible. but also, you don't have to, and then it's about the same.

~~~
curi
BTW, tell me which of these makes more sense:

(+ 3 4 (- 1 (/ 3 4)) (* (- 9 2) 8 3))

+(3 4 -(1 /(3 4)) *(-(9 2) 8 3))

why oh why would you want a function to be in the same grouping (set of paren)
with arguments to another function, instead of grouped with its own arguments?

the less you nest, the less it matters. but it is not a matter of taste which
way makes more sense and scales better.

~~~
WilliamLP
I know I'm not as smart as you guys, but I very strongly prefer 3 + 4 + (1 -
3/4) + ((9-2) * 8 * 3)

If you code Lisp long enough does your first expression becomes as natural to
read as my expression is for me?

~~~
anamax
I note that infix was so natural that you resorted to parens.

Infix looks reasonable until one has more than 2 operators. Then people start
making mistakes. To combat those mistakes, they start parenthesizing. The
number of mistakes goes down but there's still confusion. (Some folks know
more precedence levels than others and many folks think that they know
precedence levels that they don't know.)

~~~
WilliamLP
Another way to put that is that Lisp is so natural it resorts to forcing
parens everywhere even when I don't want them! I'd never deny that confusion
about order of operations between &, |, ==, <<, %, and so on, is a major
source of bugs. (But I'd blame poor coding style for that, in any language, in
the first place.)

However, in every field besides this niche of computer science, including
almost all of math, finance, science, and engineering, infix is used. This
means that it is at least good enough and I suspect it has advantages.

Many math operations really are just fundamentally unary or binary.
Generalizing - or / or x^y or mod to lists is just silly as far as I can see,
and adds confusion. I don't need to see parens around the outermost operation.
For the two most common associative operations, + and *, order of operations
is quite good enough and it has the advantage that everyone since grade 6 has
been working with it.

(I'll give you that there are very many cases where list notation is great,
but I don't think it's common that they help very much in science, business,
or engineering.)

~~~
anamax
> However, in every field besides this niche of computer science, including
> almost all of math, finance, science, and engineering, infix is used.

The reason is that the "reader" in all of those domains is another human and
humans do error correction almost without thinking.

Also, each of those domains has a very small number of operators - programming
languages have lots of operators.

Feel free to demonstrate that you know the precedence/associativity rules for
your favorite programming language by typing them without looking them up. (I
know two people who can do that for C; the vast majority can't.)

~~~
WilliamLP
I'm only trying to defend a very narrow point, that when coding mathematical
expressions, infix isn't bad.

Code is read by human beings too (perhaps just the person who wrote it) and
more find infix arithmetic more natural looking.

I see the appeal in the idea that arithmetic is really just a very special
case of a programming structure and should be treated as such, but on the
other hand, I and many others can instantly see what a + b _c/d - d_ (e+f)*g
means and would like equation-heavy pieces of my programs to somewhat resemble
equations everywhere else in life.

Does you have the quadratic formula memorized in list notation? How about the
sum of an arithmetic or geometric series, or a formula for an inverse square
law force?

~~~
anamax
> I'm only trying to defend a very narrow point, that when coding mathematical
> expressions, infix isn't bad.

Programming isn't math.

> Code is read by human beings too (perhaps just the person who wrote it) and
> more find infix arithmetic more natural looking.

And that's how infix causes bugs. The human reader error corrects and the
compiler doesn't.

My goal is correct programs. What's yours?

Lisp notation eliminates a whole class of bugs.

Bugs are expensive - what are you getting for the ability to have more of
them?

> I and many others can instantly see what a + bc/d - d(e+f)*g means

Really? It has at least two meanings. Which one is correct?

Yes, I do memorize formulas in a form that doesn't allow for
precedence/associativity errors. Why I should prefer a form that does allow
for such errors?

~~~
WilliamLP
Programming isn't math, but mathematical expressions are often found in
programs, more or less so depending on the domain. My preference is to have
readable mathematical expressions in programs that resemble the forms in which
I see or use them elsewhere.

In the general case of complex logical and bitwise expressions, order of
operations can cause a tremendous number of bugs. I like to use parentheses to
make these cases absolutely unambiguous anyway. But I can't remember
introducing a serious bug because I messed up order of operations between +-
and X. Anyway, if it's such a problem, there's nothing to say you can't put
parentheses around every operation in infix notation, at least in any language
that I know of!

Maybe my preference relates to having a fairly visual memory for formulas and
such. If I want to find a root of a quadratic equation, I do (-b + sqrt(b * b
- 4 * a * c))/(2 * a), and that is easy, and anyone with high school math sees
that in someone's code they know what it is. (I probably have to check for a
zero denominator and also look at the discriminant unless I'm directly using
complex numbers, and there's also the conjugate root, but that doesn't change
much.)

If I have to write (/ (+ (- b) (sqrt (- (* b b) (* 4 a c)))) (* 2 a)) then I
can do it, but it takes a lot of thought and it doesn't go along with the way
I think about the quadratic formula. Granted, this is because I learned it the
way I did, but I also know I'm not the only one.

A footnote to that is that to my mathematical sensibilities, in list notation,
using the same symbol for negation and subtraction is hideous!

~~~
anamax
> Anyway, if it's such a problem, there's nothing to say you can't put
> parentheses around every operation in infix notation, at least in any
> language that I know of!

Most of us have to read code written by other people. Those other people don't
have exactly the same precedence defense habits that we do.

No, we don't have to end up in the nasty middle ground where the
paretheization is inconsistent and buggy, but we do. Since the "infix is good"
theories and argument predict otherwise, how much weight should we give them?

------
anaphoric
Funny. I read this piece and was waiting for the profound statement that was
going to convince me. But at the end it sounded like the message was "Google
guys and gals are productive in other languages than LISP". Huh!? Not very
convincing... Why do I care about them? From my point of view it's me and the
machine. Google is just some company.

C is beautiful for what it is. Pure. Running on the metal.

And LISP too is beautiful for what it is. Running on abstractions.

The rest are all kind of in between.

~~~
brent
I'd say that the conclusion (I came to) wasn't just that googlers were more
efficient with other languages, but that after that many years of lisp he's
already more efficient with python.

------
mhartl
For those who missed the context of this post, its author is the same Ron
Garret who recently wrote "My take on Arc"
(<http://rondam.blogspot.com/2008/01/my-take-on-arc.html>, posted on Hacker
News at <http://news.ycombinator.com/item?id=107623>). Those who noticed the
name of this post's author, Erann Gat, could easily be confused: he changed
his name to Ron Garret several years ago (<http://www.flownet.com/ron/eg-rg-
faq.html>).

------
JesseAldridge
Augh, all that teasing and no meat. I want to know specifically why the author
thought Python was better than Lisp.

~~~
lisper
For the record, I did not submit this article, and specifically declined a
request to do so. It's not that I don't stand by what I wrote (I do) but it
was written for a specific audience at a specific time and I don't think it
deserves the attention that it's getting now.

~~~
kirubakaran
How about if we _request_ you to give us some real examples? Please... Pretty
please... :)

~~~
akkartik
Or you could write an update for this new audience you've suddenly found.

~~~
lisper
Working on it.

~~~
akkartik
I noticed. [http://rondam.blogspot.com/2008/02/what-are-programming-
lang...](http://rondam.blogspot.com/2008/02/what-are-programming-languages-
for.html)

Thanks.

------
bootload
_"... So I can't really go into many specifics about what happened at Google
because of confidentiality, but the upshot was this: I saw, pretty much for
the first time in my life, people being as productive and more in other
languages as I was in Lisp. What's more, once I got knocked off my high horse
(they had to knock me more than once -- if anyone from Google is reading this,
I'm sorry) and actually bothered to really study some of these other languges
I found #myself# suddenly becoming more productive in other languages than I
was in Lisp. For example, my language of choice for doing Web development now
is Python. ..."_

This was written in 2002FEB and pre-dates the reddit rewrite from lisp to
python.

------
stcredzero
Sounds like he's lost his faith in Lisp uber-alles, but not necessarily in
high-level languages or dynamic languages.

