Thinking in Lisp

SQL, Lisp, and Haskell are the only programming languages that I've seen where one spends more time thinking than typing.
That's because it takes forever to think of the solution in Lisp and Haskell as opposed to a decent language. Faggot lispers will spend most of their time figuring out how best to abuse recursion because they think it makes them leet programmers or some shit.

>>60
I don't know, but if 98% of my functions were functional, I should be better using a functional language, shouldn't I?
Ah, but you didn't really read my post.  I said that I might still use imperative (i.e. destructive) code inside functions that turn out to actually be pure.  Purely functional languages usually don't let you do that, or let you do it but in a rather awkward way.  If you just meant functional language as in language that puts emphasis on functional programming all while still allowing side-effects, then ignore this paragraph.

I don't want to put your opinions on s-exprs down, it's okay to dislike anything. But I think the other two benefits (homoiconicity and macros) outweight the annoyance that s-exprs are to you.
Ah but you didn't read my post.  I considering the possibility of a "more comfortable" non-S-expression surface syntax that has a direct mapping to S-expressions, thereby maintaining homoiconicity and macros (especially if the source code is preprocessed into S-expressions before any parsing even begins).

My problem with imperative paradigm is that there's a lot of shared state, because it's easy (and desired, to minimize memory usage).
Well yes, shared mutable state brings in a whole new class of bugs.  This is why I said that whenever I do end up writing impure functions, it's for I/O or for managing around the purely-functional workhorses.