This claim: "Python/Ruby/Javascript: my experience is that large systems are difficult to maintain in these languages, as the dynamic typing makes it difficult to refactor large codebases without introducing errors in poorly tested areas of a repository"
-- is unfounded.
Not necessarily unfounded, you simply don't have access to data on it.
I am not at liberty to share details, but I have in fact seen data from a large company based on many internal projects that found that initial development was faster but long-term maintenance costs were much higher for stuff written in dynamic languages like Python and Ruby than in static languages like Java and C++.
The cost difference was both large and real. As someone who mostly does dynamic languages I didn't like the conclusion, but I couldn't argue with the numbers.
> initial development was faster but long-term maintenance costs were much higher for stuff written in dynamic languages like Python and Ruby than in static languages like Java and C++.
I don't have any hard data, but this feels right. I wonder what would be the results with Clojure, which certainly isn't statically typed, but doesn't do duck-typed function dispatch (like Ruby and Python, and even Go) either.
It's a misnomer to say that Go uses duck-typing because an object must statically implement a complete interface, not just a subset that's hopefully sufficient for what happens at runtime.
> I have in fact seen data from a large company based on many internal projects that found that initial development was faster but long-term maintenance costs were much higher for stuff written in dynamic languages like Python and Ruby than in static languages like Java and C++.
A big part of this is the shortsightedness of the companies themselves. There are steps you can take to ensure that you can manage types in dynamic languages. Very often, companies simply don't take these steps. It's not programmers that need babysitting by tools. It's big enterprise.
> It's not programmers that need babysitting by tools. It's big enterprise.
If one language is easier for "big enterprise" to maintain than another, then what's the problem? Obviously different languages have different strengths.
The claim 'big enterprise is better served by a statically typed language' is a different claim than 'dynamically typed languages cannot be used for large projects.'
> If one language is easier for "big enterprise" to maintain than another, then what's the problem?
I never said there is a problem. There is a lot of inefficiency in big enterprise, but since they're basically sitting on a formula to print money, it's often not a problem. (Until they start to get out competed.)
A big part of this is the shortsightedness of the companies themselves. There are steps you can take to ensure that you can manage types in dynamic languages. Very often, companies simply don't take these steps. It's not programmers that need babysitting by tools. It's big enterprise.
I am not at liberty to discuss details, but I would be shocked if your theory was an accurate explanation of the data that I saw.
-- is unfounded.
Not necessarily unfounded, you simply don't have access to data on it.
I am not at liberty to share details, but I have in fact seen data from a large company based on many internal projects that found that initial development was faster but long-term maintenance costs were much higher for stuff written in dynamic languages like Python and Ruby than in static languages like Java and C++.
The cost difference was both large and real. As someone who mostly does dynamic languages I didn't like the conclusion, but I couldn't argue with the numbers.