Shouldn’t we use programming languages with fewer bad parts?

I was reading that Stanford has begun teaching their introductory computer science course CS101 with Javascript. Despite a lot of the propaganda surrounding the web and a pretty good book on the good parts of Javascript, I can help but think that Javascript has some really tragic flaws. Dijkstra famously referred to PL/1 as “the fatal disease, belonging more in the problem set than in the solution set”, and I kind of feel the same way about Javascript. Yes, it is in every browser now, so it is perhaps the most widely deployed programming language you can find, but it’s got quite a few absolutely horrific features in it. The == operator has some astoundingly obtuse behavior. Automatic semi-colon insertion is simply idiotic. Crockford documents several more features he finds questionable, most of which I think are questionable, because they mirror features in other common languages.

Crockford advises that we use tools which check our use of these questionable features, but wouldn’t it simply be better if the language didn’t contain these features in the first place? We know that some features are bad, so why are they retained in the language? Are we forever to be saddled with error prone and silly features?

One thought on “Shouldn’t we use programming languages with fewer bad parts?”

  1. Dan Lyke

    I’m no particular friend of JavaScript, but maybe rather than asking if it’d be better if the language didn’t contain those features, we should be asking why popular languages are the sort that language pundits have been denigrating for as long as there have been computer languages and language pundits, and why the ones that seem attractive die quiet deaths.

    Remember Modula-(2||3)? Eiffel? Languages put together by people with strong opinions on computer language design that never went anywhere.

    I still cringe at loose typing. I keep saying that I want more structure in my languages. But when it comes right down to it the tool that I pick up to solve a problem is never the one that Dijkstra endorses, so maybe it’s time to reevaluate my prejudices and beliefs in the face of the observable reality, and let pragmatism drive my language choices.

Comments are closed.