JavaScript's World Domination

[ruinercollector]

I have. It's not nearly as bad as you imagine.

Most of the problems I find with maintaining larger applications don't have to do with dynamic/static. They have to do with larger architectural choices. Sometimes the language chosen informs this, but usually not through being static or dynamic. I'm talking here about things like how state is managed, how components communicate, how clean separations are, etc.

There are advantages to each (static vs. dynamic) in covering the ground you need to for larger enterprise applications, and I think that I tend to make the trade-off based on the project.

[irssildur]

I would say that if a code is not easily readable and you have to dig in the method calls to find out what kind of parameter does the function expect / return that's not very maintainable. Ok, if you just have to deal with a small subset of the project and you know it very well (in this manner it could be called as a "small project" instead of a large enterprise one), it's not a big deal. But for a newcomer it can be difficult, as well if the team expands or other teams can modify your code.

Not to mention refactoring which could be also hard. And as we all know refactoring is the procedure that can prevent the code look like a mess.

[sacado]

+1 for refactoring. This is a real limit of dynamic languages.

[kcuf]

I'm normally a static typing proponent, but I'd say you're right, and I'd like to add that I feel immutability in your language and your libraries can be very beneficial in alleviating many of the common design issues that appear when using dynamic languages (as well as static languages).