What the Blub: Java vs JavaScript

8 min readOct 5, 2019

Two popular languages for lightweight services are Java versus JavaScript. The choice is a debate or battleground. I have seen many engineers look at their preferred language with the sense of nostalgia and comfort they place in their favorite home cooked meals. Perhaps blinded by the Paul Grahams blub paradox:

…I’m going to use a hypothetical language called Blub. Blub falls right in the middle of the abstractness continuum. It is not the most powerful language, but it is more powerful than Cobol or machine language [or Visual Basic].

And in fact, our hypothetical Blub programmer wouldn’t use either of them. Of course he wouldn’t program in machine language. That’s what compilers are for. And as for Cobol, he doesn’t know how anyone can get anything done with it. It doesn’t even have x (Blub feature of your choice).

As long as our hypothetical Blub programmer is looking down the power continuum, he knows he’s looking down. Languages less powerful than Blub are obviously less powerful, because they’re missing some feature he’s used to. But when our hypothetical Blub programmer looks in the other direction, up the power continuum, he doesn’t realize he’s looking up. What he sees are merely weird languages. He probably considers them about equivalent in power to Blub, but with all this other hairy stuff thrown in as well. Blub is good enough for him, because he thinks in Blub.[1]

We must acknowledge that difference in type systems. We would classify Java’s type system as Strong and Static meaning there are limited implicit conversions of types (strong) and the types are enforced at compile time (static). JavaScript’s type system would classify Weak and Dynamic meaning that the language will try to convert types (weak) and the type system is enforced at execution (dynamic).

We also must acknowledge differences in programming paradigms. Java is an Object Oriented language working with imperative coding tactics. JavaScript is a multi-paradigm language offering Object Oriented with imperative tactics, but also Functional coding with declarative tactics. Those familiar with both languages will recognize that there are significant differences between their interpretation of objects. Many consider JavaScript’s system flawed — snarling at the concept of prototype inheritance as a bastardization of the pure object oriented paradigm.

Research shows that there are (at least) two schools of object oriented programming. The Alan Kay’s coined the term “object oriented” as he built the language SmallTalk which differed from other approaches: everything is an object and objects are instances of other objects. In the early 1980’s Bjarne Stroustroup added a similar “object oriented” concept to C as he built the language C++. However C++ differs in that while (almost) everything is an object, objects are instances of classes with inheritance, etc [2]. JavaScript happens to be modeled off of SmallTalks approach and blended with concepts from Scheme (or as Douglas Crockford says JavaScript is “Lisp in C’s clothing” [3]).

Does it matter where these languages rank on the abstractness continuum? From a task perspective, probably not. The majority of software being written today include tasks that can be accomplished in most of the languages on the continuum. Certainly some langauges provide more expressive constructs leading to simpler implementations. Bt from a task perspective (for a majority of tasks) most languages are up to the task. Per Java vs JavaScript — my read is that they are equally Blub.

The secondary concerns in choosing a language should include

Speed to market
Initial Quality
Mean Time to Resolve Defects

Fortunately studies over the last few years have remediated our need speculate on those factors.

Speed to market

One should consider the time it takes to deliver applications when one chooses a programming language. One study, by Stefan Haneberg, asked 49 subjects to develop a simple Java parser. These subjects had received fundamental Java training (and thus familiarity with the language). The participants were divided into two groups and trained with a specific language for the task. One group learned a language with a static type system while the other group learned a language with a dynamic type system [4].

The differences are quite high (for example, the sum of the development times of the dynamically typed solutions is 391,107 seconds, while the time for the statically typed solutions is 582,602 seconds). [4]

A boxplot visualization (through the lower extreme) allows us to see that the fastest participants in both the static and dynamic groups had relatively equal performance. However the visualization shows the first quartile, median, third quartile and upper extreme indicates that the participants in the dynamic type system group out-performed the static type system group.

Box plot showing languages with dynamic type systems have faster development times than languages with dynamic type systems [4]

Hanenberg continues with a Mann-Whitney U-Test to determine whether:

H0: The data from the statically and dynamically typed development times are drawn from the same sample [essentially the choice of language with a dynamic type system or a static type system has no influence on development times].

H1: The samples come from different populations [essentially the choice between a static or dynamic type system influences development times].

the p-value for the Mann-Whitney U-test is p=0.04. Since p<0.05, the null hypothesis (H0) can be rejected, i.e. both populations come from different samples [4].

Hanenberg continues statistical analysis to determine whether the results are impacted by a small group of significant under-performers in the static type group and ultimately rejects that the difference can be explained significant numbers of under-performers (and over-performers) skewing the results. He concludes:

languages with dynamic type systems have significantly lower development times than languages with leveraging static type systems [4].

While this conclusion contradicts those of previous studies — it does add empircal evidence favoring dynamically typed languages.

Initial Quality: Escaped Defects

Researchers from UC Davis (Baishakhi Ray, Daryl Posnett, Vladimir Filkov, Premkumar Devanbu) conducted a study of 729 projects, 80MM lines of code, 29,000 authors shared on GitHub to determine if language choice impacts software quality [5].

The study associated each code repository to a language and then from a language to a number of characteristics:

Paradigm { Procedural | Scripting | Functional }
Compilation Class { Dynamic | Static }
Type Class { Strong | Weak }
Memory Class { Managed | Unmanaged }

Graphic: Different Types of Language Class [5]

A study of this type is going to have some issues. Known issues inlcude [citation missing] that some GitHub repos are mis-classified to languages. “Scripting” seems to be an odd classification of paradigm — languages like JavaScript and Python support both imperative forms (procedural) and functional approaches. Regardless of any potential pitfalls the study is worth considering.

The study reaches four results. Result 1 is an overall statement:

Some languages have a greater association with defects than other languages, although the defects are small [5].

Graphic: Showing escaped defect rates by language

An fundamental concern with these results of some languages (such as Scala) come from a small number of repositories. For example the Scala results are drawn from 55 projects as compared to the JavaScript whose results are drawn from 432 repositories.

Retracing back to our original discussion of Java and JavaScript we can see that Java (-0.01) out performs JavaScript (0.06) with respect to escaped defects. The JavaScript looks to be significant, tagged with a P-Value of p<0.01 (meaning a 0.1% chance to have occured at random).

Result 2 classifies based on programming paradigm:

There is a small but significant relationship between language class and defects. Functional languages have a smaller relationship to defects than either procedural or scripting languages [5].

Graphic: Functional programming languages demonstrate less defects

This result overcomes some of the sample size problems in Result 1. However it raises a concern on selection bias. Namely are the programmers who gravitate to the primary functional languages in this study (Haskell, Scala) categorically different as programmers? One could cross referance their works in non-functional languages to the generalized population to get a sense but that analysis wasn’t performed.

Result 3 focuses on Domain. The domain dimension classifies project as Application, Code Analyzer, Database, Framework, Library and Middleware.

There is no general relationship between domain and language defect proneness [5].

Result 4 looks at defect type. The Defect type dimension classifies defects as Algoithm, Concurrency, Failure, Memory, Performance, Programming and Security.

Defect types are strongly associated with languages; Some defect type like memory error, concurrency errors also depend on language primitives. Language matters more for specific categories than it does for defects overall.

When looking at Java and JavaScript by defect type we see contradicitons to result 1. Here JavaScript out performs with respect to Memory, Concurrency, Security and Failure.

I tend to think the only meaningful conclusion to draw here is that functional languages tend to outperform from an escaped defects perspective (and it is not conclusive whether this is due to selection bias or language deisgn) — but that isn’t the pupose of this post! Java vs JavaScript looks like a toss-up.

Mean Time To Resolve Defects

Hanenberg continues his study to measure how quickly the subjects were able to resolve defects. The study limited the types of defects to defects caused by mismatched types which manifested in static type systems as compile errors and in dynamic type systems as “NoSuchMethod” types of exceptions.

Hanenberg concludes in this case that there is no statistical differences between the time to resolve the mismatched type defects between the dynamic typed group and statically typed group [4].

This result is interesting for two facts:

These are the types of defects that most static type systems (particularly ones of Blub complexity) are expected show their performance advantage
It introduces questions on why the group leveraging the dynamic type systems out performed on the time to market test or why did the group leveraging the static type system underperform.

Closing out

Look at languages higher in the Blub paradox and learn about the constructs they provide. I have found this to broaden my perspective, my ability to think abstractly and to see patterns where I previously saw unique problems. Languages like Haskell, Idris, Agda etc have far more advanced type systems than Java and JavaScript. Perhaps they are a bit esoteric , but what can they teach you about your preferred tooling?
The tasks we typically encounter (especially in the enterprise world) are likely solvable by most languages. Religious battles over language selection are a distraction turn those conversations to ones based on metrics. You could elect to search published research or conduct your own.
At least one study concludes that dynamically typed language look to get products to market faster. This would seem to make sense in smaller efforts.
Static type systems don’t impact defect rate as much as coding style. Java and JavaScript performed perfectly Blub with respect to rate. However functional languages significantly outperformed the field (particularly functional languages which run on the JVM).
It looks like MTTR for escaped type-defects favors JavaScript over Java. This is just a small portion of escaped defect types that one should almost ignore this bit — but this is the one area Java is supposed to excel. This makes it surprising but not a practical difference maker in either direction.