I can't understand how people use languages without static analysis. The only edge case I can think is using any scripting language to write a script that is less than 1k lines. Are there any pros for languages that don't have static analysis other than the fact that it allows "rapid development/prototyping"?
So you don't know any successful projects in JavaScript, Clojure, Erlang, Elixir, Groovy, Julia, R, etc. etc. etc.? ;)
There are well-known advantages and repeating them here will incite another flame-war.
I can only speak from my 35 years of coding experience, spending most of that time in the confines of static typing:
Most problems I solve today are not good fits for static types. They cause major headaches along the road as your customer's needs change and as I get a better understanding of the problem domain.
> Most problems I solve today are not good fits for static types.
This would seem to involve a widespread misconception about what static types are really about. Languages that "don't have static types" are not inherently more flexible than languages that do expose them; one can always translate a "dynamic" program structure to a statically-typed language in a way that preserves arbitrary flexibility in refactoring, prototyping and the like. Many languages even provide a standard `Dynamic` type for this very purpose.
The problems solved by static analysis are not the big problems, and when it's useful to solve some of them solving them in a less-than-complete way is good enough. (Even languages like Java implicitly align with this by allowing runtime reflection with strings.* )
You might just have to try it in order to get it. Write 10k lines, reflect on what your pain points were. I recommend giving Common Lisp a spin, its popular free implementation SBCL even has rudimentary and incomplete "static" analysis ('compile is a function available at runtime) useful for catching typos or telling you your types are off or telling you that with a bit of type hinting in places it could make your code compile to much faster assembly instructions (and you can immediately verify by calling the built-in function 'disassemble). After that you might understand a bit, even if you still don't like it. Meanwhile multi-million line projects exist regardless.
* And to continue a bit more with the article's vein of static analysis going beyond static types, there are many cases where we'd like to specify a function precondition which is too complex to prove holds in the real program. We don't lament, though. And if it's important, we check it at runtime. It's risky business after all running code without checks just because some external source approved it -- the external source could have made a mistake, or unexpected runtime conditions (many coming from the nature of programs having to run on physical hardware) could happen.
Sometimes you still are required to solve them as far as you can. The problems solved by systems like TLA+ or ACL2 can also be useful, and those are both free tools (ignoring engineer time). The absolute cost of solving a problem isn't the best measure for how "big" it is.
It's a good reminder though in reference to the GP that there's a richness in methods beyond what one might expect a programming language by itself to handle -- can you imagine someone proclaiming "I can't understand how people use languages without [input from my multi-million dollar] static analysis [tool]."?
There's some argument in favor of clarity I think.
Statically typed languages often require a lot of additional annotation of types and more awkward logical structures that interfere with readability. Obviously there is a counter weight that not having types be explicit creates its own set of problems. If type inference was perfect and languages were able to support things like union types seamlessly I think it would be possible to get close. But I've used languages with quite good inference (Kotlin) and it is still regularly a battle with the compiler to get it to believe something is "safe" which actually can only ever be safe but requires me to add extraneous syntax all over my code just to "convince" the compiler.
I quite like languages with incremental typing for this reason - you can create a statically defined interface and data structures but if you already know constraints are satisfied you don't need to pamper the compiler to continuously reassure it inside the function. But these would fall into your definition of languages "with static analysis" I imagine.
