I've tried on a few occasions to really like Lisp. I love it's simplicity and recursiveness. The "code as data, data as code" thing is really cool.

But I love static typing. Not only for "safety-net" reasons, where the compiler lets you know that you've broken stuff, but also for documentation reasons (I don't have to guess at the shape of each "c" in "cs" in "(mapcar some-fun cs)", I can just look at its type and know its shape), and I really like it when that type system lets me be more expressive, like in MLs (where I can pattern-match by the various members of an ADT and destructure them as I go).

I also find that idiomatic Lisp likes to nest things too much to be really readable for me. If I don't have types to tell me how the data's being transformed, at least give me named functions and well-named variables instead of very-deeply-nested anonymous functions everywhere.

And finally, I've never been completely convinced that macros are a great idea. They're far too easily abused to create "the Scala problem" of having code in language X that is still unrecognizable to someone else who also writes in language X.

I totally agree with you here; statically typed languages (OMG OCaml) are great for making code very readable/documented, IMHO. I just have so much more confidence in my code when the compiler has my back.

Another commenter pointed this out, but Typed Racket is a Racket variant (which is a scheme-ish variant) that implements "gradual typing". I've played with it here and there and am about to dive in again.

https://docs.racket-lang.org/ts-guide/

That's a very good point. Type information certainly help reading. That might explain why Lisp is easy to write but hard to read. I did find myself having to go into a function's code to figure out what it does and what the parameters are. Hard to read code make sharing difficult and hinder widespread language adoption.

I dislike Lisp (and Lisp-inspired languages like Scheme and Clojure) for two reasons:

1. their weak and dynamic type system, and 2. they don't control side-effects.

Haskel programmers: you can spot them by that constant pained look, as if they have to step in horse poop whenever they go outside.

Your comment is almost accurate when referring to Haskell programmers who have not used the language for very long.

I meant no disrespect. The horse poop outside was a metaphor for side effects.

During my brief exploration of Haskell, I went to great lengths to avoid dealing with side effects, and when I couldn't avoid them, the pure functional solutions were pretty painful to learn.

> I meant no disrespect.

I don't believe you.

Wow. Must be a culture clash or something. Let's both just have a nice day, then.

I'll agree that clojure doesn't enforce control of side-effects. But with the recent work on clojure.spec, your first complaint has become (even more of) an asset.