Maybe good tools are able to perform some static analysis and rule out some of the methods with the same name but impossible types, but the language doesn't rule out situations where the best the tool will be able to do is show you all of the function definitions with the same name as the (dynamically dispatched) function call site you're looking at.

Let's say you have seven different type hierarchies having dynamically dispatched functions named "run", with 5 definitions in each hierarchy, for a total of 35 functions named "run". In a statically typed language, if the code compiles, it's possible to narrow down the type for a given call site to either one of the hierarchies or one definition, meaning you have to look at either 1 or 5 definitions. In a dynamically typed language, there are situations where legal code results in the tool having to throw up its hands and show you all 35 definitions.

The flip side is that if you really have a spot where you'll need to dispatch to any of the different hierarchies, then in a strong statically typed language, you'll need to either create an algebraic sum type covering all 7 hierarchies, or you'll need something like a typecase / typeswitch statement to enumerate out your possibilities.

And even in a statically-typed language there will be cases where the tooling can only determine fairly generic things statically.

I don't see anyone advocating for abandoning static typing over that occasional limitation. Yet I do see people proposing similarly-infrequent issues as cause to abandon dynamic typing.

When $problem happens in $language_I_dislike, it's a clear sign that the language itself is inherently broken.

And that's really all I care about, I'm not about to start writing production code in Lisp.

Well, usually. It gets a little confused when you start using dependency injection containers, or dynamic requires, or anything like that.

How can it be a niche language, if it's an ANSI standard, has more than 8 or 10 fully feature, standard-conformant implementations, runs on most CPU types, and has been proven to work in production systems for spaceship guiding, worldwide airfare reservation and credit card transaction verification?

You use Js and Python because you choose to use it, but it's not the only choice. Not only Common Lisp, you could also be working in Clojure with many benefits.

It is not. A language feature is either amenable to static analysis (not necessarily type checking) or it is not.

> Consider dynamic class loading in Java, dlopen / reinterpret_cast in C++ etc.

This actually emphasizes my point. Features that are not amenable to static analysis are problematic for tooling.