That's a good point, and perhaps it is. The majority of my experience with dynamic languages is probably in Python.

One thing that makes a difference between Python and other commonly used dynamic languages (here referring to JavaScript / ECMAScript and Lua) is that Python is dramatically more complex out of the box. This is both in terms of language features and Python's batteries-included standard libraries. For example, the amount of overloading that you can do in Python is very impressive, but the result is that common operations aren't necessarily predictable or dependable without more context (not that this isn't a problem in static languages - looking at you C++, but at least in the other languages you get type information to help out and some checking at compile time).

Funny, my experience has been that large/ complex python code is actually easier to follow than JavaScript because of the line noise that JS requires. Side by side, the same code will usually be easier to read in Python (or Ruby.)

Same goes for Java, although in a slightly different sense. I've seen non-trivial Java projects balloon quickly where you have dozens or hundreds of classes & interfaces with no clear sense of structure. High line noise, lots of boilerplate. Sure it compiles but at the end of the day it's just as likely to hit a NPE so you have to rely on functional and unit tests regardless of static/dynamic/compiled/interpreted.

Obviously a lot of it comes down to who's writing the code. For me, a language that lets me succinctly express my intentions with minimal cruft is what wins.

I totally agree that it comes down to who the code is written by. I've done both python and java, and in python I would go so far as to define interfaces as a form of documentation in my python code so people who use it know what I expect out of their classes which want to interact with my object. It doesn't require the class to explicitly implement the interface but they can if it makes sense (fairly similar to Zope Interfaces I guess). Unfortunately, I don't see this a lot in most python applications and you're left searching around through calls to figure out exactly what is required of the object being passed in. Look at a lot of popular libraries -- you are still left searching through code just to see what can possibly be returned because they aren't always the same type -- also, exceptions aren't part of the function or method definition, which means if you don't document your exceptions, I'm up shit creek. I think a lot of the problem around the python ecosystem, again, that I've seen, is people just don't follow best practices -- documentation, it's a core component if python development -- It's one of the arguments they use against static typing. Personally, I think python developers need to be much more strict about development practices than java developers. I think it's a lot easier to make bad python code than it is to make bad java code. The same goes for C, which I used to also do as well. To be a good C developer, you have to be very strict and structured (however, for somewhat different reasons). With great power comes great responsibility.

I've seen shit java code as well. A lot of bad java code usually revolves around things not being modular or not having some form of consistent development patterns or not breaking methods down into simpler sub-problems -- I think documentation isn't as important as it is in python for the fact that I know exactly what is being returned, what exceptions can be thrown, and what exactly needs to be passed in just by looking at a method. In terms of the business logic associated with the class, that still needs to be documented.

That said, I understand why python is generally used at startups -- it allows fast initial development where at startups, time is critical. Long term development really relies a lot on the teams ability to make structured decisions and organize their code, which is a difficult task in any language.