<p>When asking someone the question, &quot;Which coding languages should a beginner learn?&quot;, the answers I most frequently get are JavaScript or Python.</p>
<p>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.</p>
<p>Which specific elements of a language - not a whole language itself - are 'beginner-friendly'?</p>
<p>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).</p>

<language-design>
What makes a language 'beginner-friendly'?
CC BY-SA 4.0
2024-04-02T05:38:22.143Z
It's being said Python came for readability so why is it at the top of recommended languages for beginners.
Ahmad
CC BY-SA 4.0
2024-04-02T06:36:46.080Z
@Ahmad Sorry, could you clarify your comment? I don't understand what you mean.
Redz
CC BY-SA 4.0
2024-04-02T06:41:22.427Z
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.
Eldritch Conundrum
CC BY-SA 4.0
2024-04-02T07:26:06.253Z
@Redz the reason Python is among the "beginner-friendliness" list is because it was mainly developed for emphasis on code readability, and its syntax allows programmers to express concepts in fewer lines of code. so in addition to what was mentioned above "manage memory manually" if the language can express itself -the syntax- in something close to plain English then you can say it's beginner-friendly
Ahmad
CC BY-SA 4.0
2024-04-02T09:02:22.750Z
Racket. It was specifically designed for teaching programming to high-school students. Especially when paired with the book *How to Design Programs*.
Jörg W Mittag
CC BY-SA 4.0
2024-04-02T16:10:55.293Z
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.
Eric Lippert
CC BY-SA 4.0
2024-04-02T18:10:27.697Z
I think this question needs to be rephrased a bit to make it not opinion-based ─ perhaps asking which features of languages are purported to be beginner-friendly by their designers, which features of languages are backed up by psychological learning theories, or which features have been empirically confirmed to make a language easier for novices.
kaya3
CC BY-SA 4.0
2024-04-02T20:12:53.550Z
The original "beginner-friendly" language was BASIC (the B stands for "Beginner's"). I don't agree that JavaScript is beginner-friendly.
Barmar
CC BY-SA 4.0
2024-04-03T00:47:39.363Z
I think this should be re-opened too (maybe with some edits). But, the general question is sound and worth answering imo.
CoffeeTableEspresso
CC BY-SA 4.0
2024-04-03T00:49:26.917Z
Hooray! I just had a funny conversation with someone about this topic - they looked it up and pointed me to this exact question that I asked, despite the fact that it has not been answered. Google search for the win!
Redz
<p>Adding to the existing answers:</p>
<p>Consider the &quot;beginner&quot; 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.</p>
<p>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.</p>
<p>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 &quot;Hello, world!&quot; program:</p>
<pre><code>#include &lt;stdio.h&gt;

int main(void) {
    printf(&quot;Hello, world!\n&quot;);
}
</code></pre>
<p>Contrast this to Python where this is just a single line, so you don't need to learn about include files and the <code>main()</code> function:</p>
<pre><code>print(&quot;Hello, world!&quot;)
</code></pre>
<p>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.</p>
<p>Writing mathematical equations the way you learn in school is one aspect. Another is using appropriate words for certain things, like <code>if</code> for condition statements, and <code>for</code>/<code>while</code> for loops.</p>
<p>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.</p>

CC BY-SA 4.0
2024-04-08T21:34:06.303Z
2024-04-08T21:34:06.303Z
G. Sliepen
<p><a href="https://scratch.mit.edu/" rel="noreferrer">Scratch</a> was the first language I learned, and is very popular even today. Scratch is a bit more than &quot;beginner-friendly&quot;: it's designed for <em>absolute</em> beginners, particularly young children, and it's far different than a traditional language. Here are some of the things that make Scratch beginner-friendly:</p>
<ul>
<li>Scratch is <strong>block-based</strong>. 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 &quot;holes&quot; nested blocks fit into. Examples:
<ul>
<li>A loop has a small &quot;hole&quot; with ridges that make it so only statement blocks fit in the loop body.</li>
<li>A &quot;start&quot; block has a capped top so no block can connect above, and a &quot;stop&quot; block has a flat bottom so no block can connect below</li>
<li>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.</li>
</ul>
</li>
<li>The blocks are also color-coded by their semantics, e.g. movement blocks are blue, control-flow blocks are orange.</li>
</ul>
<p><a href="https://i.sstatic.net/LQQtT.png" rel="noreferrer"><img src="https://i.sstatic.net/LQQtT.png" alt="Scratch blocks" /></a></p>
<ul>
<li>Scratch is <strong>extremely interactive and high-level</strong>. The &quot;IDE&quot; 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.</li>
</ul>
<p><a href="https://i.sstatic.net/YiaWL.png" rel="noreferrer"><img src="https://i.sstatic.net/YiaWL.png" alt="Scratch IDE" /></a></p>
<ul>
<li><p>Scratch is very <strong>concrete</strong>. There aren't as many abstract concepts as other languages. e.g. instead of classes, there are &quot;sprites&quot; (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 &quot;move ( ) steps&quot;; these blocks also hide complexity, like trigonometry in the &quot;move ( ) steps&quot; 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.</p>
</li>
<li><p>Scratch lets you make <strong>interesting</strong> 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.</p>
</li>
</ul>
<p><a href="https://i.sstatic.net/JkDz9.png" rel="noreferrer"><img src="https://i.sstatic.net/JkDz9.png" alt="Simple scratch game" /></a></p>
<ul>
<li>While not part of the language itself, it's absolutely essential for beginners: Scratch has a <strong>large community and online resources</strong>. The Scratch developers knew this, they released the project alongside the website that let you upload and share content as well as access forums.</li>
</ul>
<p><a href="https://i.sstatic.net/oJ5BQ.png" rel="noreferrer"><img src="https://i.sstatic.net/oJ5BQ.png" alt="Front page" /></a></p>
<ul>
<li><strong>Remixing</strong> 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.</li>
</ul>
<p><a href="https://i.sstatic.net/o5trw.png" rel="noreferrer"><img src="https://i.sstatic.net/o5trw.png" alt="Remix Tree" /></a></p>
<p>Image sources (all from <a href="https://en.scratch-wiki.info/wiki/Scratch_Wiki_Home" rel="noreferrer">the Scratch Wiki</a> and under Creative Commons, except one I took on the main site which is also <a href="https://en.scratch-wiki.info/wiki/Scratch_Project_License" rel="noreferrer">CC</a>):</p>
<ol>
<li><a href="https://en.scratch-wiki.info/wiki/File:TOC_blocks_3.0.png" rel="noreferrer">https://en.scratch-wiki.info/wiki/File:TOC_blocks_3.0.png</a></li>
<li><a href="https://en.scratch-wiki.info/wiki/File:Scratch_3.0_Program.png" rel="noreferrer">https://en.scratch-wiki.info/wiki/File:Scratch_3.0_Program.png</a></li>
<li>Screenshot</li>
<li><a href="https://en.scratch-wiki.info/wiki/File:3.0_Homepage.PNG" rel="noreferrer">https://en.scratch-wiki.info/wiki/File:3.0_Homepage.PNG</a></li>
<li><a href="https://en.scratch-wiki.info/wiki/File:RemixVisualization.png" rel="noreferrer">https://en.scratch-wiki.info/wiki/File:RemixVisualization.png</a></li>
</ol>

CC BY-SA 4.0
2024-04-03T05:33:06.593Z
2024-04-03T20:49:26.113Z
2024-04-03T20:49:26.113Z
tarzh
CC BY-SA 4.0
2024-04-05T15:33:43.263Z
Scratch is the first language many of us learned. It is indeed great for learning.
Seggan
<p>I think this question is still verging on too broad, but I'll give a high-level overview of a number of relevant areas.</p>
<p>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 <em>is</em> examined that we don't necessarily know which.</p>
<p>There just aren't as many actual experiments looking at programming-language design <em>in total</em> as you might expect — <a href="https://jyx.jyu.fi/handle/123456789/47698" rel="noreferrer">Antti-Juhani Kaijanaho's 2012 PhD thesis</a> 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.</p>
<hr />
<p>The most significant recent study on language <em>syntax and keywords</em> for novices comes from Andreas Stefik and Susanna Siebert in 2013, <a href="https://doi.org/10.1145/2534973" rel="noreferrer">An Empirical Investigation into Programming Language Syntax</a> (<sub>ACM Trans. Comput. Educ. 13, 4, Article 19 (November 2013), 40 pages.</sub>). Some of the results there are likely to be surprising, while others are obvious at least in retrospect. Overall, the major takeaways are that</p>
<ul>
<li><p>Use of <strong>words rather than symbols</strong> generally helps matters, but ...</p>
</li>
<li><p>... the <strong><em>typical</em> words</strong> used in programming languages are <strong>not very effective</strong>.</p>
<p>For example, terms like &quot;foreach&quot;, &quot;while&quot;, and &quot;for&quot; perform very poorly, while data type names like &quot;float&quot; and &quot;string&quot; don't do well either.</p>
</li>
<li><p><strong>Metaphorical terms are especially weak</strong>: things like throw and catch do worse than &quot;error&quot; — but for both.</p>
</li>
<li><p>In general, <strong>using fewer tokens</strong> to express something performs better than using more, but this is in tension with using helpful non-symbolic terms.</p>
</li>
<li><p>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 <code>cout</code> tested very favourably for output).</p>
</li>
</ul>
<p>When experimenting on whole languages, Ruby, Python, and their <a href="https://quorumlanguage.com/" rel="noreferrer">Quorum</a> language performed best. However, these experiments were still only in an artificial environment and did not measure learning, only accuracy.</p>
<hr />
<p>There is a reasonable amount of evidence that <strong>static typing produces better results</strong> for novice programmers by catching their errors, but also that <strong>type <em>annotations</em> produce more syntax errors</strong> 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 &quot;more tokens&quot; issue again.</p>
<p><strong>Block-based programming</strong> environments, which prevent the creation of various kinds of syntax and type error, have been shown to <strong>perform better with novices than textual languages</strong> even when the language is otherwise identical, such as by Thomas W. Price and Tiffany Barnes in 2015, <a href="https://doi.org/10.1145/2787622.2787712" rel="noreferrer">Comparing Textual and Block Interfaces in a Novice Programming Environment</a> (<sub>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. <a href="https://doi.org/10.1145/2787622.2787712" rel="noreferrer">https://doi.org/10.1145/2787622.2787712</a></sub>); 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.</p>
<p>&quot;Good&quot; error messages do increase learner performance, but those that are &quot;too helpful&quot; are counterproductive, especially if they can make a bad guess about the user's intent. A substantial number of novices will &quot;freeze&quot; 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, <a href="https://doi.org/10.1080/08993408.2016.1225464" rel="noreferrer">Effective Compiler Error Message Enhancement for Novice Programming Students</a> (<sub>Computer Science Education 26, no. 2–3 (2016): 148–75. doi:10.1080/08993408.2016.1225464</sub>). 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.</p>
<p>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 &quot;stumble&quot; 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 <code>static</code> 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.</p>
<p>Although the language &quot;paradigm&quot; 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.</p>
<p>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 <strong>the spreadsheet</strong>, a spatial dataflow language. These do have <a href="https://eusprig.org/research-info/research-and-best-practice/" rel="noreferrer">very high error rates</a>, but immediate accessibility that virtually no other programming environment matches. The true answer for a randomly-selected &quot;beginner&quot; is probably Excel.</p>
<hr />
<p>Other topics I won't touch on more, but are worth keeping in mind also:</p>
<ul>
<li>There is a concept in educational psychology called <em>transfer</em>. 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 &quot;similar enough&quot; to what they have been using already then this will happen for free, but research does <em>not</em> bear that out. A language that is merely similar to one the learner may want to use in future may not be helpful.</li>
<li>In considering your starting question, &quot;Which coding languages should a beginner learn?&quot;, 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.</li>
<li>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 &quot;exit path&quot; from novice-specific languages that is much harder to navigate alone.</li>
<li>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.</li>
<li>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.</li>
</ul>
<p>Broad overviews of the long-standing research on learning programming are in</p>
<ul>
<li>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.</li>
<li>Anthony Robins, Janet Rountree, and Nathan Rountree. Learning and teaching programming: A review and discussion. Computer Science Education, 13:137–172, 2003</li>
<li>And Section 2.1 of my <a href="https://michael.homer.nz/Thesis" rel="noreferrer">thesis</a> has a (somewhat cynical) overview of the state of the field at the time.</li>
</ul>

CC BY-SA 4.0
2024-04-03T05:03:42.473Z
2024-04-03T05:03:42.473Z
Michael Homer
CC BY-SA 4.0
2024-04-04T03:29:06.150Z
What an excellent answer!!
apropos
CC BY-SA 4.0
2024-04-04T09:30:45.297Z
Did they propose any better alternatives? For example, if `for` and `foreach` perform poorly for comprehension, how else might one express the idea tersely?
Karl Knechtel
CC BY-SA 4.0
2024-04-04T17:55:04.070Z
@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.
Michael Homer
CC BY-SA 4.0
2024-04-05T08:12:18.337Z
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.
Karl Knechtel
CC BY-SA 4.0
2024-04-08T03:35:55.797Z
Looking into it further, it doesn't appear that Quorum actually offers any high-level syntax for iterating over a collection... ? I saw some interesting ideas, but many other things that seem rather questionable to me.
Karl Knechtel
CC BY-SA 4.0
2024-04-08T04:03:49.553Z
@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.
Michael Homer
CC BY-SA 4.0
2024-04-08T13:40:02.357Z
Good catch on _the spreadsheet_. Definetely a very useful tool to start learning "computational thinking", and also start tinkering.
Pablo H
# What makes a language 'beginner-friendly'?
Posted by: username_0 on 2024-04-02
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).
**Tags:** language-design
> **Comments:**
> **username_1**: It's being said Python came for readability so why is it at the top of recommended languages for beginners.  
> **username_0**: @Ahmad Sorry, could you clarify your comment? I don't understand what you mean.  
> **username_2**: 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.  
> **username_1**: @Redz the reason Python is among the "beginner-friendliness" list is because it was mainly developed for emphasis on code readability, and its syntax allows programmers to express concepts in fewer lines of code. so in addition to what was mentioned above "manage memory manually" if the language can express itself -the syntax- in something close to plain English then you can say it's beginner-friendly  
> **username_3**: Racket. It was specifically designed for teaching programming to high-school students. Especially when paired with the book *How to Design Programs*.  
> **username_4**: 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.  
> **username_5**: I think this question needs to be rephrased a bit to make it not opinion-based ─ perhaps asking which features of languages are purported to be beginner-friendly by their designers, which features of languages are backed up by psychological learning theories, or which features have been empirically confirmed to make a language easier for novices.  
> **username_6**: The original "beginner-friendly" language was BASIC (the B stands for "Beginner's"). I don't agree that JavaScript is beginner-friendly.  
> **username_7**: I think this should be re-opened too (maybe with some edits). But, the general question is sound and worth answering imo.  
> **username_0**: Hooray! I just had a funny conversation with someone about this topic - they looked it up and pointed me to this exact question that I asked, despite the fact that it has not been answered. Google search for the win!  
---
## 3 answers
### Answer by username_11 on 2024-04-03. Score: 22
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](https://jyx.jyu.fi/handle/123456789/47698) 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](https://doi.org/10.1145/2534973) (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](https://quorumlanguage.com/) 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](https://doi.org/10.1145/2787622.2787712) (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](https://doi.org/10.1080/08993408.2016.1225464) (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](https://eusprig.org/research-info/research-and-best-practice/), 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](https://michael.homer.nz/Thesis) has a (somewhat cynical) overview of the state of the field at the time.
> **Comments:**
> **username_12** (2024-04-04): What an excellent answer!!  
> **username_13** (2024-04-04): Did they propose any better alternatives? For example, if `for` and `foreach` perform poorly for comprehension, how else might one express the idea tersely?  
> **username_11** (2024-04-04): @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.  
> **username_13** (2024-04-05): 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.  
> **username_13** (2024-04-08): Looking into it further, it doesn't appear that Quorum actually offers any high-level syntax for iterating over a collection... ? I saw some interesting ideas, but many other things that seem rather questionable to me.  
> **username_11** (2024-04-08): @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.  
> **username_14** (2024-04-08): Good catch on _the spreadsheet_. Definetely a very useful tool to start learning "computational thinking", and also start tinkering.  
---
### Answer by username_9 on 2024-04-03. Score: 10
[Scratch](https://scratch.mit.edu/) 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](https://i.sstatic.net/LQQtT.png)](https://i.sstatic.net/LQQtT.png)

* 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](https://i.sstatic.net/YiaWL.png)](https://i.sstatic.net/YiaWL.png)

* 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](https://i.sstatic.net/JkDz9.png)](https://i.sstatic.net/JkDz9.png)

* 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](https://i.sstatic.net/oJ5BQ.png)](https://i.sstatic.net/oJ5BQ.png)

* **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](https://i.sstatic.net/o5trw.png)](https://i.sstatic.net/o5trw.png)

Image sources (all from [the Scratch Wiki](https://en.scratch-wiki.info/wiki/Scratch_Wiki_Home) and under Creative Commons, except one I took on the main site which is also [CC](https://en.scratch-wiki.info/wiki/Scratch_Project_License)):

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>
> **Comments:**
> **username_10** (2024-04-05): Scratch is the first language many of us learned. It is indeed great for learning.  
---
### Answer by username_8 on 2024-04-08. Score: 2
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 

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.
---
