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.

>>58
I don't know, but if 98% of my functions were functional, I should be better using a functional language, shouldn't I?

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. Just look at how nice is to deal with JSON when Javascripting. XML and Java do not look as good choices.

And I really think that previous statement holds (about paradigm background). People only have trouble with things that they don't understand clearly. If you get that any program is some transformation f : I → O between an element in I to an element in O, imperative or functional don't matter. My problem with imperative paradigm is that there's a lot of shared state, because it's easy (and desired, to minimize memory usage). There's nothing wrong with shared state, except that it defeats the whole purpose of modules. Your functions can't be considered modules anymore, and programmers should take extra attention to the enclosing scopes. When you evolve into a big code base and a lot of coworkers, your heat-seeking missiles are “locked”, but can easily retarget your allies without your control or awareness.