Could you maybe break it all down for us ? thanks
Common Lisp has found a very high local-maxima for macros. If you knew all of common lisp except defmacro, I could explain how it works to you in about 3 sentences. This is an absurd lever for how much power it gives you. This is also where many "lisp-in-foo" implementations fall down.
They (rarely) use the scheme macro system (which has a very complicated algorithm behind it) or more commonly implement the common lisp system, but without the features of common lisp that make it reliable. A major exception to this rule is Clojure.
I'm not a huge clojure fan, but every single place in which it differs from common lisp, it is immediately apparent that Rich understood why it was done in common lisp, and has very good reasons for doing it differently. It's one of the very few lisp branches that I can't find Chesterton's fences[1] in. I don't think this is because there's anything wrong with lisp, but rather that it's very very easy to write a any lisp dialect, which means you get a lot more bad ones. You need to do a lot more work to write a bad
1: https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_...
Anything that takes work required some form of motivation. It is very likely that the person that did the thing you think to be wrongheaded was a lot more like you than different from you.
The times when experience gets in the way is when the reasons for decisions are no longer true, but you fail to revisit those decisions. My favorite example for this is the Jet engine:
Radial-flow compressors create far too much drag to create efficient engines. Axial flow compressors generate too little compression in each stage to create lightweight engines. Therefore jet engines are not practicable.
The above paragraph was true around 1930. Improvements in metallurgy, machining, and compressor design eventually made axial-flow compressors much lighter and more efficient. I can easily imagine a more experienced engineer telling a less experienced one something like "I looked into that and the math just doesn't work out."
One can't fault the more experience engineer because one doesn't have time to reexamine all of the underpinnings for all of the knowledge one has about the world on a regular basis. Though I do recall hearing a few people (including Feynman) who would keep a journal of problems they failed to solve. Any time they would learn a new technique or about a new technology they would flip through and see if there was anything in it that could be solved with the new information.
I think Lisp is interesting, but I doubt you will find many parts that are "better" (more powerful or succinct) than Haskell.
Lisp is primarily about freedom that macros give you. However, the two huge use cases for macros, selective evaluation, and representing code as data (different interpretations of the same code), can be naturally done in Haskell. There are some other minority use cases for macros, but in my current view they do not justify the cost of losing the type system.
I now think that macros are an evolutionary dead end. They are powerful, but they are hard to integrate with the type system. It's kind of surprising that progress (IMHO) in programming comes from (selective) restriction of freedom. And that's why Lispers will probably strongly disagree with me...
Anyway, if you like Python, you might like Lisp. The core language is more elegant, and much more powerful, but the libraries are generally less polished.
Somebody recommended Let Over Lambda to show what macros can do, I don't disagree but I would recommend reading On Lisp first, it covers more traditional uses of macros.
Interactive Development let you iterate ideas really fast, and allows an ease of exploration that's refreshing and can really help to learn how to use a library, an API, etc.
Metaprogramming lets you add whatever functionality you want. It can help reduce boilerplate code down to a minimum.
Those are the two features where I think it distinguishes itself.
Many of the ideas presented by Bret Victor can be seen on those environments
Allegro Common Lisp and LispWorks are the surviving examples how they used to be.
If you like Lisp for specific tasks then exactly this would be a good reason to do so.
When you want the design to be fixed and predictable and easy to develop for the developer, before the program runs, pick Haskell.
Lisp has a macro called setf, which takes any call which gets a value -- whether from a local function variable, or a class, to an array or hash table entry -- and converts it to the corresponding setter call. (If you define your own value places/types, there are also functions to make setf aware of how they work, so this isn't restricted to just some defined set of features in the language. Anything that holds a value in Lisp can be "setf" to a new value.)
There are a couple of other "big" Lisp macros in the language standard like with-open-file (which ensures a file is closed once control flow exits the body), loop (does pretty much what it says on the tin: provides whatever looping method you might want), or handler-case (try-catch style error handling; yes, Lisp allows for other methods).
Or how about the example I recently saw in a cryptography library. Since a lot of cryptographic algorithms use integer math modulo some giant number, this library defined a macro "mod-n" which took a base and some Lisp code, and re-wrote the code so the common integer math functions (addition, multiplication, etc.) would only return values "modulo {base}" --that is, return only values between 0 (inclusive) and base (exclusive). This meant their modulo math code looked (nearly) the same as normal, just standard arithmetic functions. This wasn't a very large macro either: only around 10 lines long (and about half of that being the list of operator replacements).
1: https://www.destroyallsoftware.com/talks/wat (45 seconds in)