That dynamic typing and Lisp-style macros are advantages is highly debatable. Most programmers I've worked with (some of whom are probably in the top 1% of coders in the world, these include the guys who developed PLT Scheme) would in fact consider both those features to be disadvantages.
Example counterarguments:
Static typing is far better than dynamic typing. There is nothing you can express in a dynamically typed language which you cannot express in a statically typed language, and most of those things can be expressed just as succinctly thanks to type inference. Further, to use your own words, static typing provides debugging "at compile time or link time, not at runtime."
Hygienic macros (i.e., macros which gracefully handle identifier collisions) provide all the same "language-building" features of Lisp-style macros without mysterious bugs caused by namespace clashes. Furthermore, the "customization" use case you point out is far better served by either higher-order modules (a.k.a. functors), which enforce provides-requires relationships at compile time; and by compile-time inlining of static code (also known as partial compilation), thus allowing the same language to be used for compile-time and run-time code.
I'm going to agree with you about dynamic typing. I spend most of my time programming in dynamic languages, but I spend a lot of that time pretending I have static types. I waste a lot of CPU cycles making up for the safety difference between static and dynamic typing. Then I waste even more to be able to store "hello world" and 42 in the same variable, even though I never need to do this.
Fortunately, if I care about CPU time, I just use Haskell, which gives me the syntactic sugar and expressiveness of Lisp with the type safety of ... well ... Haskell.
The question isn't whether you want static types while running or debugging (or testing). The question is whether you want static types while developing.
>Static typing is far better than dynamic typing. There is nothing you can express in a dynamically typed language which you cannot express in a statically typed language, and most of those things can be expressed just as succinctly thanks to type inference. Further, to use your own words, static typing provides debugging "at compile time or link time, not at runtime."
Most things require little change but when you need to add a method to a class, static typing starts to get in the way. Node.js express framework could not have been made in a static language nor could rails find_by_* method system.
Loop is a fucking mess and, in Common Lisp, is not strictly implemented. But while I wouldn't recommend it to anybody, for any given implementation (clisp, say), yes, you can.
Example counterarguments:
Static typing is far better than dynamic typing. There is nothing you can express in a dynamically typed language which you cannot express in a statically typed language, and most of those things can be expressed just as succinctly thanks to type inference. Further, to use your own words, static typing provides debugging "at compile time or link time, not at runtime."
Hygienic macros (i.e., macros which gracefully handle identifier collisions) provide all the same "language-building" features of Lisp-style macros without mysterious bugs caused by namespace clashes. Furthermore, the "customization" use case you point out is far better served by either higher-order modules (a.k.a. functors), which enforce provides-requires relationships at compile time; and by compile-time inlining of static code (also known as partial compilation), thus allowing the same language to be used for compile-time and run-time code.