The “use-case” ignorance
Tauseef Khan 
31

People have only nine fingers? ;-)

They’re only as good as the work people produce using them.

But the quality of the tools do matter. A lot. Good tools make the job easier and safer. Bad tools make the job unnecessarily harder and more problematic. Getting the job done, by itself, simply isn’t good enough.

My Narrative

I first studied programming in high school in the 1970s learning FORTRAN on mainframes and punch cards. In university, I learned PL/1. When I graduated, my first two jobs used FORTRAN again.

Then I moved on to Modcomp assembler at AECL, Tandem TAL (a cross between C and Pascal) at the Toronto Stock Exchange, and C, which became the primary language of my career.

In time, I also picked up C++, C#, Smalltalk, Objective-C, Java and Python. And I played with Go language and Scheme.

The pinnacle of my career was as Project Team Leader of the Windows NT Driver Group at ATI Technologies (now AMD), the famous PC graphics card company. In all that time, I learned the importance of software engineering discipline and what happens when you don’t have the proper tools to support that discipline.

Epilog

I think I can say with some justification that I know what is required of a programming language to support good software engineering. I can compare JavaScript with Smalltalk and Python (both dynamic languages), and with Java, C# and C++. I can see where JavaScript is lacking and why it’s sloppy.

Here is something else that I know: good developers can produce good code in any language. Just because some people can make good use of JavaScript does not make it a good language.

As much as we would all like to think we are good programmers, the truth is, most of us are pretty average, with some being rather mediocre. I’ll put my ego aside and admit that I’m just above average. I am certainly no star developer.

Google understood this. That’s why they came up with the Go language. Go was designed pragmatically for software engineering at scale in a team environment. They recognized that not everybody on the team can be a star programmer. So they created a language that was blessedly clean and simple, easy to learn and master, and disciplined enough to write software systems comprising hundreds of thousands, if not millions, of lines of code. You don’t have to be a super programmer who can craft coding masterpieces with Brainfuck.

With this perspective, I regard JavaScript as a poor language. It may be easy to pick up, it may have a very low barrier to entry, but it is intrinsically dangerous for average programmers to write serious software with. For businesses with large applications, JavaScript means higher maintenance costs and greater difficulty in assuring a desired level of reliability and performance. All my years in IT tell me this. If I’m wrong, you’ll have to explain why.