Years ago when I first tried learning Python, within the first five minutes of playing around with it I encountered one of these error messages:

SyntaxError: invalid syntax

It sounded like Python was telling me: you did something bad, and you should feel bad.

I did feel bad, in part because I had no idea what a SyntaxError meant, and the phrase "invalid syntax" didn't help clarify anything at all.

Today, I know a lot more about programming languages and about how parsers work. But the error message is still bad. It's bad UX, or more precisely: bad DX (developer experience).

If you're learning programming for the first time, then the error is a bad experience on two levels:

1. First, it doesn't tell you what just happened. Did I do something wrong? Did my program do something wrong? Or did Python do something wrong?
2. Second, it offers no indication of what the reason for the error might be, or what I could try to do to fix it.

Now, the reality is that syntax errors happen all the time (even after years of experience) and that most of a developer's life is spent fixing bugs and troubleshooting all kinds of coding problems.

But as a beginner, you don't know that.

When you're a beginner, this error actually sounds like it's a big deal, and more critically, it sounds like you did something wrong.

The problem: programming languages are created by programmers

Programming languages are created by programmers, for programmers.

That's a problem when you want to make programming more accessible and easier to learn. It's a target audience mismatch.

On top of that, there are limitations that come from how programming languages are created. We end up with messages like "invalid syntax" not just because someone wrote the error message like that, but because of the way that the language grammar and parser work. Maybe the parser actually doesn't have access to the exact grammar rule that caused the syntax error, because it was coded that way. So the error message isn't capable of being more helpful for technical reasons.

It's very likely that it just wasn't one of the priorities for Guido when he was writing the first version of the Python parser. He was writing it for himself and for other programmers.

After all, when Python was first released in the early 1990s, it was already much simpler and easier to learn than most other languages at the time. (I think that might still be true today.)

A secondary problem: programming languages which are designed to be easy to learn tend to be useless

There are lots of programming languages that are designed to be easier to learn and to be accessible to beginners. Very few of them are successful or popular, and the problem is that you can't do any serious work with them.

They may achieve their goal of making it easier for people to get started with programming. But a lot of the time they fail to illustrate what problems programming can solve, and how it fits into a bigger picture.

So in a way, they actually sabotage themselves before they can fulfill their goal.

If you want to show people why programming is worthwhile and help them understand how they can use it, you need to show them how to solve a real-world problem. Otherwise, most of the time, it ends up looking like a toy.

HyperCard and Excel

HyperCard was one of those applications that emerged in the late 1980s that had an influence on a huge number of computer users and I would bet that it inspired a lot of people to become programmers.

The programming language that was available inside of HyperCard, called HyperTalk, wasn't particularly great. But it was aimed at non-programmers while at the same time being capable enough to solve real problems.

Many people who thought they would never be able to program a computer started using HyperCard for many automation and prototyping tasks, a surprise even to its creator. (Wikipedia)

Excel is the other application that was huge in bringing programming to non-programmers.

Based just on formulas and cells, Excel's model managed to be half-code and half-graphical. It's generic enough to solve a whole range of problems, but it still sticks to a sweet spot: it's specific to problems that can be expressed as a spreadsheet. That's what keeps Excel so powerful: it doesn't try to do everything. It's a spreadsheet.

Making a tool customizable until it becomes a poorly designed programming language

In software, we're always faced with a trade-off between writing code that solves a specific solution, and writing code that allows the user enough customizability to solve a wide variety of problems.

It's the tool specificity problem.

Excel and HyperCard are tools, not programming languages. But both of them were pulled in the direction away from specificity, to try to solve all problems for everyone.

What's the most customizable form of a piece of software? It's a programming language itself. So if you take those tools to an extreme point of customizability, they become poorly designed programming languages.

Why is HyperCard dead today? I think it's because it was too generic and wasn't a perfect fit for any specific problem.

While it did put a lot of power into the hands of non-programmers, eventually it turned out that the economics of software is such that it's usually more worthwhile to have specific tools built for specific problems.

Programmers solve their own problems

It's normal to expect that if you leave programmers to their own devices, they're going to make tools to make their own work easier.

Sometimes programmers are guilty of a certain kind of elitism, where they put up barriers to entry instead of making things easier for newcomers.

Once you get past the initial hurdles and you learn how to write code, you start to forget what it felt like when you were just getting started.

It's remarkably easy to forget how helpless you felt when you were trying to learn the basic syntax of your first programming language and everything seemed stacked against you.

Everyone starts out as a beginner.

So, what can we do to make things better?

Rants aside, here are some actionable suggestions.

• If you're an experienced coder, share stories about your first encounters with programming to show that we all start out clueless and intimidated before we got the hang of it.
• If you're a beginner, try to forgive the creators of programming languages for the cryptic and unhelpful error messages. Creating a programming language is a lot of work, and it's not always obvious how to make it easy for beginners while also making it useful for solving real problems.
• Also if you're a beginner, you can help the programming language community by sharing your experiences and your feedback. A lot of the time, the experienced programmers need a reminder that beginners don't see things the same way that they do, and they need to snap back to reality sometimes.
• Forgive the beginner-friendly programming languages if you can't make anything useful with them. They can still be worthwhile learning tools, and if they can get people excited to learn more about programming in general, then that's the best we can hope for.

Let me close with one last thing.

I was too harsh above when I called those languages useless, but I meant it in relation to real-world, so-called "business" problems.

If you can use a tool to make cool or creative things and then show those things off, then that tool is 100% useful and valuable to humanity. Let's make more of those.