>>52
What I am saying is that Lisp is not necessarily S-exprs. Lisp is a certain way of doing things, among which homoiconicity and macros. But the surface syntax does not have to be S-expressions and I would argue that it could still be called Lisp, as long as there is an obvious and trivial mapping to a S-expressions-based Lisp. I agree with you, rejecting everything that Lisp brings just because of its surface syntax is a tad bit silly. But there's more than one way to get past it, and it doesn't have to be "well just get used to it".
People rejecting functional programming
With a few exceptions, Lisp allows side effects (but indeed encourages functional programming). Implicit parallelization does
not require purely functional programming style all throughout the language; the compiler must merely prove that a particular time-consuming function is pure, regardless of whatever impure things it does inside. Functional programming is nice, but sometimes it's cumbersome not to just write things out imperatively. I can't imagine writing a codec or a cryptographic library in purely functional style. It's obviously possible (by Turing equivalence), but sometimes you just want to
a[i] += f(x,y,z). Yes, 98% of my functions *are* pure functions (possibly containing impure things like multiple assignments to the same variable), and the remaining 2% will probably be I/O and the likes.
So no, I don't see the point of forcing upon the user S-expressions nor purely functional programming.