The programmers who write programming languages are an elite. When a programmer takes on the task of writing a major programming language, they are creating an essential engineering tool, to be used by literally millions of programmers, so they are focussed on two fantastically important and difficult things:
Reliability. The language will be used in countless ways, testing the very limits of the machine. It must never make a mistake. (There are already so many ways for a program to fail, you need to be sure that the programming language itself is not to blame.)
Speed. The language must never slow down the computer, so that each project can use the full resources of whatever machine it will run on -- from a smartphone to a supercomputer.
It takes a large team of experts -- compiler engineers -- to write a programming language. We’re talking about people who have completely forgotten what it felt like not to know how to code. As a rule, these are also people with unusual cognitive styles and ways of communicating.
Here’s what they’re not worried about: Friendly error messages. This is understandable, especially since friendliness, as a goal, is in direct conflict with speed. A system which is busy checking for problems, so that it can explain the problem to the user, is wasting time. It actually has to approach problems in different, and slower, ways, just so it can run the checks which determine which error message to show.
I should know: I wrote a programming language, along with co-founder Bjorn Hansen.
Now, to be clear, I’m not an elite programmer. Quite the opposite; Real software engineers look at me funny when I suggest solutions to technical problems. They avoid me in the cafeteria.
But I’m a programmer, and I’m creative and stubborn. We decided to write a programming language which would explain mistakes to the user, and by God we did it. My hair was thicker and my beard was darker when we started, but it works. It has hundreds of error messages, and communicates in much clearer ways with the user.
The bad news: It is not fast. It is literally a hundred times slower than real JavaScript. The good news: that doesn’t matter. It’s still fast enough for beginners to write games in.
It is also not reliable. It does not implement a number of advanced features that would completely derail a project at a professional level -- but that doesn’t matter either. It’s not for advanced projects. As long as you use it for beginner-type projects, it’s fine.
In real JavaScript, no matter what mistakes you make, you almost always get one of three or four error messages, or most commonly, no error message at all -- which, if you think about it, is the worst possible thing for tracking down a problem. The designers of JavaScript do not apologize for this; it’s standard practice. And it works OK -- for engineers.
Beginners need something like our little project, though -- something designed for beginners, that is helpful, that explains what you've done wrong.