It's 2015 and there are still people using Common Lisp left

I switched from Common Lisp to Haskell.

I got interested in Haskell because of its purity and functional programming. I held my nose when dealing with its horrible syntax (which I still do to this day, but I was really distraught back then at the Perl code I had seemingly been creating and nearly gave up), and then got roped into liking the type system, and a deeper appreciation of laziness beyond tricks came much later.

Haskell also has much better set of standard classes; it has equality as a class, instead of the 5 or so functions and one for every data type that you have in Lisp, same for ordering, numerics, etc.

Partial evaluation makes for pretty predictable argument order, argument order in Common Lisp is hard to predict.

Most CL codebases I've worked on were not maintainable due to arbitrary side effects and no type system to support refactoring. CL is just a bad language for code that matters. Back when CL was my goto-language I found libraries and implementations lacking, but these days with Quicklisp and SBCL I think the situation is better.

GHCi is pretty poor in comparison to SLIME, there's no comparison. Lisp suffers from ugly macros, Haskell suffers from operator line noise. Where Haskell makes code hard to read by trying to abstract everything with types, CL programmers make up for it with macros and abstractions without any static enforcement. Lisp also suffers from selfishness on the part of the programmer because of how the language is setup, Haskell code comparatively is made to be shared.

Lisp functions like to be kitchen sinks with all the bells and whistles (the pathological case is the LOOP macro), Haskell functions like to do one thing like UNIX commands and lazily be glued together.

Community-wise CL's has generally always been unfriendly and bitter in my experience. In Haskell you basically write assuming GHC. Lispers try to write "portable" code, where portable means that this code will behave the same on different compilers with preprocessors for each compiler, or by using dumber libraries with fewer dependencies. I consider this a waste of mental effort.

In the end I care above all about maintainability and re-usability. For that Haskell is an obvious choice and has been since 2007.

Projects: Haskell is a much more well-designed language, so I find myself using it for pretty much everything.

Templating: Lisp wins in this department. Haskell doesn't really have anything equivalent to macros. There is TemplateHaskell, but that's not very fun.

Debugging: Haskell wins by a long shot. Haskell's strong type system means that most bugs are caught at compile-time. You'll spend much less time hunting down bugs, and more time coding.

Haskell's REPL, GHCi, is pretty nice. There's apparently a nice debugger, although I've never felt the need to use it.

Libraries: Not significant.

Community: Meh, both are pretty good.

I like the Haskell community a lot. #haskell on FreeNode is one of the highest-quality IRC channels you'll happen upon.

Workflow: I spend a lot less time debugging in Haskell, because of the aforementioned "once it compiles, it probably works" thing.

Haskell's Emacs support is pretty good, although not as good as Lisp's. There's structured-haskell-mode and hindent, which try to mimic paredit's functionality. Things like [projectile][3] and [Helm][4] will help you more than anything else.

Haskell's packaging tool, cabal, is very poorly written, but supports sandboxing and integration with the REPL. A lot of your Haskell time will be spent fighting with cabal, until someone gets around to writing a replacement.

Readability: Haskell is great, provided you stay away from infix operators. Most people use infix operators, so reading other people's code sometimes isn't fun. Lisp wins in this department, but not by much.

Collaboration: They are both pretty good.

Haskell intrinsically values "code correctness" a lot more than Lisp. This is reflected in collaboration. Lisp programmers seem to rely on common sense, where Haskell programmers rely on math.

For instance, a while ago, I sent a PR to Haskell's time library. As it stood, you couldn't take two ZonedTime objects, and order them. The first PR I sent was rejected because I made a dumb logical error. I fixed that and sent back a second one, and it was rejected.

8:00 Pacific time is 9:00 mountain time. Common sense would indicate that if compare these ZonedTime objects, you'll get back Eq. However, algebra would indicate that you would get back NotEq, because both the time and the time zone are different.

My PR included the common-sense definition of equality, and was rejected in favor of the algebraic definition. A lisper would probably say those are the same time. A Haskeller would not.

Although, in lisp, you would probably get back different answers for all 8 definitions of equality.