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.
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.
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.
- 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.
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.
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.
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).
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.
- Big consultancy company working with lots for Fortune 500 company groups;
- At least 3 development sites active at any time;
- Some projects can have 100+ active developers across sites;
- Several MB of written source code, plus many modules generated via specific DSLs or code generation tools
- The typical enterprise architectures
- Lots of crappy developers in some of the teams
The implications of static typing helps keeping the possible damages under control.
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.
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.
Most enterprise projects with modules developed in offshore, suffer from crappy developers that barely know one single programming language.
Forcing them to write lots of unit tests as required by dynamic languages development leads to nothing.
The only way to minimize broken systems is to use languages that force them to stay on course.
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.
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).