[vincent-toups]

I'm programming in Lisp (Chez Scheme) now.

I've been a serious Lisp programmer (recreationally and sometimes professionally) for around 10 years and I have programmed in Common Lisp, Scheme, my own weird dialects, Emacs Lisp, etc.

At this point I feel like almost everything written about Lisp is silly. Taken as a language family as a whole, there isn't much that separates Lisp from most of the other languages that are out there _except_ syntax-transformations or macros which, frankly, most people should never use.

For me, the best thing about Lisp is the regularity of the syntax. What I like least about almost all other programming languages is all the useless syntactic doodads and wingdings. The brackets, the indentation sensitive stuff, the unneeded complexity that languages insist on associating with what is and must be the denotation of a tree, in the end.

The other great thing about the language is that you must use `let` or `lambda` to introduce variable bindings and their scope is, therefore, always perfectly clear.

Despite these niceties, Lisp isn't going to make you into a super programmer. It won't really help you solve hard problems. It might help you quickly solve easy problems, but in the end, most of the job of a software engineer is grappling with conceptual problems with which Lisp is only sort of helpful.

As long as I'm holding forth, I will say that I enjoy programming in Scheme _much_ more than I enjoy Common Lisp, which feels incredibly, uselessly, and old-fashionedly complex with all sorts of weird corners to stub your toes on.

[reikonomusha]

"Most people should never use [macros]" is not a very good take-away. This is silly and overly paternalistic, like most programmers are children who shouldn't enjoy an extraordinarily expressive programming tool because it's "dangerous to readability". I feel as though people imagine more macro horror stories than they've actually ever experienced. I've experienced just one horror story in an optional-use open-source numerical library. And so I just didn't use it because I couldn't figure out how to extend it for my needs.

Many macros—just like programs as a whole—are bad and unhelpful. But this has little to do with macros, and more to do with programmer technique. It's not intrinsically difficult to write a useful macro, but it does presuppose that the programmer has a useful syntactic idea.

The Lisp family of languages so so broad and loose. It's hard to say anything generally about them anymore. But if you narrow down to Common Lisp, there's still a treasure trove of unique features. Common Lisp and Clojure seem to be the only two lisps where you've achieved broad community agreement on tooling, ecosystem, and general library design. They're also two languages where you can get paid to write them. Can't say the same about Scheme.

Lastly, as a personal anecdote, I don't think I've stubbed my toe on anything in Common Lisp. It's a very safe language with a lot of language features. I have stubbed my toe with CALL/CC though and memory leaks.

[vincent-toups]

What I mean about macros is that there just aren't a lot of problems that are really well suited to solution via meta-programming. People should be free to program however they want, but if we're evaluating the power of a language I think its fair to talk about the frequency and type of problems you might need to solve.

I think you're right about CL and CLojure, though. While I really prefer Scheme, its not really appropriate for solving a large set of practical problems.

[dreamcompiler]

> It won't really help you solve hard problems.

I have to take issue with this. There are only two languages I consider when faced with a very hard problem: Common Lisp and Haskell. One can solve easy problems in any language. But when I have to solve a new problem from scratch that nobody's ever solved before, I don't reach for Java or Python. I reach for the languages that augment my brain rather than limiting it.

[kqr]

I agree. I have several times solved hard problems in something like Lisp or Haskell, only to have to port the solution to a more common language for integration later. While I would expect the port to take less time than figuring out the solution in the first place, it generally takes longer because the target language is riddled with gotchas and inefficiencies that make the actual programming more difficult.