And good on them. But that doesn't mean it's easy to write large websites in dynamically-typed programming languages, it just means that they are very good at what they do.
- Multi-site development at least in 3 countries;
- Sometimes up to 100+ developers
- CI systems
- Source code of several MB of source code
- Enterprise like infrastructures for Fortune 500 companies
- Different skill sets from the "just out of the university" to the "top developer"
Maybe YouTube beats this, but Google only has Phd guys able to crack out crazy algorithms/data structures in minutes. Not typical in most software houses.
I agree dynamic languages result in smaller codebases, but that's only because they tend to be so much more concise than most statically typed languages.
Also, as for large and complex projects done by distributed teams, I don't have to point much further than Django or Plone to prove dynamic typing works well in that context.
The plural of anecdote is not proof. Heck, it's not even data.
Heck, the examples you give aren't even anecdotes. They're just name-dropping. One would have to be pretty familiar with the codebases in question and the history of their development in order to be able to give a clear assessment of what, if any, impact dynamic typing might have had on them.
Fair enough. They prove large projects built by distributed teams are possible in at least one dynamic language.
There was a time I was familiar with both codebases (I have some catching up to do) and that's why I mentioned them. Both projects carry heavy heritage and are experiencing huge pressures to evolve and both are doing very well (from what I hear on the dev lists).
Sure, but even then one merely has an observation that there are these two large projects that are written in dynamic languages and are being successfully maintained.
That doesn't imply that they are being successfully maintained because they are written in dynamic languages, or despite being written in dynamic languages. And of course there's also the possibility that static vs. dynamic is a wash and doesn't really have an impact at all. Or that the potential impact of going with static or dynamic is heavily influenced by other factors - does the static language have type inference, does the dynamic language support duck typing, stuff like that.
Long story short, correlation does not, in and of itself, imply causation.
In any case, it's mostly an apples to oranges comparison. Observing from my heavily biased toward web applications experience, there aren't as many Python codebases as there are Java ones at least in part because you can do a lot more with a small Python codebase than you can do with a similarly sized Java codebase.
By limiting the damage a single crappy programmer can do.
Everywhere people talk about 'large' teams maintaining a large codebase in this thread, substitute 'mediocre' teams stuck with a poor bloated codebase that is the vehicle for their ambitions. It's just not worth anybody's time to understand its unique needs in detail, especially since any improvement you make today risks being messed up tomorrow.
I can understand using static typing if you already have a large codebase that's statically typed, but is there any reason you'd start a project with a statically typed language?
Yeah the benefits of static typing are front-loaded at the start of a project. I might rewrite in a statically-typed language for performance if it ever needs it, but I wouldn't start statically-typed.
My lisp interpreter above allows me to tear out a lisp function and replace it with a C function, while leaving the unit tests untouched.
Dynamic languages are very good for prototyping or small scale projects.
But they fail to address the context of programming large scale applications with teams distributed across multiple sites.