How so? Prefix notation reads left-to-right nicely when you are dealing with verbs. Boolean logic is less natural, but also makes up much less of my programs (especially when using functional patterns like predicates, map, reduce, filter, etc.).
I also think that while Boolean expressions in Lisp are less natural than "this AND that OR another", they are clearer when they get large (with good formatting of course).
In English we say 1 + 2 * 3 as "one plus two times three":
1 + 2 * 3
one plus two times three
But in Lisp when read naïvely left-to-right this becomes "times add one two three", which is nonsense in English.
(* (+ 1 2) 3)
times add one two three
Most people cite "lots of brackets" as their reason for disliking s-expressions, but I think the unfamiliar ordering is a less superficial criticism. Of course, for those of us manipulating ASTs they're very natural, because we see language as trees.
People always mention the infix operators, but really, how often do you come across them in your code? Unless you're working on something highly mathematic, it really isn't that big of a deal. Otherwise, sexprs visually are a matter of rearranging parentheses for basic function calls.
Of course 1 + 2 * 3 is more familiar that way, vs the Lisp way. But you have the Lisp way wrong (unless your example was Smalltalk)... it would be:
(+ 1 (* 2 3))
Which could be read left-to-right as "sum 1 and the product of 2 and 3".
Also, most math functions in Lisp are variadic. So if you have this in infix:
x + y + z + 1
// x plus y plus z plus one
You could do it in Lisp as:
(+ x y z 1)
;; sum x y z and one
There are plenty of cases where an algorithm is naturally expressed as a map or a reduce, where infix or prefix has nothing to do with it. I don't find myself using a lot of the kind of math that would be better in infix.
It might even be useful to give math operators new names in Lisp, because of the way that things like < > = == are a bit awkward when read as their equivalents in infix. They are all variadic, after all.
Compare:
(x == 10 && y == 10) && (x < y && y < z && z < 100)
Vs.
(and (== x y 10) (< x y z 100))
That's already an improvement, but the reading is strange. So what if we alias those operators?
(all-true? (same? x y 10) (ascending? x y z 100))
I don't know if I'd actually use those names, and I don't think I would do this in code, but you get the point. You can even tell how a list of numbers is sorted in Lisp by simply doing:
Lisp disappointed a lot of people in the early 2000s. It wasn't ready for a close-up examination by people who cut their teeth on Perl, Python, and Java. All the little inconveniences, the lack of software repos, the lack of organized open-source projects, the attitude that people shouldn't expect to get work done right away, the "why do you need a library for X when you can write it in twenty lines of code?" The Lisp community was pretty satisfied with the way it did things (which I think was more a reasonable attitude than it appeared from the outside) but they were not prepared to explain themselves to a mob of curious people with entirely different expectations for a programming language community.
Erasing that initial bad impression may be a generational thing. Even heroin goes through cycles where a new generation comes along that hasn't seen anyone die of heroin, they make heroin cool for a while, and then the horrifying results inoculate the culture against the idea that heroin is cool for another fifteen or twenty years. Lisp will get another chance, and it can afford to wait.
Also, I think next time around it won't be Lisp, the universal solution. It will be a Lisp. It might not even be called Lisp. It might be called "Clojure" or something odd like that ;-)
Can't get a hold on a blog article from an old lisper expressing his lack of understanding about the so-called lisp library problem. It was a clear summary of the fallacy.
More and more I hear people 'they've been doing this in lisp all along' so I make a naive guess that in the future lisp genes will reappear in more favorable settings and won't get dismissed as they were before. It's already happening as for gc's and closure right ?
