JavaScript is a Dysfunctional Programming Language
JavaScript is supposedly a functional programming language. (Actually, it’s multi-paradigm, mainly imperative with some functional capabilities and a smattering of object orientation, via object prototypes.) Unfortunately, JavaScript is also a dysfunctional programming language, imbued with a myriad of “warts” and “gotchas.” It lacks the discipline to be a serious software engineering language, thanks to loose typing and freewheeling coercions, and their wildly inconsistent semantics. JavaScript doesn’t even have a proper integer type! JavaScript also doesn’t have a proper array type like you find in most normal programming languages. Just to be clear, despite ECMA working hard to fix JavaScript, it has yet to address the abovementioned problems.
JavaScript apologists are constantly telling us that all programming languages have warts. What they don’t tell us is that most languages have far fewer warts than JavaScript has. How big is the problem for this language? The following graphic gives you some idea:
Here are some long lists of warts:
Are there similarly long lists for Java or Python?
These same apologists also tell us that by applying good practices, including linters*, you can avoid the bad parts, and you’re left with programming joy. Isn’t that what Douglas Crockford’s book is all about? This is a fairy tale, of course. Good practices are not a perfect solution. Sooner or later, JavaScript’s loose typing and inconsistent semantics will bite you in the ass. Sooner or later, the lack of integers or proper array type will prove annoying. These things are like land mines, laying in wait with infinite patience to blow off your legs. Good practices mitigate but do not eliminate the problems.
(* Linters can also produce false positives which cause you to look for phantom problems. This can be a real time-waster.)
The need to be constantly aware of the bad parts most definitely places an added and unnecessary cognitive burden on the programmer. I alluded to this in JavaScript’s Sword of Damocles. So why do JavaScript proponents continue to promote its use?
The answer is: JavaScript’s large user community and ecosystem of tools and libraries, not to mention the large number of jobs available for JavaScript developers. This answer also explains the longevity of all the mainstream languages, irrespective of their faults, including: PHP, C++, Perl, and Visual Basic (languages everybody loves to hate).
The community and ecosystem argument is certainly quite compelling. There is no doubt that these things confer substantial benefits for both businesses and programmers. The benefits, however, must be balanced against the downsides, such as:
- the complexity and difficulty of maintaining the code base as the application grows beyond the safe threshold for the language (in the case of JavaScript, I’d say that’s about 20k LOC)
- the diminished reliability of the software as it grows so big that JavaScript’s lack of discipline interferes with the ability to ferret out defects and prove program correctness
- the difficulty of delivering software on time and on budget because the language imposes an unpleasant cognitive burden and slows down the programmer’s pace of work (a scientific study has shown JavaScript to be one of the least productive languages in IT, well behind C++, Java, and C#)
In other words, this is user community, ecosystem, and jobs versus maintainability, reliability, and productivity. The classical contention in IT.
It must be noted that while a rich ecosystem does aid in productivity (with reusable code, there’s no need to reinvent the wheel), you must still write new code for your business logic, UI design, testing procedures, etc. An inefficient language can hamper the latter to the extent that it wipes out the ecosystem advantage. A powerful and elegant language can work miracles. A prime example of this is Smalltalk. This language is much vaunted for its extremely high productivity, thanks to an incredible “live” programming IDE/debugger, and to impossibly clean syntax and semantics which remove any cognitive burden. In other words, Smalltalk gets out of your way so that you can focus on writing your application in the most efficient manner. This makes for a very pleasant programming experience, almost zen-like! Smalltalk’s ecosystem is not nearly as rich as JavaScript’s, but I wouldn’t bet against Smalltalk in any programming contest.
We are like Samson pushing back on the spurious promises of JavaScript, the lie that has beguiled a generation of naive developers. How do you counter so many foolish minds?
There’s no denying that JavaScript is very useful. Many modest-size applications have been written. The area where I am most concerned with is in software engineering at scale…applications that are many tens of thousands of lines of code (or LOC) long.
Of course, you can use any language to write large-scale applications. The question is, what are the risks involved? How much additional effort is required?
There may well be some large applications written in JavaScript (I don’t actually know), but this doesn’t tell us the whole story. It doesn’t tell us how reliable the software is, how many defects there are. How much down time did the application suffer? It doesn’t tell us how maintainable the code base is over time. It doesn’t tell us the life cycle cost of using JavaScript, which this study suggests is very bad. These are all real costs that cannot be ignored. Businesses are loathe to reveal such information.
From the enterprise perspective, we know that it’s safer to use Java, C#, C++, Python, etc. These languages rest on a solid foundation. They are proven quantities. They don’t have Bad Parts that far outweigh the Good Parts. This is a question of trust.
Ultimately, the question comes down to this: Are you doing serious software engineering, or are you hacking together relatively simple applications (less than 20k LOC)?
