Scalability: Dynamic and Static Programming Languages

In the wake of the demise of Chandler personal information management project, a discussion has occurred on TSS about the scalability potential of dynamic languages. Ted Neward attempted to go beyond language quarrel in order to provide some structured insights on this issue.  

First of all, Neward emphasizes that a language scaling can be understood in terms of "size of project, as in lines-of-code" or in terms of "capacity handling, as in "it needs to scale to 100,000 requests per second"". The two need to be delineated because even though both are important, they do not always go hand in hand: assembly languages or C, for instance, are conducive to capacity scalability but not to size scalability.

Neward defines size scalability in terms of “a language’s ability to extend or enhance the complexity budget of a project”. He refers to Mike Clark's concept that implies that “every project has a fixed complexity budget, and the more you spend on infrastructure and tools, the less you have to spend on the actual business logic." And according to Neward, this point is at the core of the debate about the scalability capacity of static and dynamic languages.

The adherents of static languages argue that type-safety check results in fewer work for the programmer “as an automated tool now runs through a series of tests that the programmer doesn't have to write by hand”. Moreover IDE support that exists for these languages provides powerful tools for refactoring that are “widely believed to be impossible on dynamic language platforms.” Dynamic language proponents, however, put forward the fact that “the dynamic nature of these languages means less work during the creation and maintenance of the codebase, resulting in a far fewer lines-of-code count […] thus implicitly improving the scale of a dynamic language”. 

According to Ted Neward, it is true that “dynamic language programmer can typically slam out more work-per-line-of-code than his statically-typed compatriot”, but he will most probably need to produce more unit tests given that dynamic languages do not use a compiler that, in a way, ensures a certain number of systematic tests. 

As for IDE refactoring, Neward references Dave Thomas who admits that refactoring support of Eclipse, for example, is limited for dynamic language platforms given that type information is missing until runtime. Thomas highlights, however, that “simple search-and-replace across files, something any non-trivial editor supports, will do many of the same refactorings as Eclipse or IntelliJ provides, since type is no longer an issue.” And Neward emphasizes that he expects IDE vendors develop tooling specifically designed for dynamic languages:

 [… ]it's relatively easy to imagine that the IDE could be actively "running" the code as it is being typed, in much the same way that Eclipse is doing constant compiles, tracking type information throughout the editing process. 

Moreover one should not forget that “the original refactoring browser was an implementation built for (and into) Smalltalk, one of the world's first dynamic languages”, as it was highlighted in the TSS debate.

With respect to capacity handling scalability, Ted Neward stresses its importance because “a project that cannot handle the expected user load during peak usage times will have effectively failed just as surely as if the project had never shipped in the first place.”  

Dynamic language opponents argue that these languages cannot scale in terms of capacity handling, because they are “built on top of their own runtimes, which are arguably vastly inferior to the engineering effort that goes into the garbage collection facilities found in the JVM Hotspot or CLR implementations.” Dynamic language supporters respond that “there are plenty of web applications and web sites that scale "well enough" on top of the MRV (Matz's Ruby VM?) interpreter that comes "out of the box" with Ruby”. 

Ted Neward, at his turn, points out that “with the release of JRuby, and the work on projects like IronRuby and Ruby.NET, it's entirely reasonable to assume that these dynamic languages can and will now run on top of modern virtual machines like the JVM and the CLR”:

While a dynamic language will usually take some kind of performance and memory hit when running on top of VMs that were designed for statically-typed languages, work on the DLR and the MLVM, as well as enhancements to the underlying platform that will be more beneficial to these dynamic language scenarios, will reduce that.

Ted Neward seems to believe that there is a window of opportunity for improving scalability of dynamic languages in terms of both project size and capacity handling by adapting tools and optimizing runtime environments to their specificities. More generally speaking, he rather opposes the dichotomy between static and dynamic languages. He highlights the fact that some applications, Excel for instance, successfully combine the two "by creating a core engine and surrounding it with a scripting engine that non-programmers use to exercise the engine in meaningful ways.” Neward sums up rephrasing Karl Marx: "From each language, according to its abilities, to each project, according to its needs."