Explaining the difference between strictness of languages and paradigms to a colleague of mine, I ended up asserting that:
-
Tolerant languages, such as dynamic and interpreted languages, are used best for prototypes and small projects or medium-size web applications. When choosing elegant dynamic languages such as Python or JavaScript with Node.js, the benefits are:
-
Fast development,
-
Reduced boilerplate code,
-
Ability to attract young, creative programmers who flee “corporate languages” like Java.
-
-
Statically typed/compiled languages are best for applications which require higher strictness such as business-critical apps or apps for medium to large-size apps.
-
Well-known paradigms and patterns developed for decades,
-
Ease of static checking,
-
Ability to find many professional developers with decades of experience.
-
-
Strict languages such as Haskell, Ada or techniques such as Code contracts in C# are better for systems which favor safety over flexibility (even if Haskell can be extremely flexible), such as life critical systems and systems which are expected to be extremely stable. The benefits are:
-
Ability to catch as many bugs as possible at compile time,
-
Ease of static checking,
-
Ease of formal proofs.
-
However, by looking at the languages and technologies used for large-scale projects by large corporations, it seems that my assertion is wrong. For example, Python is successfully used for large systems such as YouTube or other Google applications which require an important amount of strictness.
Is there still a correlation between the scale of the project and the strictness of the language/paradigm which should be used?
Is there a third factor that I've forgotten to take in account?
Where am I wrong?
Best Answer
An interesting case study on the matters of scaling projects that use dynamic and interpreted language can be found in Beginning Scala by David Pollak.
As you can see, major challenges in project scaling for author turned out to be in test development and knowledge transfer.
In particular, author goes into more details in explaining the differences in test writing between dynamically and statically typed languages in Chapter 7. In section "Poignantly Killing Bunnies: Dwemthy’s Stairs" author discusses Scala port of a particular Ruby example:
Reading above can make one think that as projects grow even larger, test writing might become prohibitively cumbersome. This reasoning would be wrong, as evidenced by examples of successful very large projects mentioned in this very question ("Python is successfully used for... YouTube").
Thing is, scaling of the projects isn't really straightforward. Very large, long-living projects can "afford" different test development process, with production quality test suites, professional test dev teams and other heavyweight stuff.
Youtube test suites or Java Compatibility Kit sure live a different life than tests in a small tutorial project like Dwemthy’s Array.