When asking someone the question, "Which coding languages should a beginner learn?", the answers I most frequently get are JavaScript or Python.

In both cases, a big reason for being beginner-friendly is that they read like English - however, many other coding languages do as well. Meanwhile, 'harder' languages like Assembly may be harder to read - not English based.

Which specific elements of a language - not a whole language itself - are 'beginner-friendly'?

In specific, I am looking for elements that fall into one of two categories - first, syntax and appearance (such as Python's emphasis on code readability) - and second, language functionality (such as Eldritch Conundrum's comment about easy ways to visualize everything).

  • 2
    $\begingroup$ @Ahmad Sorry, could you clarify your comment? I don't understand what you mean. $\endgroup$
    – Redz
    Apr 2 at 6:36
  • 7
    $\begingroup$ Not having to manage memory manually is beginner-friendly because it lets them focus on what they're trying to do. Short feedback loops are important when learning, so the language should be interactive. There should be easy ways to visualize everything, with readable default string representations of data. $\endgroup$ Apr 2 at 6:41
  • 1
    $\begingroup$ Racket. It was specifically designed for teaching programming to high-school students. Especially when paired with the book How to Design Programs. $\endgroup$ Apr 2 at 9:02
  • 1
    $\begingroup$ This is a perfectly reasonable question for language designers to consider and should be reopened. I just now had a very interesting conversation with a Dutch professor of CS on this exact question and there is a lot to say about it. $\endgroup$ Apr 2 at 16:10
  • 3
    $\begingroup$ The original "beginner-friendly" language was BASIC (the B stands for "Beginner's"). I don't agree that JavaScript is beginner-friendly. $\endgroup$
    – Barmar
    Apr 2 at 20:12

3 Answers 3


I think this question is still verging on too broad, but I'll give a high-level overview of a number of relevant areas.

One challenge with this question is that the evidence base is much thinner than you might expect, and much of the wisdom floating around isn't based on anything much, and quite often does not hold up when examined — but so little is examined that we don't necessarily know which.

There just aren't as many actual experiments looking at programming-language design in total as you might expect — Antti-Juhani Kaijanaho's 2012 PhD thesis identifies somewhere between 37 and 137, depending on your inclusion criteria, and there haven't been vast numbers since then. Many of those are not specifically relevant to beginners.

The most significant recent study on language syntax and keywords for novices comes from Andreas Stefik and Susanna Siebert in 2013, An Empirical Investigation into Programming Language Syntax (ACM Trans. Comput. Educ. 13, 4, Article 19 (November 2013), 40 pages.). Some of the results there are likely to be surprising, while others are obvious at least in retrospect. Overall, the major takeaways are that

  • Use of words rather than symbols generally helps matters, but ...

  • ... the typical words used in programming languages are not very effective.

    For example, terms like "foreach", "while", and "for" perform very poorly, while data type names like "float" and "string" don't do well either.

  • Metaphorical terms are especially weak: things like throw and catch do worse than "error" — but for both.

  • In general, using fewer tokens to express something performs better than using more, but this is in tension with using helpful non-symbolic terms.

  • Neither beginners nor more-experienced programmers are very consistent in just about any facet, except that the experienced programmers favour the choices they're accustomed to (for example, the term cout tested very favourably for output).

When experimenting on whole languages, Ruby, Python, and their Quorum language performed best. However, these experiments were still only in an artificial environment and did not measure learning, only accuracy.

There is a reasonable amount of evidence that static typing produces better results for novice programmers by catching their errors, but also that type annotations produce more syntax errors for them. The most well-known work in this vein is by Stefan Hanenberg, but it has been replicated a few times. Pedagogical experience reports often highlight the latter point as more significant at the very beginning — it's that "more tokens" issue again.

Block-based programming environments, which prevent the creation of various kinds of syntax and type error, have been shown to perform better with novices than textual languages even when the language is otherwise identical, such as by Thomas W. Price and Tiffany Barnes in 2015, Comparing Textual and Block Interfaces in a Novice Programming Environment (In Proceedings of the eleventh annual International Conference on International Computing Education Research (ICER '15). Association for Computing Machinery, New York, NY, USA, 91–99. https://doi.org/10.1145/2787622.2787712); there has also been significant work by David Weintrop and others. However, while these provide good support in the early stages of learning, they can also impose meaningful exit friction when the novice advances beyond what the block environment gives them. Most block environments also provide very easy access to graphical or interactive primitives, and may show live stepping or other debugging affordances.

"Good" error messages do increase learner performance, but those that are "too helpful" are counterproductive, especially if they can make a bad guess about the user's intent. A substantial number of novices will "freeze" when there are many error or even warning indicators given to them, but presenting all errors at once outperforms one-at-a-time reporting. Allowing erroneous programs to run partially has shown some effectiveness. Improvements to error reporting have been studied among others by Becker, Brett A., Graham Glanville, Ricardo Iwashima, Claire McDonnell, Kyle Goslin, and Catherine Mooney in 2016, Effective Compiler Error Message Enhancement for Novice Programming Students (Computer Science Education 26, no. 2–3 (2016): 148–75. doi:10.1080/08993408.2016.1225464). Negative responses to error messages perceived as directed at the user are common in new learners and the phrasing and content needs to be balanced carefully.

Limited sub-languages that progress towards the unrestricted language have shown value as far back as SP/k, but it is Racket more recently that has brought them to the fore. The advantage these systems provide is that learners do not "stumble" into advanced functionality they didn't intend to reach; this sometimes happens when error messages lead them astray (a common anecdote is a novice who turns their entire Java program static after they try to fix an error saying they are unable to access an instance method or field). However, these limited languages also introduce more kinds of error and more ways for the learner to go wrong.

Although the language "paradigm" seems like it should form a major component of the answer, the evidence for and against functional, imperative, object-oriented, procedural, ... models for learners is very mixed over time. There does not seem to be a strong recommendation that could be made in isolation backed by anything but personal assertion (and many have done so). The other aspects already mentioned, and any structured teaching wrapped around it, are much bigger factors.

Finally, and this is a bit out of left field, the programming language that the most beginners pick up unassisted and to productive use is the spreadsheet, a spatial dataflow language. These do have very high error rates, but immediate accessibility that virtually no other programming environment matches. The true answer for a randomly-selected "beginner" is probably Excel.

Other topics I won't touch on more, but are worth keeping in mind also:

  • There is a concept in educational psychology called transfer. A beginner won't be a beginner forever, and if they soon have to move on to another language they likely will not be able to transfer what they've learned already easily, unless they have directed instruction guiding them. It's often assumed that if the new target is "similar enough" to what they have been using already then this will happen for free, but research does not bear that out. A language that is merely similar to one the learner may want to use in future may not be helpful.
  • In considering your starting question, "Which coding languages should a beginner learn?", there are a lot of other elements outside of the language designs themselves, and these are likely to dominate in practice. Those with significant communities or commercial appeal are often going to be better choices than those more ideal for a beginner to learn.
  • If the beginner is to pick up the language on their own, the answer is likely different to if it is to be taught to them. In particular, teaching with explicit bridging content can allow the "exit path" from novice-specific languages that is much harder to navigate alone.
  • Localisation is a significant issue, particularly for younger learners. Learning keywords and following already-opaque error messages in an unknown language is very challenging, but localised languages often fall short on the previous point and have not had the engineering work of the larger languages.
  • Accessibility varies significantly by the tooling, more so than the language, but these are often very correlated. IDE support for screenreaders and other assistive technology varies greatly, and some language families have a much worse time than others.

Broad overviews of the long-standing research on learning programming are in

  • Arnold Pears, Stephen Seidman, Lauri Malmi, Linda Mannila, Elizabeth Adams, Jens Bennedsen, Marie Devlin, and James Paterson. A survey of literature on the teaching of introductory programming. In Working Group Reports on ITiCSE on Innovation and Technology in Computer Science Education, ITiCSE-WGR ’07, pages 204–223, New York, NY, USA, 2007. ACM.
  • Anthony Robins, Janet Rountree, and Nathan Rountree. Learning and teaching programming: A review and discussion. Computer Science Education, 13:137–172, 2003
  • And Section 2.1 of my thesis has a (somewhat cynical) overview of the state of the field at the time.
  • $\begingroup$ What an excellent answer!! $\endgroup$
    – apropos
    Apr 4 at 3:29
  • 1
    $\begingroup$ Did they propose any better alternatives? For example, if for and foreach perform poorly for comprehension, how else might one express the idea tersely? $\endgroup$ Apr 4 at 9:30
  • $\begingroup$ @KarlKnechtel The most successful keywords in that category were “repeat”, “again”, and “loop” for non-programmers. Both “loop” and “repeat” were strong with the programmer group as well. $\endgroup$
    – Michael Homer
    Apr 4 at 17:55
  • $\begingroup$ I'm having difficulty imagining how to distinguish for loops from while loops in that context, or how to make it sound natural without adding those sorts of words back in... would be nice to have access to the paper. $\endgroup$ Apr 5 at 8:12
  • 1
    $\begingroup$ @KarlKnechtel Well, I’m not going to endorse Quorum itself particularly, but the result that those keywords I mentioned were unintuitive to novices is independent of their subsequent work (and was pretty well-known before then too; many pedagogical reports note the same issue and probably anyone who’s taught introductory programming has seen it, so it would not have been surprising). Constructing more successful iteration mechanisms is a different, harder project, and that’s just an illustration of one element to be considered alongside everything else. There are questions to ask about Quorum. $\endgroup$
    – Michael Homer
    Apr 8 at 4:03

Scratch was the first language I learned, and is very popular even today. Scratch is a bit more than "beginner-friendly": it's designed for absolute beginners, particularly young children, and it's far different than a traditional language. Here are some of the things that make Scratch beginner-friendly:

  • Scratch is block-based. You can't create bad syntax because the blocks are all valid syntactic forms and only connect in valid ways. The blocks immediately also give intuition for how they fit together from their shape and the shape of the "holes" nested blocks fit into. Examples:
    • A loop has a small "hole" with ridges that make it so only statement blocks fit in the loop body.
    • A "start" block has a capped top so no block can connect above, and a "stop" block has a flat bottom so no block can connect below
    • Expression blocks have different sides depending on their type, e.g. numeric blocks have rounded corners and boolean blocks have triangular corners. Statement blocks have flat sides and ridged tops and bottoms.
  • The blocks are also color-coded by their semantics, e.g. movement blocks are blue, control-flow blocks are orange.

Scratch blocks

  • Scratch is extremely interactive and high-level. The "IDE" shows the running program, and you can pause, step through, and edit the program during execution. The image and sound editors are integrated so there is no friction from having to switch to an external tool.

Scratch IDE

  • Scratch is very concrete. There aren't as many abstract concepts as other languages. e.g. instead of classes, there are "sprites" (singletons) that always exist on the scene rather than having to be configured and added. Sprites all have built-in properties like position and rotation, which can be affected by blocks like "move ( ) steps"; these blocks also hide complexity, like trigonometry in the "move ( ) steps" block. You can create variables and custom blocks (functions) but many projects exist without them, since the built-in sprite properties and other blocks provide enough expressiveness on their own.

  • Scratch lets you make interesting things with minimal effort. Whereas other languages like Python start at the command line and take a long time and a lot of setup to get graphics, a few blocks are enough to make a tiny interactive Scratch program. Many genuinely interesting projects in Scratch have only a little code and that code is very simple.

Simple scratch game

  • While not part of the language itself, it's absolutely essential for beginners: Scratch has a large community and online resources. The Scratch developers knew this, they released the project alongside the website that let you upload and share content as well as access forums.

Front page

  • Remixing is an essential feature of the Scratch website. It encourages taking existing projects and editing them. Besides illuminating how other people solved problems, it makes it even easier to get started: you can take someone else's project and change a few blocks (or even just edit the graphics) and have something of your own right away.

Remix Tree

Image sources (all from the Scratch Wiki and under Creative Commons, except one I took on the main site which is also CC):

  1. https://en.scratch-wiki.info/wiki/File:TOC_blocks_3.0.png
  2. https://en.scratch-wiki.info/wiki/File:Scratch_3.0_Program.png
  3. Screenshot
  4. https://en.scratch-wiki.info/wiki/File:3.0_Homepage.PNG
  5. https://en.scratch-wiki.info/wiki/File:RemixVisualization.png
  • 1
    $\begingroup$ Scratch is the first language many of us learned. It is indeed great for learning. $\endgroup$
    – Seggan
    Apr 5 at 15:33

Adding to the existing answers:

Consider the "beginner" itself: it is someone who just started programming, doesn't know the progamming language yet, and is trying to solve some simple problems. They will have some basic knowledge though; already in primary school children will learn some mathematics and logical reasoning, and of course they know at least one human language.

So a beginner friendly programming language is one that leverages the knowledge beginners already have, and makes it easy to solve easy problems. Also, the less things you have to learn, the better. So the language should provide a small set of basic tools that are easy to understand but are as useful as possible. Of course, that doesn't preclude that same language from having more complex features that are harder to understand, as long as they are not necessary for the initial problems beginners are working on.

You can use this to understand why some languages are more beginner friendly than otehrs. For example, while C isn't a very complicated language, it still requires you to understand a lot of things before you can even write a simple "Hello, world!" program:

#include <stdio.h>

int main(void) {
    printf("Hello, world!\n");

Contrast this to Python where this is just a single line, so you don't need to learn about include files and the main() function:

print("Hello, world!")

A visual language with a good IDE might be even simpler, as there it guides the programmer more and they can just click around to discover things.

Writing mathematical equations the way you learn in school is one aspect. Another is using appropriate words for certain things, like if for condition statements, and for/while for loops.

Of course, at some point the beginner is no longer a beginner, and they might want to do some more complex programming. Ideally, there is a smooth learning curve, and the language provides more advanced features to reduce the amount of effort needed to write complex programs. Some beginner friendly languages fail in this regard.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .