Douglas Crockford says we should quit using JavaScript.

Douglas Crockford is the author of JavaScript: The Good Parts, creator of JSLint, the linter that has become the basis for JSHint, ESLint, etc -- all the JavaScript linters -- and creator of the JSON data interchange format.

"There are lots of terrible mistakes in the way that the web works, in the way our operating systems work, and we can't get new ones. We're just stuck with this crap and they keep piling new features on everything and the new features always create new problems and it doesn't have to be like that. We could be using a really clean operating systems with really clean languages and really clean runtimes and doing all this stuff in a much more reliable way. But we don't seem to want to do that."

I have a theory as to why we never seem to want to do that. But first, an explanation (quickly) of how I came to have some appreciation for what I've come to call "minimalism" -- the idea that in programming languages, more is not better. I've told the story before so you can skip if you've already heard it. Years ago I was working on a C++ project and my boss said, "Hey Wayne, so-and-so has left the company. You're taking over his code and we need you to fix some bugs and add some new features immediately." I went into his code... and couldn't even read it. Like, at all. It was like it was written in C++. I thought I knew C++, but no -- I realized that C++ was such a huge language (the official spec was something like 1,100 pages if memory serves -- it's probably even bigger now) that every developer uses a subset of C++. My subset and his subset had little overlap. This is not a recipe for long-term maintainability. For long term maintainability, one of the things you want is what I've come to call "ambiguity reduction". It's important to realize this is about the human reading the code, not the machine. To the machine, everything is always deterministic, no matter how complex. For the human, you want to be able to read a line of code and know exactly what it does. This makes it easy to reason about the program's behavior. This means not having hidden "magic" in programming language features. The more of these "magic" features you have to memorize, and the more complex the rules you have to memorize, the more liklihood you have ambiguity when you read lines of code.

Ok, now to my theory as to why "we don't seem to want to do that" -- make really 'clean' languages. New languages are often created by new people entering the industry, who have great enthusiam for one or another set of ideas. But what they don't know is how a design decision you make today will affect your software 10 or 20 years down the line. For that, you need to have been around for 10 or 20 years, and had that experience. In other words, it's the old people that have that knowledge. They "greybeards". And whatever the equivalent term is for the gals. But because the industry has been expanding exponentially, more or less since its inception, the old people are always outnumbered by the young people. And the young people think "more is better" so they always pile on the features. (Now we have young people with LLMs.)

What do y'all think?

Why we should stop using JavaScript according to Douglas Crockford (inventor of JSON) - Honeypot

#solidstatelife #computerscience #programminglanguages