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:
- 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?
- 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.
Latest comments (34)
I'm currently learning Python. They say this language is quite "Friendly".
But then i read this post and you said that "friendly coding language doesn't solve any problems and quite useless", so does that mean that learning Python is useless?
I mean, i aim to Machine Learning but this seems to be so.....lost to me at the moment.
I too, am a beginner in programming
I think the premise of this post is too broad. Having friendly & helpful error messages doesn't make languages automatically easier to learn. Programming at a professional level is just damn hard, because it's not just about learning syntax of a language and how to read error messages.
The current trend of marketing software development education to people that "programming is easy" or that "anyone can pick it up in 6 months in a bootcamp", may be a big disservice and setting them up for failure. Some can and some cannot, but not everyone. I had several friends who tried to go into software testing because of all the hype a few years ago, but just realized it was not for them after wasting a considerable amount of time and money.
Let's use an analogy: many people can learn basics of flying and controlling a small airplane in a "6-months bootcamp" or even in a simulator, but would you entrust them with a big passenger or cargo jet, especially if they find it hard to read one of the controls? How many people actually go through years of training it takes to become a real professional pilot, that can fly anything bigger than a equivalent of sky scooter, capable of making difficult landings in difficult conditions and somebody who really understand the relevant topics in aeronautics, mechanical engineering, customer service, emergency situation management, etc ?
I'm not trying to say that programmers are like pilots, all I'm saying that any profession takes time & dedication, and may not be for everyone. And in some cases having a bit of a technical barrier is inherent to the profession.
I think you are also arguing for "better tools". But better tools don't make it accessible to everyone, nor should they. Planes that are flying now are ages more advanced then 60 years ago. They can practically fly themselves, but does it mean you want everyone to have a pilot license?
Having said that, making readable error messages, while being helpful, isn't a panacea. For example Elm and Elixir and Crystal - all have much better error messages than what "older" languages used to have. But many people still can't easily grok them, especially functional aspects of Elm & Haskell. Even people who've been doing programming for a while. ( This is just anecdotal based on my experiences with other programmers)
I agree, it's not accurate to tell people "programming is easy". Unlike a pilot's license though, there isn't any harm or danger coming from a higher number of people learning an introductory level of programming.
I'd love to hear more about the experiences of people who have invested real time and effort into learning (a bootcamp or something equivalent) and then decided it's not for them. What were the factors that made them reach that conclusion? That would help us understand what we should be saying instead of "programming is easy / anyone can do it".
What are some examples of languages that are designed to be easy to learn and are useless?
Very useful article for frustrated programmers. I would recommend that instead of syntax error, it should display a list of solutions (let's say I mistyped a certain function, the output should be: "Syntax error, and put some suggestions to correct the code"). I know it's hard but once done, it would get viral and highly recommended not just for beginners, but for experts also.
Very Insightful. I teach logic formulation and have taught several programming language (Assembly, BASIC,Pascal, C & C++). To my mind, syntax is easier to hurdle than algorithms. Coders should also acquire fundamental concepts on control and data structures.
This problem is already solved in Ruby; take an eye to the "did_you_mean" gem: github.com/yuki24/did_you_mean
It was created as a separate gem, but it's now part of ruby core. Any ruby syntax error comes now with a nice "did you mean..." with useful suggestions.
This post resonated with me since I started my career as a financial analyst and have been using Excel for 10+ years. I never thought of Excel as "programming," but as I dug deeper into data structures, automating tasks with VBA, and sanitizing data, I got more interested in SQL, data pipelines, and data manipulation using scripts.
Going from Excel to programming was a difficult leap but showed me that there is so much more you can do beyond Excel. I'm not a coder by any stretch of the imagination, but have found a sweet spot with no-code tools. I consider Excel to be in this "no-code" camp. Wrote a post about it here: dev.to/coda/the-overlooked-benefit...
Ok, well you left yourself an "out" by the word "tend" - but I'm going to relate my experience and understanding:
I first started my software engineering path, though I didn't know it at the time, with the first computer I "owned" (ok, my parents bought it) - a TRS-80 Color Computer 2 with 16K of RAM, a TV, and cassette tape "drive" for storage! Woohoo!
Ok - this was in 1984, and truth be told, it wasn't my first computer nor first "programming experience" (prior to that, I had a Milton Bradley Big Trak, which was "programmed" in a very primitive kind of "LOGO" using a simple keypad, and no display).
Anyhow - that first experience was with the built-in language of the computer, Microsoft's "Extended Color BASIC"! And my first error, IIRC - was a syntax error.
Or - more precisely for BASIC:
?SN ERROR IN 10
Honestly I don't recall the real line number, but it was likely "10" because for some reason all BASIC programs started with line 10, and each line increased in multiples of 10. It would be a few years before I learned about structuring a program and setting aside blocks of numbers so I could build things better - but hey, I was only 10 years old...
So - how did that error occur? Well - because I had typed in the code as the book for the computer showed. The thing was, it never said anything about hitting the < ENTER > key at the end of the line (what is the < ENTER > key? Well - it was another name for what we call the RETURN key; strangely, though, some keyboards still have it labeled with the word "Enter" - such as the Model M keyboard I am typing on right now).
I was (a little) familiar with a typewriter - so I hit the spacebar until the "end of the line" on the screen, at which point the cursor jumped to the next line, right under my first line - perfect! From there I continued to type in the code (fortunately, on the Color Computer 2, the initial screen is only 32 characters wide - so "spacing over" wasn't too much of an effort).
Some more "spacing over" - then I typed in RUN, which strangely in the manual did tell you to press the < ENTER > key! And...
?SN ERROR IN 10
But I didn't feel bad about it - it just made me want to find out what I did wrong. With some careful reading (which probably should've been done first - I learned my lesson there!), there was mention of pressing the < ENTER > key at the end of the lines put in. I cleared things out, re-entered the code, typed RUN and < ENTER >...
My world changed. Today, I'm a well paid software engineer who enjoys going into work every day, then coming home and...browsing reddit!
(ok - occasionally I get a bug up my butt and do more coding, but this isn't as often as it was in my teens and 20s; sometimes you need to veg)
That's my tale of my beginnings programming...in BASIC.
Now - BASIC stands for "Beginner's All-purpose Symbolic Instruction Code" - it was a language developed at Dartmouth in the 1960s specifically to be easy for beginners to learn how to program with.
But to say, just because it was (fairly) easy to learn, that it would "tend to be useless" is to do a huge disservice to the language itself.
Was it perfect? No. Did it have rough edges? You bet! But was it useless?
In a business sense?
Hell no!
In fact, there was a whole subset of BASICs created in the 1970s and 80s specifically geared toward business, strangely enough they were termed "Business BASIC" languages. Probably one of the best known of them was "PICK Basic":
en.wikipedia.org/wiki/Pick_operati...
But that isn't to say other BASICs weren't popular for business use purposes; indeed, Microsoft partially built their empire around BASIC. For business, their BASIC compilers of QuickBasic 4.5, PDS 7.1, and Visual Basic 1.0 were the "final DOS BASIC languages" of the early 1990s, and a lot of businesses used and were built on these languages.
Then came VB 3.0 for Windows, and that really changed the business world. Today, there are a ton of VB 6.0 developed software still running businesses, so much so that Microsoft has been virtually forced to keep the runtime available, even now in Windows 10.
But back in the earlier days of personal computing, BASIC was about all you had, because the cost to purchase a compiler for almost any other language (if your system could even use it) could be prohibitive. But usually you could get a simple assembler (or on some machines, like the Apple IIe, you could drop into the ROM monitor and type in the hex opcodes) to help along your BASIC code. I am certain there were businesses out there that used a ton of BASIC on various machines of the era, whether that was an Apple, IBM, TRS-80, or anything else. It was done because it was approachable, a lot of people knew it (built in base of developers), and it was low cost.
I've since seen BASIC pop up in other use cases - for instance, at one point one of the major manufacturers of industrial robot arms could program their arms using a form of BASIC (it was called something like "ROBO-BASIC" or "ARM-BASIC" or something like that; all I ever found was the manual, I never actually used it).
And BASIC today? Well - maybe not used as much for business, but VB still survives (somewhat) in the form of VB.NET. There are also quite a few open source BASICs available - many quite advanced:
qb64.org/
freebasic.net/
rfo-basic.com/
...plus several others out there as well. Oh - and who can forget BASIC for embedded microcontrollers:
store.melabs.com/cat/pbp.html
learn.parallax.com/educators/teach...
Heck - with that last one - it is arguable that Parallax brought microcontrollers to a whole new audience by naming it the "BASIC Stamp" and integrating PBASIC into the system, over a decade before the Arduino!
Toy language? Useless? Hah!
So, I think Hypercard is dead because Apple decided they had something cooler. Also, they had trouble with color. But, a company made SuperCard and had great color. I used that for a while for multimedia educational tools. In fact, you could build stuff with such ease, you have to wonder while people go through so much trouble on the web.
But, SuperCard did not last. And, there was a guy who wrote Revolution with RevTalk. RevTalk is now LiveScript (I think). That is a write once run everywhere system. A Scottish company took it over.
I think that besides QT, LiveScript is one of the best cross-platform solutions out there. But, QT requires more work all around, yet gives you C++. But, LiveScript is about the fastest turn around in development I ever encountered. It needs more love for sure.
As for just rummaging through every computer language known to man and several natural ones, I have to say that I have never been fully satisfied. For complex languages, what you get is a crowd of people who are really snotty about little useless features and you don't get simple development paths. You get lots of hype. For instance, there is a common belief that Python will prevent bad programming from all programmers. That is not true, I have seen horrible programs written in Python. But, that does not make Python bad, it's the hype that's problematic.
I used to think that SETL would be a language in which Set Theory expressions could be used. But, I found out that some guys just wanted to extend the 'set' command line statement found in bash. (Correct me if I am wrong.)
I started a language def of my own. But, of course, who would fund its development? So, it's sort of a joke. github.com/rleddy/acai. I tried to make set theory language parsable. And, I even used the name of a food you might have at breakfast with coffee.
But, if you want to keep me from starving and would like a language that works for you, you could request that I do that and help out the ghost (who is starving) patreon.com/coffeeshopghost. - got to get groceries somehow.
Why do you think it's hard to stop thinking that way later on?
What stops you from picking up the missing principles at a later time?
For a beginner anything is "hard", for example riding a bike is hard, riding a bike off road is even harder and riding a bike down a world cup downhill course is hardest.
Is programming really that hard or are there just bad/lazy developers in the world? I would say the latter. It's a skill where few are great, some a very good, most are good and a lot are bad.
As a developer of 15+ years, I've mostly worked with C, C++ and Python. When I look at python code others have written it's not too often when I think "wow, that was a neat solution". Most of the time I read code I think "wow, that is stupid". Why? Because yes, programming is hard and most programmers I come across hate listening to critique of any code they have written. It comes across as a personal insult and the first human reaction to insult is to defence. If you defend your bad code and don't learn how do you get better? The answer is you don't, and you spill into the pool of "good/bad" programmers and never allow yourself to become "great".
Programming is hard; why should it be easy? Going back to the principle of riding a bike, you can make it easy by adding stabilisers, but your not going far off road with stabilisers and your certainly not going anywhere near a world cup downhill course! I'm all for newbies becoming great, but they need to ensure they are completely open to critique so they can become great.
I find Python error messages to be one of the strongest sides of the language.
I mostly disagree. Natural languages are hard, and that is the problem. The syntax and grammar feel arbitrary. There are no proper tools available to verify if the sentence you constructed produces the correct result.
This is all much easier with programming languages. But when something wrong is detected it needs to be communicated back to the user by means of natural language. This is where the issue surfaces.
Good article. I agree with your assessment of how we got into the current situation. However, I believe the onus is entirely on the developer community to create better paradigms, languages, and tools to assist less technical people in getting stuff done. Computers are crazy powerful, but much of that is locked away for the average person.
On the topic of error messages, have a look at Elm. Great care was paid by the developers to make compiler errors easy to understand for regular humans. It will even show examples and guess at what might fix the problem.
However I think we may be stuck in an old paradigm - textual source files - that's also holding us back. Bret Victor gave an interesting talk on forgotten lessons from decades past at worrydream.com/dbx/. He has also been working on re-imagining a computer as a public space for experimentation that exists in the physical world at dynamicland.org
I am really excited when people are able to think past our current ways of doing things, designed to meet constraints that largely no longer exist. I hope that programming will one day be unrecognizable to us now, and become just another thing you do in your day to day life.
Yes!! Best error messages ever. I have never felt happier as a developer.
ellie-app.com/4XjyF9wJB8na1
Ironically, I'm trying to solve this puzzle these days: making programming more beginner friendly.
One gimmick that I use to address "invalid syntax" issue is...
I show a text with numerous grammatical 3rrors in it. And peple still able 2 read it.
Then I show a working production code with 10k+ lines of code. Then I misspell one 'word' in it, and show how the entire thing breaks.
Then I show an excel sheet with 1000 numbers and show how fast excel can add all of them.
And when I ask humans to do the same. They begin to get the difference ;)
IMHO, the approach to teaching had been created by .. electrical engineers (not programmers) and is long overdue for a complete re-write.
I'm helping kids with their first and second course... what to they start with?
Now if you consider that an 18-20 had been born after consumer console applications were succeeded by GUI apps. And they had never seen or used a console application in their life...
Then what are we doing here?
Are we teaching someone how to drive .. using a car with a manual starter, manual transmission, carburetor and no power steering.
;)
In the end ... programming is simple. So there should be a way of teaching it so that the student goes "yeah it is simple"
Sounds like my car. I like it and learned to drive with it.