Studying individuals is the wrong experiment. Static typing benefits tooling most when you have larger groups of programmers who much collaborate, often asynchronously. It's easy to hold a mental model of the code you write in your head and minimize mistakes, it's harder to hold a mental model of a larger program consisting of code written by many programmers.
I'd like to see them hand a pre-written codebase of say, 10,000 lines to a bunch of students, and ask them to make large changes/new features to the codebase.
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.
>Studying individuals is the wrong experiment. Static typing benefits tooling most when you have larger groups of programmers who much collaborate, often asynchronously.
Absolutely.
And also: static typing benefits is not about "development time" but about maintenance, adding stuff, refactoring etc.
If anything, dynamic typing would be expected to lead to faster development time, which is also why it's used in most prototyping.
Lastly: small sample. Did enough of them use an editor/IDE that could take advantage of a static type system?
Did enough of them use an editor/IDE that could
take advantage of a static type system?
Just because the language is static, that doesn't mean it benefits from an IDE.
For instance, Scala has fairly good integration on top of Eclipse and IntelliJ IDEA, however every time I try doing some work in Scala, I end up cursing and screaming, because these Scala IDE plugins are slow, incomplete and unstable and get in my way. And I can't blame their authors, because Scala is a difficult language to deal with.
Another example would be C++, which has been around for a very long time and is one of the most popular programming languages ever. And yet even Visual Studio has problems with its refactoring/IntelliSense support.
And then there are the Smalltalk environments, still around, still kicking ass.
Here's the thing ... there are static languages, and then there are languages designed for usage within an IDE ;-) Java, C# and Smalltalk are like that, while Scala, Haskell and C++ aren't.
i agree totally with both parents -- i wanted to comment the same...
static typing would more benefit:
* large groups of programmers
* large codebases
* maintenance (which is usually taking more resources then the initial development of a large code base)
aditionally i've come to believe that not all static typing is created equal. most allow `null` to be returned instead of adhering to the type, then some have exceptions and not many languages type side effects (like IO). i'm basically saying that C/C++/Java/C#'s kind of typing is not Haskell's kind of typing, and that the potential gains from Haskell's type system are much bigger on the long run (while it also comes with a steeper learning curve).
I'd like to see them hand a pre-written codebase of say, 10,000 lines to a bunch of students, and ask them to make large changes/new features to the codebase.