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?