Bachelor Degree Project

Designing an Introductory Programming Language

Based on Studies on Novices

Author: Linnea Jansson

Supervisor: Dr. Jonas Lundberg
Semester: Spring 2022
Department: Computer Science
Dedicated to the loving memory of my father who has taught me compassion,
dedication, and the meaning of selflessness. I am forever grateful to him for making
me a better person.
 Abstract
The challenges of learning programming have been revealed in studies for decades.
Many of the difficulties and misconceptions derive from, or go unassisted by, the
syntax and semantics of the programming language used in introductory (CS1)
courses. Despite the plethora of empirical data available, the designs of common
general-purpose languages have arguably not been based on such data, possibly
being one explanation to why novices continue to struggle. Through a literature
review, this article first reviews what languages are commonly used in CS1 courses,
studies on difficulties and misconceptions held by novices, and other factors that can
be exploited in the design of more suitable introductory languages. Thereafter, a new
text-based general-purpose programming language called Frendli is introduced, as
well as the justifications for design decisions based on the findings presented. The
language is intended for use in the beginning stages of introductory courses. The
literature review revealed that novices often struggle with understanding
fundamental concepts such as function parameters, return values, the need for
variable declarations, and the order of execution. It also demonstrated that several
syntactic and semantic design features of both C-style languages like Java and
syntactically simpler ones like Python are problematic for novices. The author would
argue that a language used for teaching programming should intuitively convey
universal programming concepts through its syntax, minimize interference and
ambiguity of syntax, and have syntactic and semantic consistency. Designing
languages based on studies on novices can hopefully assist students in their learning
and instructors in their teaching.
Keywords: programming language, syntax, introductory programming, difficulties,
misconceptions.
Acknowledgements

I wish to express my sincere thanks to my supervisor Dr. Jonas Lundberg for providing
guidance and support through the process of writing this thesis. His honest and valuable
feedback allowed me to increase the quality of my work. I would also like to thank the
second reader of this thesis, Tobias Andersson-Gidlund, for contributing with an outside
perspective and with input that could have otherwise been overlooked. Lastly, I am
grateful to my mother and sisters for their unconditional support.
Contents

1 Introduction 1
1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Problem Formulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.6 Target Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.7 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Related Work 5
2.1 Influential Studies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Research Methodology 7
3.1 Literature Review Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Defining Search Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3 Conducting Searches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4 Selecting and Filtering Studies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.5 Reliability and Validity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.6 Ethical Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

4 Literature Review 11
4.1 Language Choice in Introductory Programming . . . . . . . . . . . . . . . . . . . . . . 11
4.2 Intrinsic Complexity and Cognitive Load . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3 Difficulties in Introductory Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3.2 Constructs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3.3 Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.4 Misconceptions and Non-Viable Mental Models . . . . . . . . . . . . . . . . . . . . . . 21
4.5 Language Design for Introductory Programming . . . . . . . . . . . . . . . . . . . . . 25
4.5.1 Pedagogical Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.5.2 Design Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5 Frendli – The New Programming Language 28
5.1 Goals and Syntactic Design Strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.1.1 Novice-Oriented . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.1.2 Action-Based . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.1.3 Low-Conflict . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.2 Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2.1 Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2.2 Comments and Blank Lines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2.3 Indentation, Block, and Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2.4 Identifiers and Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2.5 Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.2.6 Expressions and Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.2.7 Statements and Control Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.2.8 Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.2.9 Standard Library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.2.10 Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.3 Sample Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.4 Justifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.5 Grammar and Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6 Discussion 36
6.1 Alternative Programming Language Designs . . . . . . . . . . . . . . . . . . . . . . . . 36
6.2 Validity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

7 Future Work 39

8 Conclusion 40

9 References 42

A Sample Program in Frendli 48

B Justifications for Design Decisions in Frendli 49

1 Introduction
Learning and teaching programming have been deemed difficult tasks for many years
[1], [2], [3], [4], [5], [6]. Failure and dropout rates among novices seem to have declined
slightly but are still relatively high [7], [8], [9], [10], [11] while various techniques and
languages are continuously being explored as a means of teaching introductory courses
[3], [6], [12], [13]. Research indicates that the choice of programming language has a
significant impact on novices’ ability to understand basic programming constructs and
concepts [2], [3], [14]. This understanding is vital given the high correlation between
difficulties in syntax and concepts and difficulties in writing code [15], [16].
Furthermore, profound misconceptions can arise from issues in conceptual knowledge
and are common among novices [6], [17], [18], [19]. Since misconceptions represent yet
another barrier of learning that may be hard to reshape [20], studying what can be done
on a language design level to minimize these obstacles as early as possible is
imperative.
….Clues and empirical evidence of what issues novices experience are plentiful, much
of which derive from syntax and semantics [1], [14], [17], [19], [21], [22], [23], [24],
[25], [26], [27], [28], [29]. Although, the frequently used programming languages today
are rarely based on such evidence [30], [31], [32], [33]. Thus, the research presented in
this paper focused on reviewing and presenting relevant literature particularly on the
difficulties and misconceptions held by novice programmers at universities. The
findings thereof were then used as the basis for the design and implementation of an
initial version of a novice-oriented and general-purpose programming language called
Frendli [34]. Accordingly, presenting the literature served the purpose of justifying
design choices made and emphasizing the importance of addressing existing
impediments.
….The new language is intended for use in the beginning stages of introductory
programming courses, transitioning early or mid-course to a different established
language. Through its syntax, the language strives to be a low barrier to entry, facilitate
the formation of accurate conceptions, and allow for an easy transition to several of the
commonly used languages.
….Both the research and the new language (1) provide insight into ways of facilitating
learning to program specifically through language choice and design, (2) serve as a tool
for teaching introductory programming, and (3) act as a resource for future research and
language designers.

1.1 Background
The number of publications on introductory programming has been steadily increasing
for years [6]. A vast majority addresses teaching and student aspects such as learning,
perhaps signifying a growing importance and need to identify preferred approaches over
others. Numbers from various institutions reveal that dropout rates from 30% to 50%
are common for both introductory computer science (CS1) courses and computer
science degrees [7], [8], [10], [11]. A study investigating failure rates in CS1 globally
(Europe and North America most represented) found the average failure rate in 2017 to
be 28%–a decline from 33% in 2007 [9]. The decline yields a glimpse of optimism, yet
one could argue that it is still high. However, not all attrition can be attributed to
difficulties in learning or teaching. Interviews with students showed that lack of time
and motivation were the most common reasons for dropping out [11]. Important to note,
nevertheless, is that the perceived difficulty of the course, as well as factors not related

1
to programming, did affect both primary reasons. Students may also hold
misconceptions about computer science as a field [8], thus their reason for enrolling in a
course may be misconstrued to begin with. Hence, one should not assume that solely
eradicating all difficulties will affect dropout rates equally much. As presented
throughout this paper, there are numerous challenges for novice programmers, but they
can indeed be mitigated to certain extents and still positively impact students’ ability to
learn.
….Some difficulties and misconceptions held by novices pertain to fundamental
constructs and concepts such as variable declarations and assignments, loops,
conditionals, and scope; object-oriented concepts such as the role of a constructor, class,
and object; syntax such as the choice of keywords, semicolons, parentheses, and
operators; problem solving; and cognitive skills [1], [2], [3], [14], [15], [16], [19], [24],
[35], [36], [37], [38]. To address these issues various techniques have been employed.
Visualization and graphical tools have been used to help form mental models, as well as
challenging students’ pre-existing notions–a main aspect of cognitive conflict theory–in
order to address non-viable mental models [2], [6], [17], [29]. Games and
problem-based learning are additional approaches used [6], [39]. Seeing how text-based
programming languages themselves impact their users, they, too, are considered by
institutions and instructors. Yet, which techniques or languages to use in introductory
programming courses has been and still is a highly debated topic [6], [36], indicating a
general lack of consensus.
….Some studies point to a simpler syntax being easier to understand [2], [14], [40]. It
seems unlikely, nevertheless, that merely making it simpler, in terms of being minimal,
would always make it more understandable. At some point, few-letter abbreviations and
terse code ought to decrease readability to the untrained eye as is supported by a study
reporting a faster comprehension speed for fully spelled out words [41]. Sometimes a
simpler syntax also comes at the cost of semantic simplicity which may not always be
favorable for novices [25]. Rigorous empirical studies have also demonstrated how
several of the commonly used programming languages use syntax with remarkably
unintuitive word choices [14], [23]. Moreover, while some research indicates
favorability toward syntactic simplicity, others have found advantages of using more
complex languages like Java and C++ [3], [27]. Accordingly, syntactic factors other
than mere simplicity ought to influence code comprehension.
….Given the inconclusiveness of the literature and the numerous papers reporting no
meaningful differences in students’ learning outcome [6], the wide and heterogeneous
array of introductory languages used seems reasonable [13], [42]. Encouragingly, many
of the difficulties and misconceptions held by novices, be they perceived or actual, have
been identified in the literature, allowing them to be strategically and effectively
exploited in the creation of new languages. Even though the improvement in one or a
few programming aspects alone likely do not solve the notion of learning to program
being unnecessarily hard, uncovering how the process can be simplified in areas of
known difficulties such as syntax and semantics can contribute to coming ever closer.
Thus, there is undoubtedly room for exploring how to further facilitate learning for
novices, particularly through untraditional language design.

1.2 Problem Formulation

The so-called programming language wars–the vast amount and impact of language
designs–and the small amount of evidence-based and human-factored languages
highlight the need for more publications on languages based on an empirical foundation,

2
as also noted by others [14], [23], [30], [31], [32], [33]. Even though there are many
factors affecting the learning process of students, the programming language itself is an
integral and inevitable part of that process. To not address the impact that language
designs have on students in particular is problematic as it impedes possible
improvements in future or current languages as well as introductory courses.
….Thus, the questions asked in this research revolved around how to improve syntactic
and semantic aspects of programming language design, specifically when the novice
programmer is the primary user of the language. The research questions (RQs) were:
RQ1: Which programming languages are most commonly used in introductory
programming courses at universities and what are the reasons for their
adoption?
RQ2: What are the most common difficulties and misconceptions held by novice
programmers?
RQ3: How can a general-purpose introductory programming language be
syntactically and semantically designed when exploiting known difficulties
and misconceptions in order to lower the barrier of entry, facilitate
conceptualization, and be universally transitional?

1.3 Motivation
Educational institutions that teach programming experience issues in terms of attrition
[7], [8], [9], [10], [11]. When choosing a programming language for introductory
courses at universities, ease of learning is a primary reason and a simple syntax seems to
be one explanation for the perceived ease [13], [42]. Nevertheless, syntactic simplicity
is not the sole answer for making programming easier, suggesting other factors also are
involved in determining how optimal a language design is for first-time programmers.
Researching and exploiting these factors would be of great benefit to educational
institutions and instructors in their choice of programming language. This research
paper better equips them so that they in turn can help minimize the very conspicuous
difficulties experienced by novices. Additionally, it also provides a resource for future
language designers whose syntactic and semantic design goals are to increase ease of
learning and understanding. Ultimately the students themselves would indeed benefit.
….The intent of the author was also to further spur the discussion around the
importance and possibility of designing languages in a way that lowers the barrier for
novices, facilitates appropriate conceptualizations, takes advantage of human intuition,
and potentially decreases the likelihood of attrition. Furthermore, it is the hope that this
research will contribute to the adoption of such languages.

1.4 Results
The results of this paper include, firstly, a presented review of literature regarding
certain aspects of introductory programming. Specifically, which programming
languages that are most commonly used in introductory programming courses at
universities are presented along with the reasons for choosing a language. Included in
the review are also studies on novices’ difficulties and misconceptions, as well as
syntactic and semantic aspects to consider for an introductory programming language.
….Following the review, an initial version of a new programming language is presented
of which the design decisions are based on the prior findings. The justifications for
individual decisions are detailed as well.

3
1.5 Scope
The literature review was scoped to novices’ issues primarily around the fundamentals
of programming, but also object-orientation to a lesser extent, almost exclusively at a
university (undergraduate) level. It concerned aspects that could potentially be
addressed via syntax and semantics in one way or another. The programming language
choice in introductory courses were also scoped to universities.
….Some of the aspects not within scope were thereby issues related to problem solving
strategies, algorithms, recursion, adherence to principles, debugging and error messages,
and surrounding tooling such as development environments.
….The presentation of the new programming language focused on syntactic and
semantic design. Thus, the architecture, implementation, and theory of interpreters and
compilers were out of scope for this paper due to both time constraints and an
alternative implementation planned for comparison. For the same reasons, out of scope
were also short-term and long-term evaluations of the new language.

1.6 Target Group

Groups and individuals considered to benefit from reviewing this research are
instructors and educational institutions offering introductory programming courses;
programming language designers; and researchers of novice programmers, introductory
programming, or language design.

1.7 Outline
This paper proceeds by presenting related work on programming languages intended for
first-time programmers and the studies that have been influential in this research
(Section 2). Described thereafter is the methodology used for the research (Section 3),
followed by a review of programming languages used in introductory courses, intrinsic
factors contributing to difficulties in learning programming, specific difficulties and
misconceptions held by novice programmers, and considerations in the design of
introductory programming languages (Section 4). A new programming language is then
presented along with its goals, syntactic and semantic characteristics, and justifications
for design decisions (Section 5). Finally, it goes on to discuss alternative language
designs and overall validity (Section 6), planned and suggested future work (Section 7),
and conclusions drawn (Section 8).

4
2 Related Work
Programming languages designed to help learn how to program and to teach concepts
have been attempted before. LOGO (created in 1967) [43], [44] combines text-based
coding with so-called turtle graphics to illustrate movements produced by commands.
Two fully text-based languages, both of which focus on a concise yet readable syntax,
are SP/k (created around 1973) [45], [46] and Turing (created in 1982) [47]. Some
languages, such as Alice (created in 1995) [48], [49] and Scratch (created in the early
2000s) [50], [51] are visual and interactive, allowing for drag-and-drop block-based
coding to control 2D and 3D objects. Both visual languages have shown positive effects
on learning programming concepts [52], [53], [54]; although, the transition from visual
to text-based has in some cases been harder, such as understanding initialization of state
[55], [56]. A more recent text-based alternative is Less-Java (created around 2019) [57]
which focuses on a simple syntax using type inference, albeit with some resemblance to
Java.
….The efforts made in trying to facilitate the learning process for novices are welcomed
and needed. Unfortunately, none of the aforementioned languages presented empirical
evidence as a foundation for the design decisions made. Around 2011, however, the
first-ever evidence-oriented programming language Quorum [58] (originally
HOP–Human-Optimal Programming) was created and is also text-based. The studies
done in the development of Quorum were highly influential in the creation of
Frendli–the new programming language designed and presented in this paper. Given
their high relevance, the methodologies used are detailed hereafter.

2.1 Influential Studies

This section describes the methodology and purpose of two influential studies related to
novice-oriented programming language design, whereas the specific results relevant to
this paper are presented alongside the findings of other studies in Section 4. The studies
stem, firstly, from Stefik and Gellenbeck [23] when they in 2010 published a rigorous
study of the perceived intuitiveness of word choices and symbols in the syntax of
languages. They intended to use the results as a basis for the design of a language
particularly suited for novices. Secondly, in 2013, having designed and implemented the
new language, a follow-up investigation by Stefik and Siebert [14] was performed
entailing additional empirical studies on the same topic, now including the language for
comparison. Results showed clear favorability to their human-factored language.
….The earlier study was initiated to facilitate programming for the blind through
auditory assistance in an integrated development environment, mapping certain
keywords and operations in the C programming language to more appropriate words
when expressed via audio. Toward its completion, the authors questioned whether these
mappings still would have been necessary if the language itself had been designed
differently. Hence, they initiated another study (presented in the same paper) analyzing
the comprehensibility of word choices for use in their upcoming programming language
that would be better suited for visual and aural representation.
….There were 106 participants–64 labeled non-programmers (although the average
number of self-reported years of programming experience in this group was 0.23) and
42 labeled programmers. The participants were given textual descriptions of concepts
meant to represent various programming concepts, after which each item in a list (being
words or symbols) was rated on a scale from 0 to 10 on how well it corresponded to the
description. Some of the included concepts were “Doing something zero or more

5
times”, “Take a behavior only when 2 conditions are true”, and “Assigning a value to a
computer’s memory”. The questions were asked in the absence of any code context. As
part of the analysis, the words were ranked in groups and order of statistical difference,
undergoing a well-defined statistical procedure. As elaborated in Section 4, their results
revealed that some of the most commonly used word choices in programming languages
today were ranked lowest; meaning, they were perceived among the least intuitive. This
implies a lack of consideration of human factors in syntactic and semantic language
design choices, which has also been claimed by others [30], [31], [32], [33].
….The later investigation conducted in 2013 built upon the aforementioned one by
exploring the intuitiveness of syntax in two empirical studies. The first one focused on
isolated word choices and the second one on constructs within the context of larger
programs written in nine different languages (Java, Perl, Ruby, Python, C++, Go, PHP,
Smalltalk, and Quorum). As in the earlier one, the participants were either non-
programmers (in this case having zero years of experience) or programmers (having
more than zero years of experience), and the data analysis followed similar procedures.
….Additionally, two empirical studies were conducted to measure novices’ syntactic
accuracy rate when writing simple programs in one of six languages (Java, Perl, Ruby,
Python, Quorum, and the metaphorical placebo-intended language Randomo). The
sample size for each language group was between 6 and 13. To know what constituted
accurate code, each person was given equivalent code samples in their respective
language from which they could derive meaning. Some concepts tested include
conditional statements, nested conditional statements, variables, and loops.
….All surveys in the studies derived from extensive peer reviews and pilot studies.
Overall, the result supported the notion that syntax significantly impacts novices insofar
as not being equally intuitive, some variations allowing for easier construction of
accurate code, and certain syntactic features being a more likely source of problems.
Their custom simple-syntax language Quorum was statistically found to be perceived as
significantly more intuitive (see Section 4 for specific results).
….There were, however, certain aspects and alternatives that were not tested in these
studies. Given that participants for obvious reasons were given a finite list of words and
symbols when rating their intuitiveness, there is a possibility that more intuitive or
better suited alternatives were not on the list. For instance, the word choices considered
for various representations such as a class, method, or variable were only nouns. Hence,
verbs such as define (abbreviated def in the programming languages Python and Ruby)
were not alternatives for indicating a function. Testing of alternative syntax was
encouraged nonetheless. Omitted were also tests specifically for the choice of the else
keyword; the choice of the end keyword for indicating the end of a block, as in Quorum
and Ruby; comprehensibility of correct yet unindented code, perhaps as a way to
provide clues on whether or not spaces ought to be semantically significant; the concept
of scope; the concept of closures; and the relationship between an object and a class.
While the later study tested the intuitiveness of word choices related to various
object-oriented concepts, the former did not.
….The research presented in this paper comparatively paid greater attention to existing
misconceptions than the two aforementioned ones. It incorporated not only that into the
design of the new language, but the potential for transitioning into a common
general-purpose language. The results of the studies on word choice and syntactic
accuracy still served as justification for several of the design choices made.

6
3 Research Methodology
This section describes the procedure adopted for identifying, selecting, and evaluating
publications relevant to this research. RQ1 (identifying languages used in introductory
programming courses and the reasons thereof) and RQ2 (identifying issues experienced
by novice programmers) were studied solely through a literature review. RQ3
(examining how novices’ issues can be exploited in programming language design) was
addressed both via the literature review and a design of a proposed language presented
in Section 5.

3.1 Literature Review Overview

A systematic literature review is a way of fairly gathering and evaluating relevant
research in an auditable manner with the aim of finding as many relevant studies as
possible [59]. The relevance is determined by the area of interest and must not be
affected by research not in support of a particular hypothesis. Generally, the review
consists of multiple activities, phases, or steps conducted in a specific order where
iteration or refinements of the steps are allowed in order to be able to better answer the
research question asked. This kind of approach was opted for due to its ability to
provide a significant amount of information on the areas to study that originate from
different environments and various methods. It collectively allows for a more fair
representation of a certain phenomenon with support for or against it. In the case of
inconsistencies, discussions around the inconclusiveness can be initiated.
….The literature review in this research was guided by the steps listed below with the
aim of efficiently producing and reproducing relevant search results. The steps taken in
the review were mainly guided by Kitchenham’s [59] proposed procedure, but also by
the method adopted by Luxton-Reilly et al. [6] for their systematic literature review
which to a large extent was based on Kitchenham’s guidelines, albeit with slight
deviations. Deviations included filtering papers primarily by relevance and eliminating
papers in earlier stages when deemed irrelevant. Step 1 laid the foundation for the
subsequent steps, steps 2 and 7 were repeated for each research question, and steps 3
through 6 were repeated for each search query. The steps included:
1) Identify and formulate research questions
2) Define search criteria
3) Conduct searches of studies
4) Select studies based on criteria
5) Filter studies based on relevance
6) Extract and synthesize data
7) Present findings

3.2 Defining Search Criteria

Google Scholar was used as the search engine due to its full-text crawling and indexing
of content deriving from multiple publishers and databases. In order to define a suitable
time range for relevant search results for RQ2 and gain further candidates for search
terms, the initial searches were broader and specifically targeted recently conducted
literature reviews. Hence the initial search query used the words “literature review
introductory programming” from which the results had to contain all of the words,
appear anywhere in the article, and be dated within the past six years (2016-2022). Only

7
the results from the first two pages (20 results) were considered. The three papers with
the highest citations out of the most relevant ones based on their respective abstracts
were selected for further reading. Reading the papers gave a broad and meaningful view
of the difficulties experienced in introductory programming courses and a sense of what
literature existed on the topic. Using a snowball method (finding additional literature via
the references in the reviewed papers) showed that a significant amount of relevant and
valuable results derived not only from recent research, but also from research in the past
couple of decades. Therefore, the period of interest for RQ2 spanned the past 20 years;
that is, from 2002 to early 2022. An exception to the 20-year time frame on search
results was when literature was found through a snowball method and was still deemed
relevant and valuable (the definitions of which are presented in Section 3.4). For RQ1, a
limit to include only the past six years was added to the search criteria as languages
used in more recent years were of specific interest. RQ3 was not bound to a specific
time period due to the early origins of language design. Applicable to all three research
questions, the words used in all subsequent search queries all had to exist anywhere in
the article (no exact phrases were required).

3.3 Conducting Searches

Initially using a trial and error approach of how general or specific the search terms had
to be was necessary in order to gain an understanding of the content range of search
results. Having too much specificity yielded too narrow a range with very few relevant
papers. Only including general terms produced many relevant papers in total but most
often spread across too many pages, producing low relevance per page. Accordingly, the
aim was to instead use terms that were neither too general nor too specific in order to
confine the relevant papers to the earlier pages. Multiple searches were then conducted
targeting different areas of interest to prevent unintentional exclusions of relevant
papers. The use of language bias was avoided to prevent biased results.
….The search query strings and with which research question (RQ) each was associated
are presented in Table 3.1. Some queries were associated with more than one research
question and thus appear as duplications. The searches were conducted between January
18, 2022 and February 8, 2022, inclusive.

TABLE 3.1
Search Query Strings Used and Their Associated Research Question

RQ Search Query Strings

RQ1 “introductory programming language”, “CS1 programming language”

RQ2 “literature review introductory programming”, “difficulties novice programmers”,

“introductory programming difficulties”, “introductory programming concepts”,
“introductory programming misconceptions”, “programming viable mental
models”, “programming language design novice”, “comparing programming
language syntax”, “introductory programming python”, “programming readability
cognitive load”

RQ3 “introductory programming language design”, “introductory programming

language”, “programming language design novice”

8
3.4 Selecting and Filtering Studies
The selection process described pertains to all research questions. For each query, out of
the 20 results available from the first two pages on Google Scholar, only papers from
the publishers ACM, IEEE Xplore, SpringerLink, ScienceDirect, and Taylor & Francis
Online were considered due to scope and time constraints of the research. Publications
found indirectly using the snowball technique were not required to originate from any of
the specified publishers. Additionally, 20 or more citations on Google Scholar were
required if published over 10 years ago; that is, prior to 2012. The numbers presented in
this section for how many papers were considered (papers that formed the basis for the
review), examined (abstracts examined and papers partially examined when needed),
selected (papers selected for further review), and filtered (papers fully read and from
where data was extracted) include the search results from all queries. The numbers as
grouped by publisher are presented in Table 3.2.
TABLE 3.2
The Number of Papers Addressed Directly from All Search Queries

Number of Papers
Publisher Considered Examined Selected Filtered

ACM 115 102 58 36

IEEE Xplore 23 19 10 6
SpringerLink 20 15 12 5
ScienceDirect 12 7 1 0
Taylor & Francis Online 12 12 6 4
Total 182 155 87 51

….The relevance was determined by each paper’s relation to the research questions. It
specifically pertained to introductory programming exclusively at an undergraduate
level (except for natural language difficulties); general and specific difficulties
encountered by students in introductory programming courses; misconceptions and
non-viable mental models held by novice programmers; factors contributing to
difficulties in learning and understanding of programming such as the level of cognitive
load; empirical studies and comparisons of text-based high-level general-purpose
programming languages; studies on novice-oriented language design; and programming
language adoption at universities.
….In total, 182 papers were considered out of which 155 abstracts were examined.
Papers with titles which clearly indicated being irrelevant to any of the research
questions were not examined. Any examined abstract that clearly implied irrelevance
was eliminated at this stage. In the case of ambiguity, the introduction and methodology
sections of the paper were read to determine whether or not to be selected for further
review. Additional reasons for not being selected included indications of being a work
in progress, lacking an abstract, being in the form of a book or book chapter due to lack
of time to evaluate the book as a whole, and being a different publication with the same
data as previously examined.
….Out of the abstracts examined, 87 were selected for deeper analysis. A deeper
analysis involved reading the full text (excluding any sections or subsections that
undoubtedly were irrelevant based on the heading and section introduction) starting
with the introduction, methodology, and result sections when available to further

9
evaluate its degree of relevance. Papers which did not study or present data within the
areas of interest based on those initial sections were eliminated, as were those which did
not appropriately provide references for claims, had less than three pages (excluding
references and appendices), or were inaccessible to the author. The remaining 51 papers
were fully read while simultaneously extracting relevant data such as names of the
authors, publisher, year conducted, number of citations, abstract and summary of the
study, sample sizes if applicable, primary means of data collection and analysis, relevant
findings, and explicitly stated validity concerns. The data was organized by results as a
means of data synthesis in preparation for presenting the results.

3.5 Reliability and Validity

Biases and other limitations of the research methodology exist and cannot be completely
circumvented. There are various internal validity concerns to keep in mind. For
instance, by limiting the publishers to a select few consequently limited the types of
papers considered. Moreover, a bias toward any of the publishers could have affected
the selection process. Due to time constraints, the number of papers reviewed also had
to be limited. Similarly, insufficient, suboptimal, or biased search query strings could
have unintentionally excluded relevant papers from the results. All such factors
inevitably affect the comprehensiveness of the review, introducing the risk of false
negatives (assuming the lack of something when in fact it exists).
….To reduce such risks and their effects, a trial and error approach to incrementally
define search queries and increase the relevance per page was utilized. Examining the
publishers of relevant papers referenced by other broader systematic literature reviews
revealed which publishers frequently appear in similar research and helped guide the
selection of which publishers to include.
….Additionally, the results of the studies selected in turn introduce external validity
concerns impacting the overall generalizability of claims. These include potential biases
of the respective authors and using samples not representative of the target population.
When selecting studies, multiple universities and countries had to be represented in
order to mitigate such concerns.
….As a literature review provided an efficient way of gathering a vast amount of
resources and has commonly been used for similar research, it was opted for as the
means of data collection. Its convention when conducting research was a factor for
increasing overall reliability. Alas, performing own studies, such as through surveys,
would have presented significant difficulties in terms of access to representative
samples of participants and available time for careful design and quantitative analysis.

3.6 Ethical Considerations

There was not believed to be any ethical concerns pertaining to personal data as it did
not involve directly gathering or managing information of that kind. With regard to
generalizability, the impracticality of representing most countries and institutions in this
paper inevitably introduces the risk of neglecting some parts of the world. In the design,
and more so in the implementation, of a programming language, one must consider the
potential harm that could be done in the event of bugs in the language itself. Given how
the programming language developed as part of this research is intended for
introductory programming courses and not production, risks of serious nature are
considered low. Furthermore, to increase access to programming for non-native English
speakers, using simpler terminology within the language was taken into consideration.

10
4 Literature Review
This section fully addresses research questions RQ1 and RQ2, and partially RQ3, whose
findings formed the foundation for RQ3 primarily addressed in Section 5. Section 4.1
addresses RQ1 where the programming languages used in introductory university
courses and the reasons for their adoption are presented. Sections 4.2 through 4.4
address RQ2 by presenting possible intrinsic factors of difficulties in learning,
encountered difficulties, and misconceptions held by novices. Section 4.5 addresses
RQ3 by presenting introductory programming language design problems and principles.

4.1 Language Choice in Introductory Programming

A broad and systematic literature review of publications on introductory programming
spanning from 2003 to 2017 presented that most papers focused on the teaching aspect
and fewer on curriculum such as programming languages [6]. Specifically, out of the
relevant papers selected for further review, 905 focused on teaching, 489 on the student,
258 on curriculum, and 192 on assessment (a paper could belong to more than one
classification). About a third of the papers on curriculum in turn focused on the
programming language choice, and the numbers have increased from 0-1 papers being
published each year in the beginning of the given period to 6-8 papers per year toward
the end. The authors stated that more empirical research on how and why a particular
curricular choice, such as a language, should be adopted definitely would benefit the
field of introductory programming. They also concluded that subjectivity, rather than
objectivity, clearly is what determines programming language choice, with multiple
different factors being accounted for. Others have also noted that the importance of
various determining factors depend on the priorities and aims of the institution [60].

TABLE 4.1
Languages Used in Introductory Programming Courses in the U.S. [12]

Adoption in 2018
Rank Language Count Total %

1 Java 65 42%
2 Python 41 26%
3 C++ 30 19%
4 C 7 5%
5+ Others combined 12 8%

TABLE 4.2
Duration of Use of a Language in Introductory Programming Courses in the U.S. [12]

Language (Row %)
Duration of Use Count Total % Java Python C++ C Others

0-2 years 14 9% 7% 57% 14% 0% 22%

3-5 years 37 24% 16% 41% 24% 5% 14%
>= 6 years 104 67% 56% 17% 18% 5% 4%

11
….In order to identify languages used in introductory programming courses and
justifications for choosing them, in 2018 a survey of 496 bachelor’s degree programs
within computer science in the United States was conducted [12]. With a response rate
of roughly 31% (155 programs), the four most common languages in introductory
courses were Java (42%), Python (26%), C++ (19%), and C (5%) as shown in Table 4.1.
Fourteen (9%) of the programs had been using their respective languages for up to only
two years, out of which Python accounted for 57%, C++ for 14%, Java for 7%, and C
for 0%, presented in Table 4.2. Similarly, 104 (67%) of the programs had been using
their language for six years or more, out of which Java accounted for 56%, C++ for
18%, Python for 17%, and C for 5%. Even though Java clearly was adopted by more
institutions among the ones asked, most institutions that adopted a language within the
most recent years chose Python.

TABLE 4.3
Reasons for Using a Language in Introductory Programming Courses in the U.S. [12]

Language (Row %)
Rank Reason Count Total % Java Python C++ C Others

1 Features 110 26% 38% 29% 19% 5% 9%

2 Learning ease 79 19% 38% 44% 8% 1% 9%
3 Job opportunities 62 15% 58% 6% 29% 2% 5%
4 Popularity 55 13% 47% 29% 20% 0% 4%
5 Tradition 36 9% 53% 3% 31% 6% 8%
6 APCS 32 8% 88% 0% 6% 0% 6%
7 Advisory board 25 6% 60% 8% 32% 0% 0%
8 Faculty 21 5% 62% 0% 24% 5% 10%

….Table 4.3 shows the reasons for using a specific language (the count totals 420,
exceeding the 155 respondents since multiple reasons could be selected). The most
selected reason was language features (26%). The specific features rated most important
(not shown in the table) were repetition structures (16%), functions (15%),
object-orientation (12%), and static typing (11%). Apart from language features, other
reasons for using a language were ease of learning (19%), job opportunities (15%),
popularity in academia (13%), tradition by the institution (9%), Advanced Placement
Computer Science (APCS–a program in the United States that gives high school
students the opportunity to earn college credit, and uses only Java in such courses)
(8%), advice from an advisory board (6%), and faculty availability (5%). Notable
differences were revealed when the reasons were grouped by language. Out of the ones
selecting job opportunities as a reason, 58% were programs using Java in their
introductory course, while only 6% were those using Python. None of the programs
selecting APCS and faculty availability as reasons were using Python, while 88% and
62% respectively were accounted for by Java. Ease of learning was opted for slightly
more by Python users (44%) than Java users (38%).

12
 TABLE 4.4
Languages Used in Introductory Programming Courses in Australasia [42]

Adoption in Year
Rank Language 2001 2003 2010 2013 2016

1 Python 0% 0% 14% 27% 31%

1 Java 40% 41% 37% 27% 31%
2 C 7% 13% 11% 7% 17%
3 C# 0% 0% 9% 9% 10%
4+ Others combined - - - - 28%
Total Count 57 85 44 38 48

….Another study on the choice of programming language reported on a 2016 survey

that received valid responses from a total of 35 universities in Australia (27) and New
Zealand (8) regarding 48 introductory programming courses that in turn comprised a
total of 20,295 students [42]. In total, 16 different programming languages were used
across the courses, some using more than one language. The four most common ones
are presented in Table 4.4 along with the percentages of courses having adopted each
language over the past years (total percentages in each year exceeded 100% if multiple
languages were used within the same course). The top languages were Python (31%),
Java (31%), C (17%), and C# (10%) while most other languages represented 2% each
(C++ was not used in any of the courses). The authors also incorporated data from the
previous related surveys dating back 15 years. Somewhat similar to the presented
analysis of the courses offered in the U.S., the Australasian surveys together revealed a
recent increase in the use of Python in introductory courses, having 0% adoption in
2001 and 2003, 14% in 2010, 27% in 2013, and 31% in 2016. Java’s adoption declined
between 2003 and 2013, but increased in the most recent survey in 2016.

TABLE 4.5
Reasons and Their Level of Importance for Using a Language in Introductory
Programming Courses in Australasia [42]

Reason & Importance

Rank Overall Java Python

1 Pedagogy (81%) Relevance (92%) Pedagogy (67%)

2 Relevance (78%) OO language (86%) Availability/cost (53%)
3 Availability/cost (67%) Platform indep. (62%) Platform indep. (40%)
4 Degree structure (62%) - -
5 Platform indep. (57%) - -

….The survey also asked the participants to rate the importance of each reason listed for
choosing a language on a five-point scale. The results are presented in Table 4.5.
Overall, pedagogical benefits rated highest (81% overall importance), with 30% rating it
as “extremely important” (the uppermost point on the scale). The next four highest rated
reasons were relevance to industry (78%), availability and cost (67%), degree structure

13
(62%), and platform independence (57%). When analyzed by language, the most
important reasons when using Python were pedagogical benefits (67%), availability and
cost (53%), and platform independence (40%). When using Java, industry relevance
(92%), object-oriented (OO) language (86%), and platform independence (62%) were
most important (the survey only made available the top three choices). The respondents
also answered what would be the reasons for a future change in programming language,
whereby the dominant one was pedagogical benefits (52%).
….Additional data gathered by the survey relevant to this paper included, firstly, how
difficult the respondents perceived the used language to be for the novice students, and
secondly, how useful they perceived the used language to be for teaching fundamental
programming concepts. A seven-point scale ranging from “extremely easy” to “neither
easy nor difficult” (the median) to “extremely difficult” was used. Addressing the first
point regarding perceived difficulty, roughly 21% of the respondents selected the
median of “neither easy nor difficult”, 32% selected difficulty levels below the median,
and 46% above the median (totaling 99% due to rounding). From this data, languages in
general were more so perceived as difficult than easy. Although, when grouped by
language it clearly suggested that Python was perceived as easier for novices in
comparison to Java.
….As for a language’s perceived usefulness for teaching fundamental concepts, all
Python respondents rated it between “neither useful nor useless” and “extremely useful”
(the best alternative) where 47% belonged to the latter (a scale equivalent to the one
described in the previous paragraph was used). For Java, all respondents rated it
between “slightly useful” and “extremely useful” where 27% belonged to the latter.
Python accumulated more of the best rating while Java received more ratings for the
two best ratings combined.
….Despite certain perceived difficulties in the languages, the results of the survey
indicated that some languages were still considered useful in conveying concepts in
combination with teaching, yet to various degrees. It also clearly demonstrated the room
for improvement, nevertheless. Furthermore, when compared to Java, the perception
seemed to be that Python was easier for novices while at the same time possibly more
useful for explaining fundamental concepts. No measures of significance were
presented, partly due to small sample sizes at times.

4.2 Intrinsic Complexity and Cognitive Load

Seeing from dropout and failure rates (presented in Section 1.1) how students continue
to struggle with learning programming, a reasonable question to ask is whether or not
the subject itself is intrinsically hard. Some suggest that it is not, but rather that novices
may face unrealistic expectations and that it can be made easier by improving the way it
is taught [61]. It has also been argued that the cognitive level at which teaching
conventionally occurs is higher than that of novice students and that the instructional
practice ought to be adjusted [62].
….On the other hand, perhaps the seemingly intrinsic complexity can be explained in
part by the level of cognitive load created (the amount of resources required by the
brain’s working memory) when learning a topic involving high element interactivity. A
paper focusing on cognitive load theory (a theory aiming to explain what transpires in
the brain when learning something new) stated that learning new material with high
interactivity between elements intrinsically has a high cognitive load [63]. If applying
additional cognitive load in such a state it will interfere with learning. Yet the design of
the instructions given can still be adjusted to decrease the difficulty of learning and

14
problem solving. However, it also concluded that attempts to decrease the difficulty
could prove unsuccessful or insignificant if the material to be learned does not have the
characteristics of high element interactivity.
….Other studies also provide interesting insights. One study neuroscientifically
examined 18 novices and experienced programmers using an electroencephalogram
(EEG) [64]. They were observed when completing tasks related to program
comprehension and it demonstrated that high cognitive skills were required. Another
study showed how handling many abstractions at the same time became problematic
and interfered with novices’ ability to solve problems [38].

4.3 Difficulties in Introductory Programming

Novices face various types of barriers in their early encounters with programming.
Presented hereafter are ones that can potentially be addressed in one way or another
through syntactic and semantic language design. Some relate to syntax–the lexical units
of the language such as words, symbols, and their specific order, making up the rules of
the grammar–, some to constructs–the individual building blocks of a program
assembled by the syntactic pieces–, and some to concepts–the understanding of how
something works, often practically represented by the constructs. The strong positive
correlations found between learning syntax, understanding constructs, and
understanding most concepts emphasize the importance of having languages that
effectively convey concepts through its syntax [1]. Summarized in Table 4.6 are the
difficulties grouped by category (the IDs are referred to in Appendix B).

TABLE 4.6
Issues and Clues Concerning Difficulties Among Novice Programmers

Category Description ID

General Higher syntactic accuracy using syntactically simpler languages. D1

Faster comprehension speed for fully spelled out identifier words than D2
abbreviations.

Pseudo-code was suitable for conveying, testing, reading, and reasoning D3

around fundamental concepts independent of programming language.

Missing semicolons. D4

Mismatched quotation marks. D5

Mismatched brackets and parentheses. D6

Low syntactic accuracy using an end keyword for ending a code block. D7

More intuitive words/symbols for single-line comments were //, D8

comment, note.

More intuitive symbols for multi-line comments were /**/. D9

Data type More intuitive words for an integer were number, integer. D10

More intuitive words for a float were number, decimal. D11

15
 More intuitive words for a boolean were condition, logic, binary. D12

More intuitive words for a string were characters, text. D13

More intuitive symbols for enclosing a list of characters were ( ), “”. D14

More intuitive words for a null value were undefined, empty. D15

Mismatched types. D16

Slight difficulties placing type annotations. D17

Operator More intuitive words/symbols for variable assignment were =, is. D18

High syntactic accuracy using the assignment operator =. D19

More intuitive words/symbols for incrementing the value of a variable D20

were x = x + 1, x + 1, raise x.
Less intuitive was x++.

Increased semantic complexity for overloaded + operator particularly for D21

lists.

More intuitive symbol for string concatenation was +. D22

More intuitive words/symbols for the equality comparison operator were D23
=, is, ==.

Low syntactic accuracy using the equality comparison operator ==. D24

More intuitive words/symbols for the inequality comparison operator D25

were unequal, not=.

Less intuitive symbols for the logical operators were &&, ||. D26
More intuitive were and, &, or.

Variable Difficulty understanding variable lifetime and scope. D27

Difficulty understanding the need to declare a variable before use. D28

Control More intuitive words for conditional constructs were with the condition D29
that, if, only if, when, while.

Low syntactic accuracy using a then keyword as part of if statements. D30

E.g. if y > 1000 then

High syntactic accuracy using a syntactically simple condition without D31

parentheses and braces.
E.g. if y > 1000

Less intuitive loop construct words were for, while, foreach. D32
More intuitive was repeat.

Less intuitive loop constructs as a whole were variants of the for loop. D33
More intuitive were repeat times, timesRepeat, while.

16
 Difficulty selecting the appropriate loop construct. D34

Difficulty understanding the scope of a loop. D35

Difficulty understanding which of the lines inside the loop will be D36
repeated, and the number of times.

Function More intuitive words for a function were action, procedure, work, task, D37
operation.

Difficulty understanding where values in parameters come from. D38

Difficulty understanding when to pass function arguments. D39

Difficulty understanding who the receiver of a return value is. D40

Difficulty understanding when to return something. D41

Difficulty understanding where/to data from I/O operations comes D42

from/goes to.

Less intuitive output words were console.write, printf. D43

More intuitive were display, output.

OOP More intuitive words for a class were object, structure. D44

More intuitive words/symbols for an IS-A relationship were is a, is, : D45

E.g. truck is a vehicle

More intuitive symbol for taking a behavior was : D46

Less intuitive was .

More intuitive words for the this keyword were self, myself, me. D47

More intuitive words for a base class were source, foundation, parent. D48

Difficulty understanding object-oriented concepts, such as objects, D49

instances, classes, methods, and their relationship.

4.3.1 Syntax
Multiple papers cite programming language syntax as a difficulty [36]. Syntax errors
have also shown to negatively impact novices’ attitude and experience of programming
[37], [65]. For instance, missing semicolons and mismatched quotation marks, brackets,
parentheses, and types are common, as well as incorrect use of the assignment operator
(=) where the comparison operator (==) was expected [21], [22], [24], [27], [37].
Although evaluated for identifier names (such as variables) and not specifically for
keywords, fully spelled out words took 19% faster on average to comprehend than
abbreviations and single letters in a study of 72 professional developers using the C#
language [41].
….As discussed in more detail in Section 2.1, the studies on programming language
syntax by Stefik and Gellenbeck [23] and a few years later by Stefik and Siebert [14]
revealed how many word and symbol choices in the syntax of commonly used

17
languages were perceived as less intuitive, likely being a source for difficulties. Perhaps
one of the most noteworthy examples given its frequent use across numerous languages
may be the words representing loop constructs. The words that were lowest ranked
among novices in both studies, starting with the worst, were for, while, and foreach.
Neither did they receive particularly high ratings from experienced programmers. The
highest ranked word was repeat, ranking approximately seven times more intuitive than
for in the first study. Performing something only when a certain condition is true was
most intuitively represented using the words with the condition that, if, only if, and
while for novices in the earlier study, and if, when, and require in the follow-up study.
The word case (as used in switch statements) was among the lowest rated ones. The
word most intuitive for describing the logical AND concept was and followed by the
single ampersand (&) which could not be statistically differentiated from the former.
Similarly, logical OR related best with the word or. For both logical concepts,
experienced programmers rated the commonly used symbols double ampersand (&&)
and double bar (||) relatively high, while non-programmers rated them significantly
lower. For variable assignments, the equal sign (=) was clearly the most intuitive of the
choices, but the word is was also rated high.
….Both studies implied that double quotes (“”) were among the most intuitive for
enclosing a list of characters, although novices in the first study rated parentheses (())
insignificantly higher. The plus sign (+) was most intuitive for concatenating string
types. In the second study, programmers unexpectedly rated string highest for the string
type, while non-programmers chose characters. The second best ranked word among
both groups was text. Additionally, number and integer rated highest for representing an
integer type, and number and decimal for representing a floating point number. The
three most intuitive choices among novices for a boolean were condition, logic, and
binary, although not showing any clear consistency.
….For representing something that can take a behavior (the concept of a method or
function) the word action was most intuitive for novices in the first study, followed by
words such as work, task, operation and function. Novices in the second study favored
procedure, operation, and task. Accessing a member field or method (commonly done
via the dot operator) of which the overall concept was explained in the studies as
“Telling a noun to take a behavior” related best by programmers with a dot (.) as
expected. Novices for unclear reasons rated colon (:) highest and dot significantly
lower. It may just be that the concept itself is hard to intuitively represent through only
symbols, or that the wording of the question was suboptimal.
….In addition to the results just presented, the follow-up study also addressed syntax
related to object-oriented programming (OOP), comparison operators, and comments
among a few other concepts. With regard to OOP, the most intuitive words for the
concept of a class for both non-programmers and programmers were object and
structure. Given how even programmers rated object higher than class itself may
indicate possible issues in successfully differentiating the two concepts in the question.
Both is a and is were among the highest rated words for an IS-A relationship, but
interestingly, novices also found colon (:) fitting, as in truck : vehicle. Both
non-programmers and programmers found source, foundation, and parent most intuitive
for the concept of a base class. The this keyword often used in object-oriented
languages was not among the highest rated words for either group; instead, they were
self, myself, and me.
….Regarding equality operators, the single equal symbol (=) and is were rated higher
by novices than the widely adopted double equal symbol (==); whereas for not being
equal, unequal and not= were most intuitive. For the concept of a null value, undefined

18
and empty were among the top choices for both groups. The double plus (++)
augmented assignment operator, as in x++, is commonly used in languages; however, it
was not rated highly by novices. The top choices were x = x + 1, x + 1, and raise x.
Both groups rated the word display most intuitive for outputting data to the user, and
output was among the highest ones as well. Bottom choices for the novice group were
console.write and printf. Unexpectedly, the highest rated choice for single-line
comments was the double forward slash symbol (//), and for multi-line comments the
forward slash asterisk (followed by that in reverse) (/**/)–both frequently seen in
languages today. This was not only true for the experienced programmers but for
novices as well, who also rated the words comment and note almost equally intuitive for
initiating a single-line comment.

4.3.2 Constructs
One of the surveys in Stefik’s and Siebert’s [14] study focused on evaluating the
intuitiveness of constructs syntactically (not solely individual words). Given a piece of
code with a construct in a specific programming language and a correct English
explanation of what the code did, participants rated how well the construct as a whole
represented the explanation. Overall, Quorum (the language previously developed for
novices), Java, and Ruby were perceived as most intuitive by novices. Programmers
instead chose Java, C++, and Quorum. Python was rated among the least intuitive for
programmers.
….For the conditional if construct, novices and programmers rated C++/Java, Quorum,
and Go highest, and Smalltalk lowest. For representing a loop, the top choices by
novices were Quorum (using repeat times as in repeat 10 times), Smalltalk (using
timesRepeat as in 10 timesRepeat:), and C++/Java (using while as in while (i <= 10)).
The bottom choices for both groups included variants of the for loop in Go, Python,
Perl, and PHP. Others have suggested that including only one non-terminating loop
construct in the language may be preferred if meant for use in introductory
programming [60]. Exiting would then be controlled via if statements from within the
loop.
….Regarding novices only, for representing a function, Quorum’s and Smalltalk’s
constructs were most intuitive and Perl’s the least; for a constructor, Quorum and PHP
were top choices and Python, Java, and Smalltalk bottom ones; and for inheritance,
Ruby, Quorum, and PHP were most intuitive while Perl and Smalltalk were the least.
….Stefik and Siebert [14] also measured the syntactic accuracy of novices when writing
small programs. The participants learned about various constructs through examples of
code snippets in the respective language being tested. The study found the syntactically
simpler languages like Quorum, Python, and Ruby to yield better results. Participants
using those three languages had noticeably higher accuracy rates than the placebo, while
the accuracy rates of those using Perl and Java interestingly could not be statistically
differentiated from the placebo. To remind the reader, Randomo was the name chosen
for the metaphorical placebo language and was generated by replacing keywords from
Quorum’s syntax with random characters from the ASCII1 table. Furthermore, the poor
accuracy scores for particular words in Quorum itself indicated that having a then
keyword as part of if statements, as in if y > 1000 then, proved problematic, yielding
between 8%-67% accuracy. Similarly, the end keyword indicating the end of a code
block yielded between 0%-67% accuracy. This led the developers of Quorum to remove

1
American Standard Code for Information Interchange provides numerical representations of characters.

19
the then keyword completely in a later version, as well as the inner end keyword in
if-else statements.
….Conditional statements with removed parentheses and braces, as in Ruby’s if y >
1000, were most successful. Only 1 out of 48 participants using Ruby, Python, Perl, and
Java correctly applied the double equal symbol for comparing equality. The single equal
symbol was correctly implemented by 100% of the novices when used as an assignment
operator. Type annotations were used accurately about half the time, leading the authors
to cautiously state that novices may experience slight difficulties with static type
systems. Important to emphasize is that they could not conclude based on their results
that dynamic typing is better for a novice-oriented language. It is possible that the
benefits of static types may outweigh the cost of syntactic difficulties once the type
system is learned.

4.3.3 Concepts
Having difficulties in conceptual knowledge affects a student’s problem solving ability
given their high correlation to difficulties in writing code [15], [16]. It is therefore
imperative that such issues be addressed. For instance, understanding how a loop works
has been found to be problematic in terms of its scope, which of the lines inside the loop
will be repeated, the number of times, and how it relates to its condition [1], [5], [27].
Selecting the appropriate loop construct such as a for or while loop for a specific context
has also shown to be difficult for novices at times [27], [66]. As a comparison between
the clean-syntax language Python and the traditional C-syntax language Java, a
quantitative study was conducted where the usage of various constructs was measured
[2]. It showed that loops were used 37% more frequently by novices using Python than
Java. For the usage of conditional constructs, such as if or if-else, the study found no
significant difference between the languages. Nevertheless, understanding how
conditional constructs work has in some cases been challenging [1], [17], [22].
….An empirical study comprised of 952 students at two universities was conducted at
the end of their introductory programming courses (taught either in Python, Java, or
MATLAB) [67]. Each student’s performance on two versions of an assessment exam
was compared. One version was based on the tool that the study developed for assessing
introductory computer science concepts (deemed by some as possibly one of the most
thoroughly evaluated tools of this kind [14]), written in verbose pseudo-code. The other
was a comparable version written in the language used in the student’s course. Each
student took both versions with the goal of evaluating the effectiveness of pseudo-code
as a means of establishing programming language independence for such a tool. The
results showed that some of the questions most frequently answered correctly pertained
to mathematical operators and the concept of if statements, while more difficult ones
were in relation to function parameters and return values. Several strong, positive
correlations were also found between the scores of the two versions. This indicated that
pseudo-code was suitable for conveying and testing fundamental concepts independent
of language priorly taught. Though not explicitly tested, it may also be indicative of
being a favorable characteristic for universally transitional languages, or at least worthy
of further investigation. Additionally, think-aloud interviews qualitatively demonstrated
that students could successfully read and reason around fundamental concepts using the
verbose pseudo-code syntax encountered for the first time.
….Further difficulties in understanding concepts include why declaring a variable
before it is used is necessary; not knowing where values in function parameters
originate from; not knowing when to pass arguments; not knowing who the receiver of a

20
return value is; having problems understanding when to return something; where and to
data from input-output (I/O) operations comes from and goes to; and frequent struggles
with object-oriented programming (OOP) concepts, such as lack of developing feasible
mental models and understanding objects, instances, classes, methods, and their
relationships [17], [19], [21], [22], [26], [27], [28], [68].
….Learning object-oriented concepts was especially challenging for students in a study
[3]. The study evaluated the impact of programming languages and teaching approaches
through the use of an instrument specifically developed for assessing fundamental and
OOP concepts. Insofar as specific languages, however, students programming in Java
and C++ consistently achieved better results overall than the ones using the
syntactically simpler language Visual Basic. The study suggested indecisively that it
may be easier to comprehend fundamental concepts if using more complex languages.
Although, student performance on questions related to OOP concepts did not seem to be
affected by the instructional language used. Furthermore, another study tried to
determine whether Python students struggled less than C++ students [27]. The study
included 1,927 introductory programming students across 20 universities. It revealed
that the struggle rate (measured in terms of excessive time spent and attempts per
exercise) was significantly higher for Python students.
….The implication of Java and C++ being easier for fundamental concepts was
contradicted by other studies. A quantitative one comparing Python and Java
demonstrated that the less complex language Python was easier for understanding
programming concepts [2]. Another one comparing Python and C showed that Python
yielded better outcomes such as exam grades [40]. Even though both latter studies
demonstrated advantages of Python in terms of concept comprehension, failure and
dropout rates were not significantly affected in either of the studies.
….The programming paradigm used has also been researched. As presented in a study
comparing the procedural paradigm using C++ with the object-oriented one using Java,
the results of problem-solving questions overall were not significantly different between
the two approaches [69]. Interestingly, a significant difference was, on the other hand,
found when instead examining the questions individually, favoring the object-oriented
paradigm when dealing to some extent with software design in particular.
….Despite several indications that OOP can be both hard to apply and understand for
novices, the literature failed to collectively conclude that the use of an object-oriented or
more complex language was either better or worse for learning concepts or producing
more favorable outcomes. What was more conspicuous was that only syntactic
simplicity, as represented in part by Python, did not appear to be the sole nor best
indicator of being an easy language for understanding concepts. More effective
indicators may exist in other syntactic design choices as well as other factors.
….It should be noted, nonetheless, that even though concepts may be perfectly
understood by a student, it does not necessarily mean that the student can apply them
practically for solving problems, it simply facilitates it [1].

4.4 Misconceptions and Non-Viable Mental Models

Not only can difficulties in conceptual knowledge negatively impact the process of
solving programming problems, but they can also cause significant misconceptions
related to the mental models of novices [17], [18], [29]. Difficulties pertain more to the
lack of understanding whereas misconceptions involve inaccurate understandings often
believed to be correct. Some definitions provided for what misconceptions are include
errors in the understanding of how programming constructs and computers work [70];

21
invalid ideas that conflict with commonly held and accepted ones [71]; and insufficient
understanding in a programming context [72]. A mental model in terms of programming
can be defined as the understanding of what happens behind a particular piece of code,
or one’s explanation of how things work internally [68]; analogical structures
representing the world [73]; and a construct in the working memory of the brain that
supports logical reasoning [73].
….Students hold misconceptions and non-viable mental models of fundamental
concepts, objects, and memory usage, among other things [6], [19]. Analyzing known
ones helps to understand how to address these inaccurate or inadequate models through
means such as language design. Summarized in Table 4.7 are the misconceptions
grouped by category (the IDs are referred to in Appendix B).

TABLE 4.7
Issues and Clues Concerning Misconceptions Among Novice Programmers

Category Description ID

General Significant correlation between programming performance and English M1

ability, with possibility of misconceptions deriving from different
interpretations of natural language.

Data type Divisions with only integers can result in floating point numbers (not M2
true for certain languages).

Variable A variable can hold multiple values at the same time. M3

Nothing happens to the variables of either side of an assignment M4

operator.

Assignments execute simultaneously. M5

Each assignment in each line of code is independent of the other. M6

Assignments do not have to evaluate from right to left. M7

E.g. 1 = x versus x = 1

Associated mistake: Wants to assign the left-hand side variable’s value M8

to the right-hand side’s variable.

Control Program stops executing if an if-statement’s condition evaluates to false. M9

Both blocks of a combined if-else statement are executed. M10

Associated mistake: Wants to execute the then clause of an if-statement M11

even when the condition evaluates to false.

Print statements are the only statements repeated in a multi-line loop M12
(since it is the only visible output).

Function Associated mistake: Wants to store the function object in memory by M13
executing its body.

Associated mistake: Wants to create a local variable called result in the M14
callee function and store the result there to return it.

22
 Associated mistake: Failed to store the return value in the caller’s local M15
variable.

OOP A class represents a collection or set of objects. M16

Manipulating the instance fields of an object is possible without M17

instantiating it first.

Associated mistake: Wants to copy a reference by instantiating a new M18

object.

Associated mistake: Wants to create a new object by copying a M19

reference.

Associated mistake: Wants to call an instance method before having an M20

object reference.

….According to a study analyzing misconceptions of university students using Python

[5], a programming language should facilitate a student’s formation of suitable mental
models through its syntax. The study demonstrated that Python’s syntactic simplicity
often hid its semantic complexity, causing inaccurate mental models and
misconceptions. Some of the misconceptions derived from the plus (+) operator being
overloaded, particularly when used with Python’s list data structure. The authors argued
that if the aim of a course is to provide a good basis for the fundamentals of
programming, then Python alone is not a suitable introductory language.
….Some existing misconceptions found in the literature include believing that the entire
program stops executing if an if-statement’s condition evaluates to false; thinking both
blocks of a combined if-else statement are executed; thinking print statements are the
only statements repeated in a multi-line loop, with the reason being that it is the only
visible output to the user; believing that nothing happens to the variables of either side
of an assignment operator; thinking a variable can hold multiple values at the same
time; and, as expected, believing divisions including only integers can result in floating
point numbers, which is not true for certain languages like Java and C where an integer
divided by a non-zero integer is always an integer [5], [17], [18]. With regard to
object-oriented programming, some novices incorrectly think that a class represents a
set of objects [18] or that manipulating the instance fields of an object is possible
without instantiating it first [35].
….The viability of 90 first-year Java students’ mental models was investigated in a
study [18]. It was found that the percentage of students holding non-viable mental
models of the value and reference assignment was approximately 37% and 83%
respectively. A student was deemed to hold a non-viable model if the model was both
inappropriate and consistently employed, or if different models (including appropriate
ones) were employed inconsistently. In programming tasks performed by the students,
the outcomes of the ones holding viable mental models were significantly better. It was
also found, nonetheless, that good performance in programming tasks was sometimes
still achieved by students despite holding non-viable mental models and that such
models were sometimes held by students even after course completion. Although, what
constitutes good performance may not be clear nor objective. The assessment
techniques may not always be optimal either.
….Motivated by the study evaluating mental model viability, the same authors

23
continued investigating models. In this case they found that 38 (63%) out of 60 Java
students held non-viable mental models pertaining to the value assignment [29]. Some
related to the evaluation order, such as 1 = x versus x = 1, and some to the flow of
execution that derived from the beliefs that the execution of assignments occur
simultaneously and that each line is independent of the other. Regarding reference
assignment, 41 (95%) of 43 Java students held non-viable mental models.
….In order to examine whether or not mistakes made by novices were related to known
misconceptions, data from introductory programming students at a university in Finland
was analyzed [17]. The data derived from visual program simulation exercises. During
the exercises the students graphically traced program execution in the Python language
by dragging, dropping, and clicking on elements. All students were encouraged to act on
their conceptions. The log files of over 24,000 student solutions submitted between
2010 and 2012 were analyzed of which 95% were deemed usable. Only mistakes made
by a minimum of 10 students were accounted for, totalling approximately 200. Some of
the most common mistakes were likely to be associated with misconceptions about
assignments, control structures, and functions. The results from the most recent year
(2012) are presented hereafter. For instance, rather than assigning the right-hand side
variable’s value to the left-hand side variable, 38% of students incorrectly did it the
other way around. When the condition of an if-statement evaluated to false, 17% of
students indicated that they believed the then clause would still be executed. Similarly,
when including the not operator in the condition and it evaluated to false, almost half of
the students (45%) graphically executed the corresponding then clause. As clarification
for the reader, the Python syntax did not explicitly include a then keyword, the term is
merely used here to describe the corresponding execution block. Regarding functions,
16% of students executed the body of a function instead of storing the function object in
memory using Python’s def keyword. Rather than returning the result of a calculation to
the caller, 24% of students created a local variable called result belonging to the callee
and stored the result into that variable. Almost a third (29%) of students also failed to
store the return value in the caller’s local variable. For OOP related mistakes, 14% of
students tried to copy a reference by instantiating a new object, and 18% tried to create
a new object by copying a reference. A third (33%) also tried to call an instance method
before having the object reference. These mistakes seem to reveal various inaccurate
understandings of how certain constructs work, some correlating with previously
presented ones.
….Another source of misconceptions is natural language. Since programming language
syntax is widely influenced by natural language, the words used for certain constructs
may interfere with a student’s understanding of how those constructs work if the
syntactic words do not have similar meaning in everyday life [74]. This in turn allows
for flawed conceptions to form. Noteworthy is also a study done on Chinese students in
their first programming course [75]. Among the things investigated was the correlation
between the performance in programming and the performance in subjects outside of
programming. The results showed that there was a significant correlation between
programming performance and ability of the English language. In fact, the best indicator
of success in the introductory programming course was English ability, more so than
mathematics.
….Lastly, from a theory of learning called constructivism, students form their own
mental models of the concepts they come across whether or not it is taught [76]. Some
thereby claim that the models have to be explicitly taught in order for them to be
effective.

24
4.5 Language Design for Introductory Programming
The designs of programming languages have often presented pedagogical problems
when used for teaching novice students. McIver and Conway [60] elaborated on what
design features they attribute these issues to and proposed design principles to help
avoid including such features in introductory languages. This section presents parts of
McIver and Conway’s paper by first describing some of the problems associated with
various designs (summarized in Table 4.8) and thereafter the proposed principles
(summarized in Table 4.9) (the IDs in Table 4.8 and Table 4.9 are referred to in
Appendix B).

4.5.1 Pedagogical Problems

Grammatical traps represent some of the problematic aspects concerning pedagogy and
can derive from constructs having obscure syntax or semantics. For instance, syntactic
synonyms allow more than one syntax to achieve the same outcome, sowing possible
confusion by no longer mapping a certain concept to one clear syntax. Similarly,
syntactic homonyms are constructs which have the same shared syntax but differ in
semantics depending on the context in which it is used. Another grammatical trap is
elision, or syntactic omission, which occurs when there is default behavior such as
unexpected implicit return values or initialization.
….Constraints of the hardware used, such as which representational precision to use for
a certain data type, can be problematic for novices when simultaneously learning other
aspects of syntax and semantics. The design of numerical and string data types can often
be conceptually equal to the real-world understanding but semantically different, as in
the case of a single character represented by either the character data type or string data
type, or a number represented by data types of varying bit sizes.
….Backward compatibility in terms of being able to reuse skills gained from an earlier
programming language is less useful for someone without prior knowledge. Genetic and
memetic are two types of backward compatibility. Genetic compatibility arises from the
design decisions made to retain some syntax and semantics of an ancestor language.
Problematic characteristics or features could in such cases get inherited by the new
language as well. While this type of inheritance is deliberate, memetic compatibility
results from constructs and symbols being reused unintentionally due to the designer’s
familiarity with programming and its cultural norms.
….One of the most damaging problems to the pedagogical ability of a language is when
reasonable expectations are violated, according to McIver and Conway [60]. Semantics
that conflict with novices’ expectations which have been reasonably derived from the
syntax contribute to more confusion, such as hidden side effects.

25
 TABLE 4.8
Pedagogical Problems in Introductory Programming Language Design

Category Problem Description ID

Grammatical Syntactic synonyms More than one syntax is available to LD1

trap achieve the same outcome.

Syntactic homonyms Constructs that have the same shared LD2

syntax but differ in semantics
depending on the context.

Elision Syntactic omission caused by default LD3

behavior.

Hardware Multiple variations of data Data types that are conceptually equal LD4
dependency types but semantically different.

Backward Genetic compatibility Deliberately reusing syntax and LD5

compatibility semantics of an ancestor language.

Memetic compatibility Unintentionally reusing syntax and LD6

semantics due to familiarity with
programming.

Violation of Syntactic and semantic Semantics that conflict with LD7

expectations conflict reasonable expectations derived from
the syntax.

4.5.2 Design Principles

The design of an introductory programming language should start where the novice is.
Legitimate assumptions of the behavior of the language should coincide with prior
knowledge gained outside of a programming context. Thus, the learning process may be
facilitated if design decisions around the syntax and semantics of various constructs do
not violate expectations.
….Clearly differentiating the semantics of constructs using syntax may also help in the
formation of viable mental models. The syntactic differences act as cues as to what
concepts are represented, making it easier to distinguish between them.
….Another principle is to increase the readability and consistency of the syntax.
Reducing syntactic noise by removing, for instance, parentheses, curly braces, and
semicolons is one possible way of accomplishing this. However, in the case of
homonyms (constructs with similar syntax but different semantics) it may sometimes be
favorable to add to the syntax in order to better differentiate the semantics. To facilitate
the understanding of the underlying concepts, syntactic keywords and operators with
high familiarity should be used.
….Providing a small set of language features that do not overlap can be a way of
minimizing syntactic synonyms and homonyms as well as some hardware dependency
problems. An introductory language may provide high-level abstractions of data types
that are semantically equal (as much as possible) to the conceptual meaning outside of
programming. For instance, having a single shared data type for strings and characters,

26
and one for numerical types. In some cases, instructors would still have to explain the
limitations of representations, such as approximations of certain numerical values.
Additional language features include providing only one construct for representing a
loop, one for a generic list, and one consistent input-output (I/O) syntax.

TABLE 4.9
Principles for Introductory Programming Language Design

Category Principle Description ID

Syntax and Start where the novice is Use syntax and semantics that do LD8
semantics not violate reasonable expectations.

Differentiate semantics Use syntax to differentiate the LD9

semantics of constructs.

Use readable and Reduce syntactic noise and use LD10

consistent syntax keywords and operators familiar in a
non-programming context.

Language Provide a small set of Provide a small set of language LD11

features features features that do not overlap. Use
high-level abstractions of data types
that are semantically and
conceptually equal.

27
5 Frendli – The New Programming Language
Existing general-purpose programming languages have rarely been based on empirical
data derived from human factors, sometimes lacking any evidence at all [30], [31], [32],
[33]. As discussed to a great extent throughout this paper, learning to program poses
many challenges, many of which are unalleviated or even caused by the language itself.
Hence, one of the main goals of this research was ultimately to create a friendlier
language–the Frendli programming language [34].
….This section addresses research question RQ3 by introducing Frendli, its goals,
strategies, and the syntax and semantics of language constructs. Justifications for design
decisions made, such as the reasons for including and excluding various features and
characteristics, are detailed in Appendix B and can be read alongside this section. Each
decision listed in Appendix B references the data presented in Section 4.
….Do note that Frendli is one possible alternative for an introductory language–the one
proposed by the author based on the findings in Section 4–but other syntactic
alternatives are briefly discussed in Section 6.

5.1 Goals and Syntactic Design Strategies

The syntactic design of Frendli followed what the author refers to as novice-oriented,
action-based, and low-conflict approaches as strategies for achieving the goals of the
early version of the language. The goals and strategies are defined and elaborated in the
following subsections and summarized in Table 5.1. The main goals included:
G1: Be a low barrier to entry
G2: Facilitate conceptualization
G3: Be universally transitional
….Being a low barrier to entry (G1) was considered important since the language is
intended as an introductory language with primary users having no prior programming
experience. Difficulties in learning programming affect not only performance, but also
the motivation of students, both contributing to attrition as further elaborated in Section
1.1. Lowering the barrier was thereby an attempt to ease the learning for first-time
programmers.
….Given the frequency of difficulties in understanding concepts and novices holding
misconceptions (see Section 4), facilitating conceptualization (G2) through the syntax
itself was deemed crucial. Helping students form appropriate mental models early on
and lowering the risk of developing inaccurate ones were highly relevant as it may be
hard to change previous understandings of concepts [20].
….The focus of Frendli is on alleviating the initial hurdles of learning programming and
is intended for the early stages of introductory courses before transitioning to a language
more practically useful for the remainder of the student’s program. Hence, being
universally transitional (G3), or allowing transitioning into several of the commonly
used general-purpose languages, was important to allow for an easier transition and to
be a realistic alternative for educational institutions in terms of efficiently incorporating
it into their existing programs. Being available as a language for a larger amount of
introductory courses was taken into consideration by aiming to be transitional for
multiple languages.

28
 TABLE 5.1
Goals and Syntactic Design Strategies

ID Goal Subgoal Definition Strategy

G1 Low barrier to Easy to use and Fewer difficulties and Base design choices on
entry comprehend. misconceptions. known issues.

Less time fixing Exclude superfluous

syntax errors. and error-prone tokens.

Lower degree of Use keywords and

ambiguity. operators synonymous
with intended concept,
high intuitiveness, and
fully spelled out words.
Uphold syntactic and
semantic consistency.
Favor explicitness over
implicitness.

Easier for non-native Avoid seemingly

English speakers. complex or less
common words.

G2 Facilitate con- Illustrate how Higher degree of Use verbs, rather than
ceptualization constructs work self-explanation. nouns, that describe the
and what they do. action being taken and
are synonymous with
the intended concept.

G3 Universally Useful tool for Easier to focus on Use verbs that explain
transitional instructors with teaching the meaning concepts shared by
easy transition. of concepts. languages. Exclude
superfluous tokens.

Not forcing specific Avoid nouns.

entity terminology.

Lower degree of Avoid words and

syntactic, semantic, symbols that conflict
and conceptual with other languages.
conflict.

Higher degree of Resemble pseudo-

programming code to some extent.
language
independence.

Attuned to preferences Consider reasons for

by institutions. adopting a language.

29
5.1.1 Novice-Oriented
The goal of the language was first and foremost to be a low barrier to entry (G1) by
being easy to use and comprehend, in particular for first-time programmers.
Accordingly, the novice programmer was at the center of the design choices made. In
relation to other commonly used general-purpose languages, comprehensibility and ease
of use were for the development of this language defined as: producing fewer
encountered difficulties and misconceptions among novices; requiring less time fixing
syntax errors by excluding superfluous and error-prone tokens in the grammar; having a
lower degree of ambiguity by favoring explicitness over implicitness, having syntactic
and semantic consistency, and using keywords and operators synonymous with the
intended concept, high intuitiveness in terms of its English meaning, and fully spelled
out words; and lastly, posing less translation challenges for non-native English speakers
by avoiding seemingly complex or less common word choices.

5.1.2 Action-Based
In addition to being a low barrier to entry, the second goal of the language was to help
the user conceptualize and form appropriate mental models (G2). The goal can be
broken down into illustrating through the syntax itself how constructs work and what
the code is doing. Thus, rather than using nouns such as variable (or var) as in
variable x = 1 to describe what something is, verbs such as create as in
create x = 1 are used to instead illustrate the action represented by the code. This
was to allow for the code to be more self-explanatory, rather than focusing on the
terminology of individual entities that have previously shown to be the source of many
misconceptions.
….This action-based approach also facilitated certain aspects of the third main goal of
the language which was to be universally transitional (G3). The action-based syntax
may assist introductory programming instructors in introducing and explaining
commonly shared concepts while not being forced to use entity terminology specific to
the Frendli programming language. Depending on the language to transition to, a
function may for instance also be referred to as a method, procedure, subroutine, or
action, and variables may be denoted by a range of different nouns and abbreviations.

5.1.3 Low-Conflict
Not being forced to use specific terminology overlaps somewhat with the low-conflict
approach taken as an additional strategy for achieving the goal of being transitional
(G3). This was to avoid having to unlearn information as opposed to learning more
which may otherwise be caused by syntactic, semantic, and conceptual conflicts with
other languages. Syntactic word choices may represent different concepts depending on
the language. Thus, a lower degree of conflict may increase the ease of transition.
….The languages used for comparison in this approach were Java, C, C++, and Python.
For certain design decisions, achieving low-conflict took precedence over
novice-orientation. This pertained to instances where a particular syntax was shared
across the compared languages and the comprehensibility or ease of use did not seem to
be significantly affected according to the literature reviewed. One distinct example
includes using double quotes ("") for string literals rather than parentheses (()).

30
5.2 Characteristics
The language can generally be characterized as:
1) Text-based
2) High-level
3) General-purpose
4) Dynamically typed
5) Imperative
….Being an early version of the language subject to change, it encompasses a limited,
yet foundational, set of features presented hereafter.

5.2.1 Data Types

The early version of Frendli supports four built-in types: number (representing a
double-precision floating point number2), text (representing a sequence of characters,
excluding the double quote character and newline, enclosed in double quotes),
boolean (representing a two-state value), and empty (representing the absence of a
value). See Table B.2 in Appendix B for justifications.

5.2.2 Comments and Blank Lines

A single-line, or end-of-line, comment starts with two forward slashes (//) and ends at
the end of the line. A comment can start anywhere on the line. All characters following
the two slashes are ignored by the language and, thus, are not semantically significant.
….Blank lines are also ignored and include lines with only comments, whitespace, a
newline character, or a combination thereof. See Table B.1 in Appendix B for
justifications.

5.2.3 Indentation, Block, and Scope

A block is a group of one or more statements and is delimited using whitespace
indentation. Hence, whitespace in the beginning of a line is semantically significant.
The body of compound statements is always a block and must always begin with an
increase in indentation and end with a decrease in indentation (similar to Python). Each
indentation must consist of either tabs only or spaces only. See Table B.6 in Appendix B
for justifications.
….Bindings, such as variable names to values, are lexically scoped. Declaring a variable
in an inner block with the same name as one in an outer block creates a new local
variable and hides the outer one during execution of the inner block (similar to Java and
C). Assigning and referencing a variable in an inner block/scope searches for its
preceding declaration starting from the innermost scope outward. Declarations are
allowed anywhere in a block.

5.2.4 Identifiers and Keywords

The names of the entities such as variables and functions of a program are known as
identifiers and are case-sensitive. Valid identifiers include alphanumeric characters

2
Floating-point arithmetic uses the IEEE 754 standard and, thus, inherits the limitations thereof [77].

31
(characters from the English alphabet and, but not prefixed with, the digits 0 through 9)
as well as underscores. Reserved keywords cannot be used as identifiers. The reserved
keywords for the early version of the language are listed in alphabetical order below and
are introduced with context in the coming subsections.

accept define if repeat true

and empty not return unequals
change equals or send while
create false otherwise times with

5.2.5 Variables
Frendli is dynamically typed, thus variables may hold values of any of the data types.
Type checking, such as detecting operations involving illegal combinations of types, is
performed at runtime. Explicitly declaring a variable before use is required and is
denoted by the create keyword. Declarations of the same name can only occur once
in the same block. Initialization must be explicitly performed during declaration
(empty can be used as the value if no other value is desired initially). Reassigning
values to variables must be preceded by the change keyword. Examples of variable
declarations, initializations, and a reassignment with literals are shown below. See Table
B.1 and Table B.4 in Appendix B for justifications.
create age = 30 // number
create price = 4.25 // number
create isValid = true // boolean
create isOnline = false // boolean
create firstName = "Jane" // text
create middleName = empty // empty
change middleName = "Mary" // text

5.2.6 Expressions and Operators

Values can be generated by expressions using various operators. The available
comparison operators, which all return a boolean, include < (less than), <= (less than
or equal to), > (greater than), >= (greater than or equal to), equals (equal to), and
unequals (not equal to). The latter two can operate on any value while the remaining
ones only accept numbers.
….The logical operators, all of which also return a boolean, include and (determines
if both values are true), or (determines if at least one of the values is true), and not (if
its operand is true it returns false, otherwise true). Their operands must be of type
boolean (including expressions that evaluate to a boolean).
….The arithmetic operators include + (addition), - (subtraction when used as an infix,
and negation when used as a prefix), * (multiplication), and / (division). Their
respective operands must be of type number, with the sole exception of the + operator
which is overloaded to allow for concatenation of text data types only. Division by
zero is a runtime error. (Modular and integer division are future considerations.)
….The precedence and associativity of the operators are equal to that of Java and C but
may be modified by grouping operations using () (open and close parentheses).
Examples of variables initialized to values through expressions are shown below. See
Table B.3 in Appendix B for justifications.

32
create a = 10 < 20 // true
create b = 10 equals 20 // false
create c = 10 equals "10" // false
create d = not true // false
create e = true and false // false
create f = true or false // true
create g = (10 + 2) / 20 // 0.6
create h = "Ten" + "Twenty" // "TenTwenty"

5.2.7 Statements and Control Flow

Side effects, such as altering the state or displaying something, are actualized through
statements. Hence, unlike expressions, they do not evaluate to a value. Simple
statements are terminated with a new line while the body of compound statements is
always a block (see Section 5.2.3 for the description of a block).
….Statements which produce bindings of new identifiers are declarations and include
create (for variables) and define (for functions). For updating a variable binding,
change is used (such assignments are treated as statements, not expressions).
….Control statements, which do not produce bindings, include if (executes a block if
its condition evaluates to true, otherwise the block of the first subsequent
otherwise if statement whose condition evaluates to true, otherwise the
otherwise statement if present), repeat times (repeatedly executes a block an
exact number of times based on the provided expression, as in repeat
<expression> times, where the number must be able to be represented as a
positive integer), and repeat while (repeatedly executes a block as long as its
condition evaluates to true). Selection and loop constructs are demonstrated below.
See Table B.5 in Appendix B for justifications.
….The final two non-binding statements in the early version of the language are
return with and return (both of which end execution of a function, but the
former explicitly returns a value to the caller while the latter implicitly returns empty
and can only be used when no explicit value should be returned). See Table B.6 in
Appendix B for justifications.
// (a) selection // (b) unbounded loop

create score = 5 create max = 5

create message = "" create count = 0

if score > 10 repeat while count < max

change message = "Good" change count = count + 1
otherwise
change message = "Bad"

// (c) bounded loop // (d) bounded loop

create count = 0 create max = 5

create count = 0
repeat 5 times
change count = count + 1 repeat max times
change count = count + 1

33
5.2.8 Functions
Declaring and defining a function are always performed in tandem using the define
keyword. All functions must have an identifiable name followed by a set of parentheses
enclosing a list of formal parameters (also known simply as parameters). Parameters are
not required in the declaration, but if provided, the list must be preceded by the
accept keyword. The function body is a block and explicitly returns a value if the
return with statement is present and executed; otherwise, if only a return
statement is executed or no return statements are present, it implicitly returns empty.
….Calling a function requires the use of parentheses and must be performed only after it
has been declared. If passing a list of actual parameters (also known as arguments) in
the call, the list must be preceded by the send keyword and must exactly match the
function’s arity (number of expected arguments) as shown below. The parameters are
scoped to the function’s local block. See Table B.6 in Appendix B for justifications.
define add1(accept a, b)
create result = a + b
return with result

define add2(accept a, b)
create result = a + b
return

create result1 = add1(send 2, 3) // 5

create result2 = add2(send 2, 3) // empty

5.2.9 Standard Library

There are two built-in functions: display (accepts any data type and outputs its string
representation) and time (returns the number of milliseconds since the epoch). See
usage examples of both functions below. (Reading keyboard input is a future feature.)
create milliseconds = time()
create seconds = milliseconds / 1000

display(send seconds)

5.2.10 Naming Conventions

The conventions described hereafter are recommendations for how to write Frendli code
and are not enforced by the language. However, if different appropriate conventions are
used in a language being transitioned to, instructors are free to choose whichever will
provide an easier transition for the students. Some conventions include: use camel case
(capitalize all words except the first) for variable and function names; use meaningful
names; do not use abbreviations in names; and use common English words.

5.3 Sample Program

An example of a program written in Frendli is demonstrated in Appendix A.

34
5.4 Justifications
The design decisions made were based on the results of the literature review presented
in Section 4. The results revealed difficulties and misconceptions held by novices as
well as clues as to what decisions may be more appropriate for novices in terms of
syntax and semantics, such as word choice or the level of syntactic simplicity.
….Decisions made are listed and explained in Table B.1, Table B.2, Table B.3, Table
B.4, Table B.5, and Table B.6 in Appendix B. Each decision listed specifies which of
the goals in Table 5.1 it addressed. The specific issue (difficulty, misconception, or
language design problem or principle) found in the literature review that each decision
relates to is also specified when applicable by referring to the IDs given in Table 4.6
(prefixed with D for difficulty), Table 4.7 (prefixed with M for misconception), Table
4.8, and Table 4.9 (the latter two prefixed with LD for language design). C signifies the
decision is related to one or more conflicts. If a specific decision was not found to be
explicitly supported or refuted in the reviewed literature, the decision was instead an
unevaluated attempt to address one or more of the issues found.
….The tables in Appendix B are grouped by category of design decision which include:
1) General
2) Data type
3) Operator
4) Variable
5) Control
6) Function

5.5 Grammar and Implementation

The rules of the language are formally defined using a context-free grammar (CFG).
Both the grammar and the interpreter source code are available on GitHub at
https://github.com/frendlilang [34]. The implementation is under active development. A
pedagogical introduction to the language, documentation, and an online code editor for
writing and executing Frendli code will be available at https://frendli.dev.

35
6 Discussion
This section briefly discusses alternative designs of the Frendli programming language
and introduces the syntax of Quorum–another novice-oriented, evidence-based, and
general-purpose programming language [58]. Limitations and threats to validity of the
research are discussed in the last subsection.

6.1 Alternative Programming Language Designs

Recognizing and evaluating alternative designs is important so that individual design
choices can be more confidently supported or rejected. Frendli is as of now dynamically
typed; however, static typing has shown to be beneficial particularly in regard to the
maintainability of software [78]. Whether a static type system would be better aligned
with the goals of Frendli is not entirely clear, especially for a language primarily
intended for use in the earlier stages of learning, rather than where the maintenance of
codebases is of higher priority. The code example below shows a variant of the Frendli
syntax using a static type system.
create number age = 30
create boolean isValid = true
create text name = "Jane"

define add(accept number a, number b) returns with number

create number result = a + b
return with result

create number result = add(send 1, 2)

….Some of the more difficult aspects for novices that became apparent pertained to
functions and the flow of data during function calls. This was addressed in Frendli
partly by having the argument list be preceded by send and the parameter list by
accept as shown in Section 5.2.8. A possible alternative is for each argument to be
preceded by the corresponding parameter name and a colon (:) as shown in the example
below. This may clarify the relationship between individual arguments and parameters.
However, the overall effect on the understanding of data flow is again unclear, but
evaluations are strongly encouraged.
define add(a, b)
create result = a + b
return with result

create result = add(a: 1, b: 2)

….Frendli resembles pseudocode to a certain extent by using syntax that make
grammatical sense in the English language in order to more easily read and reason
around universal concepts. Although, the readability could speculatively improve if
increasing the degree of resemblance to natural language. The example below illustrates
an alternative to variable declaration and initialization.
set score to 5

36
….Even though the readability may increase in the above example, other disadvantages
emerge. The word set may be less effective than create in illustrating the start of a
variable’s lifetime, or may not distinguish equally well between declaring and updating
a variable. Moreover, if one of the goals for the language is to also be transitional, using
= instead of to as an assignment operator is likely favorable since it is commonly used,
as long as the readability is not significantly affected. Given that the = symbol was
shown to be highly intuitive for novices suggests that a rejection of the word to may
not be at the cost of significant readability.
….On the other hand, the = symbol conflicts in several ways to its conventional use in
mathematics for denoting equality. While the mathematical equation x = 1 can be
written as 1 = x, the same is not true for programming languages which distinguish
between l-values (the memory location) and r-values (the right-hand side value to store
in the memory location). As presented in Section 4.4, it is a common misconception that
assignments in programming do not always evaluate from right to left. Removing the
resemblance to mathematics as it in this case has different semantics may alleviate the
corresponding issue. The examples below show the initialization of a variable using the
: symbol (left) and <- symbol (right).
create score: 5 or create score <- 5
….The removal of = for assignment instead allows the symbol to be used exclusively as
an equality operator where the conventions of mathematics are similar in terms of both
equality and allowing values to be positioned on either side (see examples below).
if score = 5 or if 5 = score
….Additionally, changes applied to either side of the equal sign in a mathematical
equation (for instance, adding 1) need to be equally applied to the other side as well, as
in x + 1 = 1 + 1. The use of = for assignment in programming also conflicts with this
convention. Replacing = with : in the examples below illustrates the reduction in
mathematical resemblance which becomes even more conspicuous for languages that
omit keywords for declarations and reassignments.
create score = 5 or create score: 5
change score = 5 + 1 change score: 5 + 1
….The programming language Quorum should also be considered by institutions and
language designers. The studies from which the language derived are introduced in
Section 2.1 and several of their findings are presented throughout Section 4. The results
yielded possible naming alternatives more descriptively appropriate, many of which
Frendli is based on. Below are examples of an if-else statement (left) as well as a
bounded loop (right) in Quorum.

number score = 5.1 integer count = 0

text message = ""
repeat 5 times
if score > 10 count = count + 1
message = "Good" end
else
message = "Bad"
end

37
….The concept of a function is called an action in Quorum, given the high intuitiveness
of the word found in the studies. All programs start execution at the Main action (see
example below). Quorum is statically typed but uses a type inference system that allows
the types of variables within function bodies to be inferred rather than explicitly
declared.
action Main
number result = Add(3, 2)
end

action Add(number a, number b) returns number

number result = a + b
return result
end

6.2 Validity
Conclusions and decisions were derived from the results of the literature review; hence,
the limitations associated with the review should be acknowledged. Constrained
resources included the total time allocated (approximately 17 weeks) as well as the
number of authors (1), consequently limiting the comprehensiveness of the review.
Unintentional bias in literature selection and unintentional exclusions of relevant papers
due to, for instance, the choice of query strings are other internal validity concerns.
Even though the results still demonstrate multiple relevant challenges pertaining to
novice programmers, it is possible that other aspects not covered by the literature review
present greater difficulties or even contradictions. Important to consider is also how
much of the results can be attributed solely to the programming language itself. External
factors such as instructional approach or homogeneity of individual universities,
programs, or courses may have biased or otherwise affected the results and the
generalizability thereof. Thus, isolating the programming language as one independent
variable may not always be clear-cut. To mitigate such risks and reduce their potential
impact, studies entailing multiple universities and students were included in the
findings.
….Additionally, the limitations and threats to validity of each referenced paper
inevitably apply to the respective results presented in this paper. Surveys, such as the
ones conducted on the intuitiveness of word choices in the development and evaluation
of the Quorum language [14], [23], are not free from the risk of bias. The design, order,
and word choices of the questions impact how well they test the intended concepts and
thereby the results. Although, the methodological rigor of the studies around Quorum
allowed for a higher degree of confidence in presenting their quantitative results.

38
7 Future Work
Evaluations of Frendli as well as comparisons of alternative languages and syntax are
encouraged for future work. Its usefulness to instructors for teaching concepts and as a
universally transitional language is also yet to be determined. As McIver and Conway
[60] state, the success of an introductory language is most meaningfully measured by
the outcomes of students’ encounters with the language. Accordingly, such outcomes
ought to influence how a language design evolves, rather than deciding on a permanent
one without being susceptible to change.
….As for near to intermediate-term additions to the language, an array data structure is
of high priority. More research around suitable naming alternatives, properties, and
methods will be conducted prior. There will be more support for I/O operations,
arithmetic operators such as modulus, control statements for exiting a loop early, a
built-in function for checking the data type of a variable, and functions for type
conversion. Additionally, having all values, including primitive ones, be an instance of a
class in order to allow for type-specific methods will be researched.
….A critical part of learning to program which was not presented in this research
pertains to debugging. Interpreting error messages and correcting errors have proven to
be difficult tasks for novices, but there is certainly room for improvement in this part of
language design and implementation [6], [60], [79]. Difficulties often stem from terse
and uninformative error messages, providing little guidance especially for first-time
programmers. Frendli’s error reporter will strive to provide a friendlier interaction with
its users, aligned with the overall goals of the language (see Section 5.1). As an
example, one programming language that prioritizes user experience and deviates
greatly from the traditional structure of error messages is Elm [80]. More research in
this area and more languages providing a user-friendly debugging experience would
likely be well-received.
….Although not investigated, the creation of Frendli can hopefully contribute to the
blind programming community as well, as Stefik and Gellenbeck [23] point out that
well-selected syntax based on empirical data will help future studies on how to alleviate
programming for the blind. For instance, rather than hearing the line if x == y ||
x == z as “if x equals equals y bar bar x equals equals z”, the screen reader would say
“if x equals y or x equals z” using the Frendli syntax.

39
8 Conclusion
Several difficulties and misconceptions pertaining to novice programmers have been
presented, as well as languages used by universities and the reasons thereof. A new
programming language called Frendli was proposed and developed, showcasing how
known issues could be syntactically and semantically exploited with the ultimate goal of
benefiting students learning to program.
….Educational institutions use a range of different programming languages in
introductory courses, most commonly represented by Java and Python. Although, one
must not conclude that there can be a single language that fits all programs equally well.
Different programs may have different specializations, opting for languages more
aligned with courses to come. It is safe to assume, nonetheless, that institutions and
students stand to benefit from prioritizing making it as easy as possible for novices in
the early stages of learning. Despite ease of learning being a main reason for using a
specific language in introductory courses, it seemed to be based on perception more so
than actual data, especially given the apparent lack of wide empirical support of the
notion that Python is easy. With regard to designing a language suitable for use in
introductory courses, the fact that other reasons such as language features and industry
relevance also were considered important implies that merely focusing on making it
easy to learn will likely not be enough for adoption–a likelihood that should clearly be
taken into consideration. Although it does still indicate the importance of such a
language characteristic as viewed by the educational institutions.
….What demonstrated more unanimity in the literature was the notion that novices
often struggle with programming. This struggle may be attributed partly to the intricate
nature of programming itself. Since learning new material with high element
interactivity may intrinsically have a high cognitive load, it seems plausible that
programming could inherit certain characteristics that induce and require more mentally
strenuous efforts. When learning to program, as more elements interact and the need to
comprehend how they communicate grows, the intrinsic cognitive load should
consequently increase. It could thereby be beneficial to try to make it easier in other
areas. One such area could be the choice of programming language. For instance, a
simpler syntax and more intuitive keywords may reduce the number of pieces required
to learn along with their unnecessarily added cognitive load. The potential consequences
of the resistance experienced by an increase in cognitive load deserve consideration
since it may affect students differently. It could perhaps cost some their motivation or
contribute to attrition.
….The challenges of learning programming can also be attributed to the difficulties and
misconceptions that derive from, or go unassisted by, the programming language used.
Traditional C-style syntax can cause several usability issues for novices. In contrast, a
simpler syntax often reduces the number of syntax errors, allowing more attention to be
paid to other aspects. However, it is also evident from the literature reviewed that
syntactic simplicity is not always equivalent to ease of learning. When simplicity causes
a lack of clarity it sometimes takes longer to comprehend or allows students to
unknowingly form inaccurate understandings. Thus, the benefits of being syntactically
simpler need to be carefully weighed against the potential tradeoffs. Exploiting such
data in the design of new languages could consequently make for better suited
introductory languages. Moreover, since priorly held concepts may be hard to change
[20], it further demonstrates the importance of helping students form viable mental
models early on. Addressing these aspects in the syntactic and semantic design of
languages could facilitate appropriate conceptualizations while simultaneously making

40
it harder to form damaging mental models. From reviewing the literature, the author
would argue that good candidates for a suitable introductory language are ones that
intuitively convey universal programming concepts through its syntax, minimize
interference and ambiguity of syntax, and provide appropriate syntactic and semantic
consistency to also reduce unnecessary cognitive load that would otherwise impede
students’ learning. Additionally, more consideration for non-native English speakers
ought to be given in programming language design. Frendli is one attempt at such a
language.
….This paper focused specifically on the text-based programming language, but it is
also plausible that other aspects can have significant impact on both learning and
teaching programming, such as visualization and interactive tools, dual-modality
instruction (using both block-based and text-based languages), learning problem solving
prior to programming, learning syntax prior to programming, game-based learning for
motivational purposes, integration of cognitive conflict (challenging pre-existing
notions), and developing a concept inventory (probing students’ conceptual
understandings) [2], [6], [13], [17], [28], [29], [39], [81], [82].
….More of the programming community should acknowledge the numerous ways in
which programming languages can be more accommodating to us as humans if based on
human data. Being a language intended for use in introductory programming courses,
Frendli will continue to evolve as more data and new evidence from studies emerge.
Finally, the author hopes to motivate other language designers to design more
responsibly, given the unequivocal impact it has on our future programmers.

41
References
[1] E. Lahtinen, K. Ala-Mutka, and H.-M. Järvinen, “A study of the difficulties of novice
programmers,” ACM SIGCSE Bulletin, vol. 37, no. 3, pp. 14–18, Sep. 2005, doi:
10.1145/1151954.1067453.
[2] T. Koulouri, S. Lauria, and R. D. Macredie, “Teaching introductory programming: a
quantitative evaluation of different approaches,” ACM Transactions on Computing
Education, vol. 14, no. 4, pp. 1–28, Feb. 2015, doi: 10.1145/2662412.
[3] W. M. Kunkle and R. B. Allen, “The impact of different teaching approaches and
languages on student learning of introductory programming concepts,” ACM
Transactions on Computing Education, vol. 16, no. 1, pp. 1–26, Feb. 2016, doi:
10.1145/2785807.
[4] A. Robins, J. Rountree, and N. Rountree, “Learning and teaching programming: A
review and discussion,” Computer Science Education, vol. 13, no. 2, pp. 137–172, Jun.
2003, doi: 10.1076/csed.13.2.137.14200.
[5] Y. Qian and J. Lehman, “Students’ misconceptions and other difficulties in introductory
programming,” ACM Transactions on Computing Education, vol. 18, no. 1, pp. 1–24,
Dec. 2017, doi: 10.1145/3077618.
[6] A. Luxton-Reilly et al., “Introductory programming: a systematic literature review,” in
Proceedings Companion of the 23rd Annual ACM Conference on Innovation and
Technology in Computer Science Education - ITiCSE 2018 Companion, Larnaca Cyprus,
2018, pp. 55–106. doi: 10.1145/3293881.3295779.
[7] P. J. Denning and A. McGettrick, “Recentering computer science,” Communications of
the ACM, vol. 48, no. 11, pp. 15–19, Nov. 2005, doi: 10.1145/1096000.1096018.
[8] T. Beaubouef and J. Mason, “Why the high attrition rate for computer science students:
some thoughts and observations,” ACM SIGCSE Bulletin, vol. 37, no. 2, pp. 103–106,
Jun. 2005, doi: 10.1145/1083431.1083474.
[9] J. Bennedsen and M. E. Caspersen, “Failure rates in introductory programming: 12 years
later,” ACM Inroads, vol. 10, no. 2, pp. 30–36, Apr. 2019, doi: 10.1145/3324888.
[10] C. Watson and F. W. B. Li, “Failure rates in introductory programming revisited,” in
Proceedings of the 2014 conference on Innovation & technology in computer science
education - ITiCSE ’14, Uppsala Sweden, 2014, pp. 39–44. doi:
10.1145/2591708.2591749.
[11] P. Kinnunen and L. Malmi, “Why students drop out CS1 course?,” in Proceedings of the
Second International Workshop on Computing Education Research, Canterbury United
Kingdom, 2006, pp. 97–108. doi: 10.1145/1151588.1151604.
[12] O. Ezenwoye, “What language? - The choice of an introductory programming
language,” in 2018 IEEE Frontiers in Education Conference (FIE), San Jose California
USA, Oct. 2018, pp. 1–8. doi: 10.1109/FIE.2018.8658592.
[13] A. Vihavainen, J. Airaksinen, and C. Watson, “A systematic review of approaches for
teaching introductory programming and their influence on success,” in Proceedings of
the tenth annual conference on International computing education research - ICER ’14,
Glasgow Scotland United Kingdom, 2014, pp. 19–26. doi: 10.1145/2632320.2632349.
[14] A. Stefik and S. Siebert, “An empirical investigation into programming language
syntax,” ACM Transactions on Computing Education, vol. 13, no. 4, pp. 1–40, Nov.
2013, doi: 10.1145/2534973.
[15] M. Lopez, J. Whalley, P. Robbins, and R. Lister, “Relationships between reading, tracing
and writing skills in introductory programming,” in Proceedings of the fourth
international workshop on Computing education research - ICER ’08, Sydney Australia,

42
 2008, pp. 101–112. doi: 10.1145/1404520.1404531.
[16] A. Venables, G. Tan, and R. Lister, “A closer look at tracing, explaining and code
writing skills in the novice programmer,” in Proceedings of the fifth international
workshop on Computing education research workshop - ICER ’09, Berkeley California
USA, 2009, pp. 117–128. doi: 10.1145/1584322.1584336.
[17] T. Sirkiä and J. Sorva, “Exploring programming misconceptions,” in Proceedings of the
12th Koli Calling International Conference on Computing Education Research - Koli
Calling ’12, Koli Finland, 2012, pp. 19–28. doi: 10.1145/2401796.2401799.
[18] L. Ma, J. Ferguson, M. Roper, and M. Wood, “Investigating the viability of mental
models held by novice programmers,” in Proceedings of the 38th SIGCSE technical
symposium on computer science education - SIGCSE ’07, Covington Kentucky USA,
2007, pp. 499–503. doi: 10.1145/1227310.1227481.
[19] L. C. Kaczmarczyk, E. R. Petrick, J. P. East, and G. L. Herman, “Identifying student
misconceptions of programming,” in Proceedings of the 41st ACM technical symposium
on Computer science education - SIGCSE ’10, Milwaukee Wisconsin USA, 2010, pp.
107–111. doi: 10.1145/1734263.1734299.
[20] J. Nussbaum and S. Novick, “Alternative frameworks, conceptual conflict and
accommodation: Toward a principled teaching strategy,” Instructional Science, vol. 11,
no. 3, pp. 183–200, Dec. 1982, doi: 10.1007/bf00414279.
[21] P. Denny, A. Luxton-Reilly, and E. Tempero, “All syntax errors are not equal,” in
Proceedings of the 17th ACM annual conference on Innovation and technology in
computer science education - ITiCSE ’12, Haifa Israel, 2012, pp. 75–80. doi:
10.1145/2325296.2325318.
[22] A. Altadmri and N. C. C. Brown, “37 million compilations: Investigating novice
programming mistakes in large-scale student data,” in Proceedings of the 46th ACM
Technical Symposium on Computer Science Education, Kansas City Missouri USA, Feb.
2015, pp. 522–527. doi: 10.1145/2676723.2677258.
[23] A. Stefik and E. Gellenbeck, “Empirical studies on programming language stimuli,”
Software Quality Journal, vol. 19, no. 1, pp. 65–99, Feb. 2011, doi:
10.1007/s11219-010-9106-7.
[24] M. C. Jadud, “A first look at novice compilation behaviour using BlueJ,” Computer
Science Education, vol. 15, no. 1, pp. 25–40, Mar. 2005, doi:
10.1080/08993400500056530.
[25] F. Johnson, S. McQuistin, and J. O’Donnell, “Analysis of student misconceptions using
Python as an introductory programming language,” in Proceedings of the 4th
Conference on Computing Education Practice 2020, Durham United Kingdom, Jan.
2020, pp. 1–4. doi: 10.1145/3372356.3372360.
[26] E. Kurvinen, N. Hellgren, E. Kaila, M.-J. Laakso, and T. Salakoski, “Programming
misconceptions in an introductory level programming course exam,” in Proceedings of
the 2016 ACM Conference on Innovation and Technology in Computer Science
Education, Arequipa Peru, Jul. 2016, pp. 308–313. doi: 10.1145/2899415.2899447.
[27] N. Alzahrani, F. Vahid, A. Edgcomb, K. Nguyen, and R. Lysecky, “Python versus C++:
An analysis of student struggle on small coding exercises in introductory programming
courses,” Baltimore Maryland USA, Feb. 2018. doi: 10.1145/3159450.3160586.
[28] R. Caceffo, S. Wolfman, K. S. Booth, and R. Azevedo, “Developing a computer science
concept inventory for introductory programming,” in Proceedings of the 47th ACM
Technical Symposium on Computing Science Education, Memphis Tennessee USA, Feb.
2016, pp. 364–369. doi: 10.1145/2839509.2844559.
[29] L. Ma, J. Ferguson, M. Roper, and M. Wood, “Investigating and improving the models

43
 of programming concepts held by novice programmers,” Computer Science Education,
vol. 21, no. 1, pp. 57–80, Mar. 2011, doi: 10.1080/08993408.2011.554722.
[30] S. Hanenberg, “Faith, hope, and love: an essay on software science’s neglect of human
factors,” in Proceedings of the ACM international conference on object oriented
programming systems languages and applications - OOPSLA ’10, Reno/Tahoe Nevada
USA, 2010, pp. 933–946. doi: 10.1145/1869459.1869536.
[31] A. Stefik, S. Hanenberg, M. McKenney, A. Andrews, S. K. Yellanki, and S. Siebert,
“What is the foundation of evidence of human factors decisions in language design? an
empirical study on programming language workshops,” in Proceedings of the 22nd
International Conference on Program Comprehension - ICPC 2014, Hyderabad India,
2014, pp. 223–231. doi: 10.1145/2597008.2597154.
[32] S. Markstrum, “Staking claims: a history of programming language design claims and
evidence,” in Evaluation and Usability of Programming Languages and Tools on -
PLATEAU ’10, Reno Nevada, 2010, pp. 1–5. doi: 10.1145/1937117.1937124.
[33] A. Stefik and S. Hanenberg, “The programming language wars: questions and
responsibilities for the programming language community,” Portland Oregon USA, Oct.
2014. doi: 10.1145/2661136.2661156.
[34] L. Jansson, “Frendli,” GitHub, 2022. https://github.com/frendlilang (Accessed Apr. 04,
2022).
[35] A. E. Fleury, “Programming in Java: student-constructed rules,” in Proceedings of the
thirty-first SIGCSE technical symposium on computer science education - SIGCSE ’00,
Austin Texas USA, 2000, pp. 197–201. doi: 10.1145/330908.331854.
[36] R. P. Medeiros, G. L. Ramalho, and T. P. Falcao, “A systematic literature review on
teaching and learning introductory programming in higher education,” IEEE
Transactions on Education, vol. 62, no. 2, pp. 77–90, May 2019, doi:
10.1109/te.2018.2864133.
[37] P. Denny, A. Luxton-Reilly, E. Tempero, and J. Hendrickx, “Understanding the syntax
barrier for novices,” in Proceedings of the 16th annual joint conference on Innovation
and technology in computer science education - ITiCSE ’11, Darmstadt Germany, 2011,
pp. 208–212. doi: 10.1145/1999747.1999807.
[38] O. Muller, D. Ginat, and B. Haberman, “Pattern-oriented instruction and its influence on
problem decomposition and solution construction,” in Proceedings of the 12th annual
SIGCSE conference on Innovation and technology in computer science education -
ITiCSE ’07, Dundee Scotland, 2007, pp. 151–155. doi: 10.1145/1268784.1268830.
[39] D. Cliburn, “The effectiveness of games as assignments in an introductory programming
course,” in Proceedings. Frontiers in Education. 36th Annual Conference, San Diego
California USA, 2006, pp. 6–10. doi: 10.1109/fie.2006.322314.
[40] J. Wainer and E. C. Xavier, “A controlled experiment on Python vs C for an
introductory programming course,” ACM Transactions on Computing Education, vol.
18, no. 3, pp. 1–16, Sep. 2018, doi: 10.1145/3152894.
[41] J. Hofmeister, J. Siegmund, and D. V. Holt, “Shorter identifier names take longer to
comprehend,” in 2017 IEEE 24th International Conference on Software Analysis,
Evolution and Reengineering (SANER), Klagenfurt Austria, Feb. 2017, pp. 217–227.
doi: 10.1109/saner.2017.7884623.
[42] R. Mason and Simon, “Introductory programming courses in Australasia in 2016,” in
Proceedings of the Nineteenth Australasian Computing Education Conference on - ACE
’17, Geelong VIC Australia, 2017, pp. 81–89. doi: 10.1145/3013499.3013512.
[43] W. Feurzeig and G. Lukas, “LOGO—a programming language for teaching
mathematics,” Educational Technology, vol. 12, no. 3, pp. 39–46, 1972.

44
[44] Logo Foundation, el.media.mit.edu. https://el.media.mit.edu/logo-foundation (Accessed
Jan. 22, 2022).
[45] R. C. Holt and D. B. Wortman, “A sequence of structured subsets of PL/I,” in
Proceedings of the fourth SIGCSE technical symposium on Computer science education
- SIGCSE ’74, 1974, pp. 129–132. doi: 10.1145/800183.810456.
[46] R. C. Holt, D. B. Wortman, D. T. Barnard, and J. R. Cordy, “SP/k: a system for teaching
computer programming,” Communications of the ACM, vol. 20, no. 5, pp. 301–309,
May 1977, doi: 10.1145/359581.359586.
[47] R. C. Holt and J. R. Cordy, “The Turing programming language,” Communications of
the ACM, vol. 31, no. 12, pp. 1410–1423, Dec. 1988, doi: 10.1145/53580.53581.
[48] S. Cooper, W. Dann, and R. Pausch, “Alice: a 3-D tool for introductory programming
concepts,” Journal of computing sciences in colleges, vol. 5, no. 15, pp. 107–116, 2000.
[49] Carnegie Mellon University, “Alice – Tell stories. Build games. Learn to program.,”
Alice.org. https://www.alice.org/ (Accessed Jan. 22, 2022).
[50] J. Maloney, M. Resnick, N. Rusk, B. Silverman, and E. Eastmond, “The Scratch
programming language and environment,” ACM Transactions on Computing Education,
vol. 10, no. 4, pp. 1–15, Nov. 2010, doi: 10.1145/1868358.1868363.
[51] The Scratch Foundation, “Scratch - Imagine, program, share,” Scratch.mit.edu, 2018.
https://scratch.mit.edu/ (Accessed Jan. 22, 2022).
[52] C.-K. Chang, “Effects of using Alice and Scratch in an introductory programming
course for corrective instruction,” Journal of Educational Computing Research, vol. 51,
no. 2, pp. 185–204, Sep. 2014, doi: 10.2190/ec.51.2.c.
[53] E. R. Sykes, “Determining the effectiveness of the 3D Alice programming environment
at the computer science I level,” Journal of Educational Computing Research, vol. 36,
no. 2, pp. 223–244, Mar. 2007, doi: 10.2190/j175-q735-1345-270m.
[54] T.-C. Wang, W.-H. Mei, S.-L. Lin, S.-K. Chiu, and J. M.-C. Lin, “Teaching
programming concepts to high school students with Alice,” in 2009 39th IEEE Frontiers
in Education Conference, San Antonio Texas USA, Oct. 2009, pp. 1–6. doi:
10.1109/FIE.2009.5350486.
[55] D. Weintrop and U. Wilensky, “Using commutative assessments to compare conceptual
understanding in blocks-based and text-based programs,” in Proceedings of the eleventh
annual International Conference on International Computing Education Research -
ICER ’15, Omaha Nebraska USA, 2015, pp. 101–110. doi: 10.1145/2787622.2787721.
[56] D. Franklin, C. Hill, H. A. Dwyer, A. K. Hansen, A. Iveland, and D. B. Harlow,
“Initialization in Scratch: seeking knowledge transfer,” in Proceedings of the 47th ACM
Technical Symposium on Computing Science Education, Memphis Tennessee USA, Feb.
2016, pp. 217–222. doi: 10.1145/2839509.2844569.
[57] Z. Nasrawt and M. Lam, “Less-Java, more learning: language design for introductory
programming,” Journal of Computing Sciences in Colleges, vol. 34, no. 3, pp. 64–72,
2019.
[58] “The Quorum programming language,” Quorumlanguage.com, 2014.
https://quorumlanguage.com/ (Accessed Jan. 22, 2022).
[59] B. Kitchenham, “Procedures for performing systematic reviews,” Keele, UK, Keele
University, vol. 33, no. 2004, pp. 1–26, 2004.
[60] L. McIver and D. Conway, “Seven deadly sins of introductory programming language
design,” in Proceedings 1996 International Conference Software Engineering:
Education and Practice, Dunedin New Zealand, 1996, pp. 309–316. doi:
10.1109/seep.1996.534015.

45
[61] A. Luxton-Reilly, “Learning to program is easy,” in Proceedings of the 2016 ACM
Conference on Innovation and Technology in Computer Science Education, Arequipa
Peru, Jul. 2016, pp. 284–289. doi: 10.1145/2899415.2899432.
[62] D. Teague and R. Lister, “Manifestations of preoperational reasoning on similar
programming tasks,” in Proceedings of the Sixteenth Australasian Computing Education
Conference [Conferences in Research and Practice in Information Technology, Volume
148], Darlinghurst Australia, 2014, pp. 65–74.
[63] J. Sweller, “Cognitive load theory, learning difficulty, and instructional design,”
Learning and Instruction, vol. 4, no. 4, pp. 295–312, Jan. 1994, doi:
10.1016/0959-4752(94)90003-5.
[64] S. Lee et al., “Comparing programming language comprehension between novice and
expert programmers using EEG analysis,” in 2016 IEEE 16th International Conference
on Bioinformatics and Bioengineering (BIBE), Taichung Taiwan, Oct. 2016, pp.
350–355. doi: 10.1109/bibe.2016.30.
[65] I. Drosos, P. J. Guo, and C. Parnin, “HappyFace: identifying and predicting frustrating
obstacles for learning programming at scale,” in 2017 IEEE Symposium on Visual
Languages and Human-Centric Computing (VL/HCC), Raleigh North Carolina USA,
Oct. 2017, pp. 171–179. doi: 10.1109/vlhcc.2017.8103465.
[66] K. Fisler, “The recurring rainfall problem,” in Proceedings of the tenth annual
conference on International computing education research - ICER ’14, Glasgow
Scotland United Kingdom, 2014, pp. 35–42. doi: 10.1145/2632320.2632346.
[67] A. E. Tew and M. Guzdial, “The FCS1: a language independent assessment of CS1
knowledge,” in Proceedings of the 42nd ACM technical symposium on Computer
science education - SIGCSE ’11, Dallas Texas USA, 2011, pp. 111–116. doi:
10.1145/1953163.1953200.
[68] P. Bayman and R. E. Mayer, “A diagnosis of beginning programmers’ misconceptions
of BASIC programming statements,” Communications of the ACM, vol. 26, no. 9, pp.
677–679, Sep. 1983, doi: 10.1145/358172.358408.
[69] T. Vilner, E. Zur, and J. Gal-Ezer, “Fundamental concepts of CS1,” ACM SIGCSE
Bulletin, vol. 39, no. 3, pp. 171–175, Jun. 2007, doi: 10.1145/1269900.1268835.
[70] T. J. McGill and S. E. Volet, “A conceptual framework for analyzing students’
knowledge of programming,” Journal of Research on Computing in Education, vol. 29,
no. 3, pp. 276–297, Mar. 1997, doi: 10.1080/08886504.1997.10782199.
[71] J. P. Smith III, A. A. diSessa, and J. Roschelle, “Misconceptions reconceived: a
constructivist analysis of knowledge in transition,” Journal of the Learning Sciences,
vol. 3, no. 2, pp. 115–163, Apr. 1994, doi: 10.1207/s15327809jls0302_1.
[72] J. Sorva, V. Karavirta, and L. Malmi, “A review of generic program visualization
systems for introductory programming education,” ACM Transactions on Computing
Education, vol. 13, no. 4, pp. 1–64, Nov. 2013, doi: 10.1145/2490822.
[73] P. N. Johnson-Laird, “Mental models in cognitive science,” Cognitive Science, vol. 4,
no. 1, pp. 71–115, Mar. 1981, doi: 10.1016/s0364-0213(81)80005-5.
[74] A. Bruckman and E. Edwards, “Should we leverage natural-language knowledge? An
analysis of user errors in a natural-language-style programming language,” in
Proceedings of the SIGCHI conference on Human factors in computing systems the CHI
is the limit - CHI ’99, Pittsburgh Pennsylvania USA, 1999, pp. 207–214. doi:
10.1145/302979.303040.
[75] Y. Qian and J. D. Lehman, “Correlates of success in introductory programming: a study
with middle school students,” Journal of Education and Learning, vol. 5, no. 2, p. 73,
Mar. 2016, doi: 10.5539/jel.v5n2p73.

46
[76] M. Ben-Ari, “Constructivism in computer science education,” ACM SIGCSE Bulletin,
vol. 30, no. 1, pp. 257–261, Mar. 1998, doi: 10.1145/274790.274308.
[77] D. Goldberg, “What every computer scientist should know about floating-point
arithmetic,” ACM Computing Surveys, vol. 23, no. 1, pp. 5–48, 1991, doi:
10.1145/103162.103163.
[78] S. Kleinschmager, S. Hanenberg, R. Robbes, and A. Stefik, “Do static type systems
improve the maintainability of software systems? An empirical study,” in 2012 20th
IEEE International Conference on Program Comprehension (ICPC), Passau Germany,
Jun. 2012, pp. 153–162. doi: 10.1109/icpc.2012.6240483.
[79] B. A. Becker, “An effective approach to enhancing compiler error messages,” in
Proceedings of the 47th ACM Technical Symposium on Computing Science Education,
Memphis Tennessee USA, Feb. 2016, pp. 126–131. doi: 10.1145/2839509.2844584.
[80] E. Czaplicki, “Compiler errors for humans,” Elm-lang.org, Jun. 30, 2015.
https://elm-lang.org/news/compiler-errors-for-humans (Accessed Apr. 26, 2022).
[81] J. Blanchard, C. Gardner-McCune, and L. Anthony, “Dual-modality instruction and
learning,” in Proceedings of the 51st ACM Technical Symposium on Computer Science
Education, Portland Oregon USA, Feb. 2020, pp. 818–824. doi:
10.1145/3328778.3366865.
[82] J. Edwards, J. Ditton, D. Trninic, H. Swanson, S. Sullivan, and C. Mano, “Syntax
exercises in CS1,” in Proceedings of the 2020 ACM Conference on International
Computing Education Research, Virtual Event New Zealand, Aug. 2020, pp. 216–226.
doi: 10.1145/3372782.3406259.

47
A Sample Program in Frendli
This appendix provides a sample program written in the Frendli programming language.
When executed, the program counts down (displays each number) starting from
parameter count and decremented each time by parameter step. The implementation
below is an iterative solution, but recursive solutions are also supported.
….The function assumes only number data types are passed (a built-in function for
type-checking will be added to the language after more research on suitable design and
naming alternatives have been conducted).

// Display each number down to 0

define countDown(accept count, step)
if count <= 0 or step <= 0
display(send "Count and step must be positive.")
return

repeat while count > 0

display(send count)
change count = count - step

if count equals 0
display(send "You have reached 0!")
otherwise
display(send "You have passed 0..")

// Initialize variables (or pass directly in function call)

create initialCount = 5
create step = 1

// Start the countdown

countDown(send initialCount, step)

48
B Justifications for Design Decisions in Frendli
Table B.1, Table B.2, Table B.3, Table B.4, Table B.5, and Table B.6 list syntactic
design decisions for Frendli. Each decision listed specifies which of the goals in Table
5.1 it addressed. The specific issue (difficulty, misconception, or language design
problem or principle) found in the literature review that each decision relates to is also
specified when applicable by referring to the IDs given in Table 4.6 (prefixed with D for
difficulty), Table 4.7 (prefixed with M for misconception), Table 4.8, and Table 4.9 (the
latter two prefixed with LD for language design). C signifies the decision is related to
one or more conflicts. If a specific decision was not found to be explicitly supported or
refuted in the reviewed literature, the decision was instead an unevaluated attempt to
address one or more of the issues found.

TABLE B.1
Justifications for General Design Decisions
Related ID
Decision Example Explanation Goal Issue

Use verbs for create Attempted to illustrate the G2 -

constructs define action taken in the code, as
verbs linguistically convey
actions.

Do not use nouns variable (1) Attempted to reduce G2 -

for constructs function misconceptions previously G3
shown to derive from the use
of nouns.
(2) Attempted to reduce
conceptual interference with
other languages and allow
instructors to use the
terminology of the language
being transitioned to.

Do not use var (1) Fully spelled out words G1 D2

abbreviations int had faster comprehension
def speed.
elif (2) Attempted to lower the
risk of misinterpretation and
lack of understanding.
(3) Attempted to reduce
additional cognitive load.

Resemble See Section 5.2 Pseudo-code was successful G1 D3

pseudo-code in achieving language G3
independence and to read
and reason around concepts.

Use common create (1) Attempted to ease G1 LD10

simple words change translation for non-native M1
English speakers.

49
 (2) Attempted to increase
familiarity.

Use dynamic create x = 1 The literature reviewed on G1 D16

typing static vs. dynamic for D17
novices was too few to
confidently argue for or
against either, thus was
initially solely based on:
(1) Placing type annotations
had slight difficulty.
(2) Attempted to reduce
additional cognitive load.
(Note) The decision is highly
subject to change, possibly to
strict, inferred, or optional
typing. Static typing has
shown great benefits once
learned and was an important
feature for institutions.

Do not use {} (block) (1) Excluding such symbols G1 D1

superfluous : (block start) had high syntactic accuracy. D4
tokens ; (statement end) (2) Such characters were a D6
() (condition) common source of errors. D31
(3) Attempted to reduce LD10
additional cognitive load.

Do not use end if x < y The word end had low G1 D7

for end of block doA() syntactic accuracy.
end

Use whitespace if x < y (1) Alternatives such as the G1 D1

indentation to doA() symbols { } or the word end D6
delimit a block caused several difficulties D7
(see the two rows above). D31
(2) Attempted to enforce
consistency and structure to
writing code, such as always
needing to start the block on
a new line.

Use // for // comment (1) The symbols // were G1 D8

single-line more intuitive for starting a G3
comments single-line comment.
(2) The symbols // were
shared across multiple
languages.

50
 TABLE B.2
Justifications for Data Type Design Decisions
Related ID
Decision Example Explanation Goal Issue

Use number for number The word number was more G1 D10
numerical types intuitive for an integer and a D11
float.

Use number as 12 / 30 = 0.4 Allowed divisions to act as G1 LD4

a double conventional math. LD7
(Although the limitations of LD8
the IEEE 754 standard for LD11
floating-point arithmetic M2
apply [77])

Use text for text The word text was more G1 D13
textual types intuitive for a list of
characters.

Use "" for a "My Text" (1) The symbols "" were G1 D14
text literal more intuitive for enclosing G3
a list of characters.
(2) The symbols "" were
shared across multiple
languages.

Do not use () (My Text) The symbols ( ) were more G3 C

for a text literal intuitive for enclosing a list D14
of characters, but conflicted
with enclosing parameters
and calling a function.

Use empty for empty The word empty was more G1 D15
the absence of a intuitive for the absence of a
value value.

Use boolean boolean (1) The intuitiveness of G1 D12

for two-state alternative words had no G3 LD10
types clear consistency.
(2) The word boolean had
similar meaning in a
programming context as in
math, i.e. a binary variable.
(3) The word boolean was
shared across multiple
languages.

Use true and true (1) Attempted to illustrate G1 LD10

false for false truth and falsehood as the G3
boolean literals words true and false were
seemingly natural.

51
 (2) The words true and false
were shared across multiple
languages.

TABLE B.3
Justifications for Operator Design Decisions
Related ID
Decision Example Explanation Goal Issue

Use = for create x = 1 (1) The symbol = was more G1 D18

variable intuitive for assigning a G3 D19
assignment value.
(2) The symbol = for
assignment had high
syntactic accuracy.
(3) The symbol = was shared
across multiple languages.

Do not use is x is 1 The word is was more G1 C

for variable intuitive for assigning a G3 D18
assignment value, but: D23
(1) Caused ambiguity as it
was also intuitive for
equality comparison.
(2) Conflicted with concepts
of IS-A relationships.

Do not use to set x to 1 The alternative symbol = G3 D18

for variable was still intuitive while
assignment being shared across multiple
languages, hence the
rejection of the word to was
not at significant cost of
comprehensibility.

Use <, <=, >, >= x < y (1) Allowed comparisons to G1 LD7
for boolean be interpreted as G3 LD8
comparison conventional math. LD10
(2) The symbols were shared
across multiple languages.

Do not use word x less than y The alternative symbols G1 -

replacements for above allowed familiarity G3
<, <=, >, >= from conventional math
while being shared across
multiple languages which
made the verbosity of words
unnecessary.

Use equals for x equals y The word equals had G1 D23

boolean seemingly less ambiguity LD10

52
comparison and conflict than the
alternative words and
symbols below, while being
a direct translation of the
more intuitive equal sign in
singular form.

Do not use == x == y The symbols == were G1 D23

for boolean somewhat intuitive for D24
comparison equality comparison, but had
low syntactic accuracy.

Do not use = for x = y The symbol = was more G1 C

boolean intuitive for equality G3 D18
comparison comparison, but: D23
(1) Caused ambiguity as it LD2
was also intuitive for LD9
variable assignment.
(2) Conflicted with variable
assignment.

Do not use is x is y The word is was more G1 C

for boolean intuitive for equality G3 D18
comparison comparison, but: D23
(1) Caused ambiguity as it
was also intuitive for
variable assignment.
(2) Conflicted with concepts
of IS-A relationships.

Use unequals x unequals y The word unequal was more G1 D25

for boolean intuitive for comparing
comparison inequality, adding an s for
consistency with equals.

Do not use not x not equals y Caused semantic G1 LD2

equals for inconsistency as the word LD9
boolean not was also used for logical
comparison negation.

Use not for not x (1) The word not was G1 LD10
logical negation seemingly common in G3
every-day use.
(2) The symbol ! in other
languages for the same
concept is referred to as not.

Use and and or x and y The words and and or were G1 D26
for logical x or y more intuitive for logical LD10
conjunction conjunction.

Do not use && x && y The symbols && and || were G1 D26
and || for x || y less intuitive for logical

53
logical conjunction.
conjunction

Use +, -, *, / (x + y) * z (1) Allowed arithmetic G1 LD7

for arithmetics operations to be interpreted G3 LD8
and () for as conventional math. LD10
controlling (2) The symbols were shared
precedence across multiple languages.

Use + for text "My" + "Text" The symbol + was more G1 D22
concatenation intuitive for concatenating
characters.

Do not use x++ The symbols ++ in x++ G1 D20

augmented were less intuitive for
assignment incrementing a value.
operators

TABLE B.4
Justifications for Variable Design Decisions
Related ID
Decision Example Explanation Goal Issue

Use create for create x = 1 (1) Attempted to illustrate G2 D27

variable variable lifetime start, as D28
declaration creation is synonymous with LD10
the start of something new. M5
(2) Attempted to illustrate M6
the need for declaring a M7
variable before being used, M8
as creating something may
imply it did not previously
exist and could thereby not
be used until created.
(3) Attempted to illustrate
right-to-left associativity and
reduce similarity of
conventional math where x
can appear on both sides.
(4) Attempted to illustrate
the order of execution of
declarations and
reassignments (see below),
as creation ought to precede
modification.

Use change for change x = 1 (1) Attempted to illustrate G2 D28

variable the need for declarations LD10
reassignment before variables can be used, M5
as changing something may M6

54
 suggest it first has to exist.
(2) Attempted to illustrate
the order of execution of
declarations (see above) and
reassignments, as
modification ought to
succeed creation.
(3) Attempted to illustrate
that reassignments were
allowed and reduce
similarity of conventional
math where the x value is
unchanged in an equation.

Do not use set set x = 1 The word set conflicted with G3 C

for variable set x to 1 names of data structures in
declaration other languages.

TABLE B.5
Justifications for Control Design Decisions
Related ID
Decision Example Explanation Goal Issue

Use if for if x < y The word if was more G1 D29

selection doA() intuitive for conditionally LD10
doing something, and had the
fewest characters.

Use if x < y Attempted to represent the G1 LD10

otherwise for doA() alternative (“else”) clause M1
alternative otherwise more clearly with the M10
selection doB() seemingly more common M11
word otherwise.

Do not use then if x < y then The word then as part of G1 D30
in selection doA() selection constructs had low
syntactic accuracy.

Use repeat repeat 2 times The word repeat and the G1 D32
times for doA() constructs repeat times and G2 D33
bounded loops timesRepeat were more LD10
intuitive for doing something
zero or more times.

Do not use for for i in .. (Unable to show full G1 D32

for bounded for (var i .. examples due to space.) D33
loops The word for and multiple D34
variants of the construct for LD5
were less intuitive for doing
something zero or more
times.

55
Use repeat repeat while x (1) The word repeat and the G1 D32
while for doA() construct while were more G2 D33
unbounded loops intuitive for doing something G3 D34
zero or more times. LD10
(2) The word while had
significantly fewer
characters than the
speculatively less ambiguous
as long as.
(3) The word while was
shared across multiple
languages.

Do not use only while x < 2 (1) The word while was less G1 D29
while for doA() intuitive for doing something G2 D32
unbounded loops zero or more times, and more D34
intuitive for selection.
(2) Reduced consistency
between loop constructs.
(3) The lack of a preceding
verb abated the attempt to
illustrate a repetitive action.

TABLE B.6
Justifications for Function Design Decisions
Related ID
Decision Example Explanation Goal Issue

Use define for define get() Attempted to illustrate the G2 LD10

function purpose of a function and
definition that the action must be
decided by the user, as
defining something may
imply specifying how it acts
(its behavior).

Use accept for define get( (Unable to show example on G2 D38

function accept id one line due to space.) D39
parameters ) (1) Attempted to illustrate LD10
that data can be received.
(2) Attempted to illustrate
the data flow in function
calls, specifically to where
arguments are sent
(acceptor/receiver).
(3) Attempted to illustrate
the requirements of
arguments passed, as
acceptance was also
synonymous with

56
 approval/permission.

Do not use define get( (Unable to show example on G1 -

receive for receive id one line due to space.) G2
function ) Although a good candidate
parameters for illustrating data flow in
function calls, the word
receive was in comparison to
the above alternative:
(1) Speculatively more prone
to misspelling.
(2) Speculatively less
indicative of a requirement
as well.

Use send for get(send 1) (1) Attempted to illustrate G2 D38

argument passing that data can be sent. D39
(2) Attempted to illustrate D40
the data flow in function LD10
calls, specifically from where
arguments are sent and to
where results are returned
(sender).

Do not use pass get(pass 1) (1) Increased ambiguity due G1 C

for argument to synonymous incorrect G3 LD7
passing notions such as “to skip”. LD8
(2) Conflicted with the
placeholder keyword “pass”
used in Python.

Do not use a do get() Increased syntactic and G1 -

preceding verb perform get() semantic complexity in
for function calls scenarios such as method
chaining. Ambiguity in
structure and precedence
arose as seen by some
possible alternatives:
do get().find()
do get().do find()
do get().(do find())
do list.size()
list.do size()
list.(do size())

Use return define get() (1) Attempted to illustrate G1 D40

with for return with 1 that code execution can go G2 D41
returning with back to a previous point LD10
explicit value along with data. M14
(2) Attempted to illustrate M15
the data flow in function
calls, specifically from where

57
 results are returned.
(3) Attempted to reduce
ambiguity of possible
manipulation of the return
value by including with.
(4) Attempted to make
implicit returns of empty
more intuitive (which occurs
in the absence of the word
with), as not returning with
anything is synonymous to
returning empty handed.

Use return for define get() Attempted to illustrate that G2 LD10

returning without return code execution can go back
explicit value to a previous point.

Use () for get() The symbols ( ) were shared G3 -

function call across multiple languages.

Use display display( (Unable to show example on G1 D42

as output/print send "Hi" one line due to space.) D43
function ) The word display was more LD10
intuitive for outputting data.

58