Online Polyglot Programming Education with LFT (Lingua Franca

Transformer)

Sokratis Karkalas

, Filothei Chalvatza

and Manolis Mavrikis

Simple, Farkadona, Greece

UCL Knowledge Lab, University of London, London, U.K.

ﬁ

Keywords:

Authoring Tools, Programming Education, Exploratory Learning, Web Learning Components.

Abstract:

This paper presents a novel approach to improve reusability and augment the educational value of web com-

ponents through a polyglot environment. The idea is to enable communication with web components in a

language neutral context by provisioning, along with the instructions, the grammar speciﬁcation of the lan-

guage used for those instructions and thus make the system agnostic of the language being used. This ability

promotes reusability in the sense that learning designers are able to utilise learning materials using the lan-

guage they feel more comfortable with or the language that seems to be more suitable for the task. Another

beneﬁt is that learners can make better use of the same learning environments they are accustomed to using

through different languages. This allows learners to experiment with different programming paradigms, use

more expressive or specialised languages and combine them with the concepts available in the learning envi-

ronment of preference. In the context of this project we developed an authoring environment that allows the

speciﬁcation of any language and the automatic generation of parsers that can be used to dynamically transpile

code into JavaScript. Preliminary testing conﬁrmed that the idea is feasible and gave us positive feedback for

future development.

1 INTRODUCTION

An important aspect of teaching programming to

novices is the choice of language. The language

used to encode concepts and techniques developed

during learning should be expressive enough to carry

them throughout the learning process. Different lan-

guages vary in how specialized they are, how close

they are to the physical architecture of the machine,

and other factors. Not all languages may be suitable

for teaching programming, depending on the educa-

tional course, approach, and other parameters.

The Lingua Franca Transformer (LFT) is a sys-

tem intended for transformations from any language

to JavaScript. LFT is a tool that can be used to de-

velop the deﬁnition of any language and generate the

respective transpiler to JavaScript. The tool can be

used to experiment with new languages designed for

educational or other purposes. LFT makes it possible

to use existing learning environments with different

languages, and new programming languages may also

be deﬁned with the same ease as existing ones.

2 RELATED WORK

The question of which language to use for introduc-

tory programming education is almost as old as CS

education itself (Becker and Quille, 2019; Sobral,

2019) and it is an important one (Laakso et al., 2008;

Minor and Gewali, 2004). Comparisons between dif-

ferent languages and programming paradigms with

respect to the educational value they carry in CS1

courses are a constant and recurring theme in the aca-

demic literature (Smith and Rickman, 1976; Wexel-

blat, 1979; Tharp, 1982; Duke et al., 2000; Mannila

and de Raadt, 2006; Azad and Smith, 2014; Goosen,

2008; Parker et al., 2006; Sobral, 2019; Irimia, 2001;

Wainer and Xavier, 2018; Lewis et al., 2016). Never-

theless it seems that there is still no deﬁnitive answer

as to which should be the most preferable language

to convey the necessary concepts to newcomers in the

discipline. The fact that the Association for Comput-

ing Machinery (ACM) and the Institute of Electrical

and Electronics Engineers (IEEE) have never given

clear curriculum recommendations for this subject is

indicative of the situation (Sobral, 2020). Naturally

decisions about this are being made on an ad hoc ba-

Karkalas, S., Chalvatza, F. and Mavrikis, M.

Online Polyglot Programming Education with LFT (Lingua Franca Transformer).

DOI: 10.5220/0011981400003470

In Proceedings of the 15th International Conference on Computer Supported Education (CSEDU 2023) - Volume 1, pages 305-312

ISBN: 978-989-758-641-5; ISSN: 2184-5026

 2023 by SCITEPRESS – Science and Technology Publications, Lda. Under CC license (CC BY-NC-ND 4.0)

305

sis by course directors and teachers based on criteria

that vary. An extensive list of typical criteria used are

given in (Ezenwoye, 2018; Lindoo, 2020; Naveed

et al., 2018; Sobral, 2019; Irimia, 2001; Wainer and

Xavier, 2018; Sobral, 2021). A mixed approache

that proposes multiple languages for CS1 courses is

given in (Lindoo, 2020) where the use of a multi-

programming language approach reduced the drop-

out rates and increased pass - success rates signiﬁ-

cantly.

Programming is by nature a craft and as such it is

learnt better through experimentation and exploration

in a constructivist context. Learning in this context

is accomplished through personal inquiry, divergent

thinking and self-directed learning (Hannaﬁn et al.,

1999). Naturally, learning environments that promote

that type of learning are virtual worlds (microworlds).

There have been numerous attempts in academia and

the industry to address this need through projects like

(Solomon and Papert, 1976; PATTIS, 1981; Bergin

et al., 1996; Bergin et al., 2005; Becker, 2001; Kahn,

1996; Cooper et al., 2000; Van Haaster and Hagan,

2004; Henriksen and K

olling, 2004; K

olling and Hen-

riksen, 2005; Zschaler et al., 2014; Kynigos and Latsi,

2007; Maloney et al., 2008). In all those cases, the

environments developed are tied to a speciﬁc lan-

guage though. The language used in Turtle Graphics

(Solomon and Papert, 1976; Papert, 1980) and Malt+

(Kynigos and Latsi, 2007) is LOGO and the one used

in Greenfoot (Henriksen and K

olling, 2004) is Java.

Following the discussion above about the ﬂexibility to

allow different languages for introductory program-

ming education we consider this a potentially limiting

factor that imposes considerable constraints when it

comes to utilising those environments and exploiting

the full potential of them. It would be really beneﬁcial

to have the ability to use the same environments with

other languages like C# and Python.

Another challenge that needs to be addressed is

that the de facto platform for development and de-

ployment of educational software nowadays is the

web (Wen et al., 2020). Naturally applications de-

veloped in that context are supposed to be executed

within a web browser. This offers a lot of ﬂexibil-

ity as it allows for easier development, deployment,

maintenance, upgrading and administration but at the

same time it introduces barriers in terms of what can

actually be processed in the context of a browser. The

most obvious concerns are the limitations of mem-

ory, processing resources and dependencies on cer-

tain functionalities. The not so obvious concern but

a crucial one is that the low-level machine language

of the browser is JavaScript. That realisation reveals

an additional concern that regardless of the language

being used to express things at a high level the com-

mon denominator is always JavaScript as execution

takes place in the underlying JavaScript runtime en-

gine supported by the browser. The alternative would

be to utilise a server at the back end to actually pro-

cess requests in native runtime environments and then

send back to the browser the results (Serrano et al.,

2006; Balat et al., 2009). A roundtrip to a server for

every request is not a scalable and therefore viable so-

lution for web deployments, therefore we are not con-

sidering that option at all. Executing everything lo-

cally in the browser, in a disconnected fashion is both

good and bad. The advantage is that it is guaranteed

that standard Javascript will always be the same in any

platform and that means that no recompilation will be

necessary for different machine and platform archi-

tectures. This guarantee of uniformity gives indepen-

dence, ﬂexibility and reduces the cost of developing

solutions. On the ﬂip side though, the limitations and

the somewhat distinct idiosyncrasy of JavaScript will

always be a limiting factor to what can be expressed

and executed in the context of a browser. It is lit-

erally impossible to keep the exact same semantics

between any other language and Javascript and it is

also impossible to rely on certain operating system

abstractions like multi-threading, ﬁle systems and so

on. Thus, the chances are very high that there will

be certain compromises when expressing and execut-

ing foreign code in the browser but these are compro-

mises that we should be willing to accept since the

beneﬁt outweighs the cost. Another approach that has

been proposed by (Canou et al., 2012) is to perform

a compilation of code in its native environment and

port the target bytecode to a virtual machine running

in Javascript on the browser. The idea is simple, ef-

ﬁcient and effective if it is known in advance what is

required to be transported to the browser but in the

context of online exploratory learning environments

the expectation is that the code is given in real time by

the learners and the aim is for this code to be directly

executable in real time so that the user can manipulate

constructs in those environments. This requires a JiT

(Just in Time) transpilation of code from any language

to Javascript directly in the browser.

Finally, the most recent development in this area

is the deployment of fully ﬂedged virtual machines

in the browser that are able to execute absolutely un-

modiﬁed source code written in different languages

as if they are in their native environment (Wen et al.,

2020). This is a solution that entails the execution of

an OS via a virtual hypervisor running in the browser.

The prospect of having the ability to operate like that

in a browser exceeds even the most ambitious expec-

tations and this is something deﬁnitely worth invest-

CSEDU 2023 - 15th International Conference on Computer Supported Education

306

ing in future research projects. Nevertheless, the obvi-

ous obstacles to using this approach currently is that it

is not mature enough to provide well deﬁned interfac-

ing options so that the functionality of the code being

run in the VM can be externalised and used directly to

manipulate objects in the browser and also the cost of

running a heavyweight component like the VM itself

may pose considerable resource and performance de-

ﬁciencies in such a limited platform like the browser.

The work in this paper is inspired by (Ford, 2004;

Matsumura and Kuramitsu, 2016). The aim is to

have the ability to manipulate any object that exposes

an API in the context of a browser with instructions

given in any language. The idea is simple. Instead of

just giving the code intended to perform some action,

we provide both the code and the language speciﬁca-

tion that the code adheres to. The language speciﬁca-

tion is used to generate a parser able to understand the

code and another process generates its equivalent in

Javascript. The Javascript code is then executed in the

usual way and all that happens in an automated fash-

ion. Parsers can either be generated on the ﬂy, or gen-

erated only once and reused thereafter if performance

issues arise. This simple mechanism allows any num-

ber of diverse web widgets in the browser ecosystem

to operate in a truly polyglot environment with min-

imal dependencies and performance overheads since

everything takes place locally.

3 DESIGN CONSIDERATIONS -

PARSERS

The main objective in this part is to identify the opti-

mal solution to generate parsers for input languages.

One option is to design an authoring environment to

enable efﬁcient development of custom parsers by

hand. Building a custom parser by hand is a big en-

deavour and there has to be a good reason to justify

the effort. Normally we consider this option only

when there are speciﬁc requirements that cannot be

satisﬁed by using a typical parser generator. This is

typically the case when the input language is very spe-

cialised or there are particular requirements in terms

of performance or integration that cannot be met. A

more ﬂexible approach that covers a wide range of

cases and promises shorter development time is to

use a parser generator. Parser generators may offer

a cost effective alternative to building custom parsers

but they are not trivial to use themselves. They come

with constraints and limitations in terms of what in-

put grammars they support and what types of target

languages they are suitable for. Not all parser genera-

tors are compatible with all types of grammars. This

consideration is needed because it shows the available

options along with potential constraints and limita-

tions with existing tools and technologies. The ﬁrst

and foremost constraint in our case is the fact that we

expect the parser generator to be able to operate in

the browser. Therefore the expectation is to ﬁnd a

tool that is itself developed in JavaScript. This crite-

rion narrows down signiﬁcantly the available range of

options.

For that part a domain analysis is done to see what

the available tools and technologies are in the market

and what the technical speciﬁcations for those tools

are.At the time that this part of the research was done

the major players were Jison, PEG.js, ANTLR and

Chevrotrain. The main two rivals in terms of popular-

ity (npm trends) have always been PEG.js and Jison.

These are the oldest tools in the market. PEG.js has

always been by far the most popular tool in the mar-

ket. This trend has only recently changed in favour

of chevrotain that superseded PEG.js in 2022. Popu-

larity (No of downloads per unit of time) as well as

support and maintenance (frequency of updates) are

important criteria in our decision because they relate

to the size of the target user segment we aim for. An-

other consideration is performance benchmarks that

show how performant the tools are when parsing text

in JSON notation (typical test). Unfortunately, these

reports proved not to be very helpful because they

show ambiguous and sometimes contradicting results

favouring one or the other tool. A possible explana-

tion for that might be the fact that the results are heav-

ily inﬂuenced by the range of use cases considered.

Jison was written in 2009 as an assisting tech-

nology for a compilers course. It creates bottom-

up parsers that recognize context-free languages ex-

pressed in LALR(1), LR(0), SLR(1) grammars. Ji-

son is an JavaScript implementation of Bison. Bi-

son is a parser generator written in the 1990s to con-

vert context-free grammars into deterministic parsers.

PEG.js was written in 2010 to generate top-down

parsers in JavaScript. The format and syntax of the

grammar used is similar to the one used in Jison.

PEG.js recognises a form of grammars that is alter-

native to context-free grammars and uses the packrat

parsing technique to support any language deﬁned by

an LL(k) or LR(k) grammars (Bouilliez, 2014).

4 THE PARSER GENERATOR

The tool we chose to work with in the ﬁrst proto-

type is PEG.js. The tight integration of the tool with

JavaScript, the concise syntax of the supported input

language for the grammar, the quality and clarity of

Online Polyglot Programming Education with LFT (Lingua Franca Transformer)

307

the documentation available as well as its huge pop-

ularity in the market contributed to the decision. The

tool follows the Parsing Expression Grammar (PEG)

formalism. PEG (Ford, 2004) formalises a language

in terms of an analytic grammar and that means that

syntax rules correspond more directly to the struc-

ture and the semantics of the parser generated for that

language. PEG is designed speciﬁcally to accommo-

date the needs of programming language and com-

piler writing and is considered more powerful than

traditional LL and LR formalisms. The PEG.js im-

plementation accepts syntax rules in PEG and allows

inline statements expressed in JavaScript. That means

that syntax rules in JavaScript can be embedded in

the grammar document in order to direct the gener-

ated parser to reshape the resulting AST and trans-

form it to whatever output language we desire. Tools

that lack this functionality have to resort to separate

components to process the resulting trees and make

them conformant to the desired speciﬁcation. There

is no separate lexer component for the identiﬁcation

of tokens as this functionality is integrated with the

tool.

The following is a very simple example of a lan-

guage speciﬁcation given in PEG:

text = words:(w:word space? {return w;})*

{return words;}

word = letter+

letter = [a-zA-Z0-9]

space = " "

Parsing starts with the rule given ﬁrst. The ini-

tial rule is called text and references two other rules

named word and space respectively. These rules need

to be deﬁned as well. The rule word is deﬁned as one

or more letters. Letter is deﬁned as any alphabetical

or numerical character (English alphabet). Space is

deﬁned as the whitespace character. Going upwards,

text is deﬁned as any sequence of word tokens option-

ally followed by a space. The JavaScript snippets give

instructions to the parser to return only the matched

word tokens, not the spaces.

5 THE ARCHITECTURE

LFT is primarily intended to enable dynamic trans-

formations of new and existing languages into

JavaScript. This is based on the premise that a poly-

glot environment in the browser can add educational

value to existing learning materials. Learning ma-

terials in that context take the form of web com-

ponents (widgets) that encapsulate some functional-

ity exposed via a GUI and/or an API. Learning de-

signers or learning application developers communi-

cate with these widgets programmatically to initialise

them with content, to monitor learner activity and

progress, to assess learner achievements and so on.

Learners on the other hand sometimes communicate

with them programmatically via the GUI to create and

manipulate content and learn new concepts in the pro-

cess. In both cases we have a widget that requires

instructions expressed in JavaScript to operate.

If the activity logic needs to be expressed in an

alternative language, we need a mechanism to trans-

form this code dynamically into JavaScript before we

send it off to the widget.

Figure 1: LFT Architecture.

LFT accepts the formal speciﬁcation of the in-

put language as well as the syntax rules for the out-

put language in the same text and generates a parser

for that language. The parser is then used to process

the source code in the target language and produce an

equivalent representation in the intended form. This

form in most of the cases is expected to be an Ab-

stract Syntax Tree (AST) that conforms to the ESTree

speciﬁcation, formerly known as SpiderMonkey AST.

This is not mandatory but rather a convention used for

convenience if the target language is JavaScript. AST

is a language neutral, generic tree-like representation

of the syntactic structure and the language constructs

found in the source code. It is abstract in the sense

that it does not depict every little detail found in the

syntax or the semantics of the code but only the struc-

ture. The ESTree speciﬁcation is assumed because it

is a standard format for JavaScript. In LFT the ESTree

AST serves as the common language denominator be-

cause its speciﬁcation is much simpler than that of

JavaScript itself and it allows automated conversion

into JavaScript via compatible code generators. The

ﬁnal step is to dynamically evaluate the JavaScript

code and execute the instruction in the component.

6 THE TOOL

The tool is designed to facilitate the authoring pro-

cess of syntax rules for new and existing languages

in PEG. The assumed target language is the ESTree

CSEDU 2023 - 15th International Conference on Computer Supported Education

308

speciﬁcation. The interface is split in panels organ-

ised as tabs. The ﬁrst tab shows the editor that can

be used to author the syntax rules for the input lan-

guage - On the right there is another editor that can

be used to test these rules with some text expressed in

the language being speciﬁed.

Figure 2: LFT Editor.

If the rules are well formed and the input is valid

the resulting AST is displayed in another frame. This

part of the interface can be used for the speciﬁcation

of any output language and ESTree output is not as-

sumed. If the target language is ESTree then a more

careful inspection of the output is needed. For that

there is an additional tab that allows the author to per-

form a comparative analysis of the output between the

statements given in the new language and JavaScript.

Figure 3: Comparison Tab.

The comparisons tab gives two editors, one for

each language. The author is supposed to provide

equivalent statements in both languages to express the

same operation and examine carefully the generated

ASTs.

If the ASTs don’t match up then there is a mis-

take in the PEG syntax. An automatic comparison is

performed and differences are highlighted in a third

frame. The next tab is called Testbed and is designed

to give an idea of how the newly deﬁned language

could be used to manipulate a turtle in a Microworld.

Figure 4: LFT Testbed.

7 IMPLEMENTATION DETAILS

In the context of LFT the parser is a JavaScript ob-

ject that gets generated dynamically by a third party

component found in the PEG.js

library. This com-

ponent is a parser generator that conforms to the PEG

formalism as presented earlier. Once the parser is cre-

ated it can be used to parse code expressed in the input

language and generate code expressed in the output

language dynamically. LFT was designed to allow

transformations between any two languages but its

primary goal is to allow the creation of transpilers to

JavaScript. As stated previously the purpose for this is

to enable the use of different languages in the context

of web browsers. Therefore, the expected target lan-

guage is typically an Abstract Syntax Tree (AST) that

conforms to the ESTree3 speciﬁcation. This speciﬁ-

cation is the most common and standard format for

JavaScript AST. Once the parser is created the next

step is to enter a sample text in the input language

and let the parser generate the respective AST for

inspection. The AST is formatted appropriately and

placed in a graphical control to enable visual inspec-

tion. A third-party library called JSON Viewer4

used for the formatting. Further tests are done in the

‘Comparisons’ tab and that entails the automatic com-

parison and visual inspection of ASTs that are sup-

posed to be identical. The test at that stage is to give

two equivalent statements, one in the input language

and the other in JavaScript and check if the resulting

ASTs are exactly the same. Parsing the JavaScript

code is done by a tool named Esprima5

. Automatic

https://pegjs.org/

https://github.com/abodelot/jquery.json-viewer

https://esprima.org/

Online Polyglot Programming Education with LFT (Lingua Franca Transformer)

309

comparison is performed by a third party component

called objectDiff6

. This checks both ASTs, detects

discrepancies in the structures and displays visual in-

dicators of the differences. This allows for a much

more succinct testing of the parser conformity with

the ESTree speciﬁcation

. The ﬁnal and ultimate test

is to evaluate the parser in the challenging context of

a microworld. This entails writing code in the input

language to control and manipulate a turtle in a turtle-

world. This environment is an own component built

speciﬁcally for this project. The environment was de-

veloped in HTML5, JavaScript and Raphael7

. The

API exposed by this microworld expects to be used in

JavaScript.

Therefore, the ESTree AST generated by the

parser must be transformed to Javascript before it gets

executed. For this a third-party component named

Escodegen8

is used. The visualisation that shows

the interactive AST for the code given in the testbed

is done with the third-party library named D3

. Fi-

nally, all the text editors used in this project are imple-

mented using the third-party library called Ace10

8 EVALUATION

METHODOLOGY

The evaluation component was a two-fold process.

The ﬁrst part involved three software engineers that

were presented the tool and after a short familiarisa-

tion session they were given the task to develop gram-

mars for simple mathematical expressions. There was

also a second round of more challenging projects that

took place involving the development of a signiﬁcant

portion of Java 7, scheme, lisp and logo. During the

activities the participants were asked to reﬂect on the

process and the usability of the tool using free text.

A general qualitative outcome of this feedback is that

the tool at that level is relatively easy to use, it speeds

up the process, and it is effective in producing ade-

quate results.

The second part of the evaluation was a work-

shop involving two other groups of stakeholders, ICT

teachers and learning designers. A non-random sam-

pling method was used for the selection of the par-

ticipants as there was a speciﬁc criterion needed to

be met. The participants had to be knowledgable in

https://github.com/NV/objectDiff.js

https://github.com/estree/estree

http://raphaeljs.com/

https://github.com/estools/escodegen

https://d3js.org/

https://ace.c9.io/

learning technologies, familiar with this area of ex-

pertise, and relatively skilled in IT. The participants

selected were three learning designers and two ICT

teachers. The workshop was delivered in three parts.

Initially the participants were given a general presen-

tation of the tool. Then, they were then given a short

presentation of the outputs generated by the develop-

ers in the ﬁrst part of the evaluation. Having a ﬁrst-

hand experience of tangible outputs from that part the

participants were ﬁnally asked to ideate on potential

use cases of the tool. This was a focus group dis-

cussion facilitated by a moderator. This discussion

generated very interesting outcomes and prospects of

future work presented in the following section.

9 SUGGESTED USE CASES

The feedback received by the software engineers that

did the usability testing as well as the workshop in the

previous section gave us ideas and suggestions for po-

tential use cases. The main type of users/stakeholders

identiﬁed were software developers, learning design-

ers, ICT Teachers, programming teachers and com-

pilers teachers. Starting from the latter, the most con-

spicuous use of the tool would be as an assistive tech-

nology in University courses on compilers. It would

also beneﬁt programming education by enhancing

web-based IDEs (Integrated Development Environ-

ments) with the ability to offer multi-language op-

tions. Additionally programming teachers could ben-

eﬁt by designing specialised languages for smoothen-

ing the learning curve on algorithmic thinking. These

could be more high-level languages given as an inter-

mediate step to make learning easier for beginners and

less skilled developers. Another idea is to promote

self-regulated learning to students learning a new lan-

guage. Students knowledgable in one language could

verify the correctness of their code by writing the

same code in the language they know well and com-

pare the transpilation outpouts to the new language.

In this case the technology could be used as a meta-

cognitive tool.

A different area of interest is web-based learn-

ing environments. In this category we have envi-

ronments that natively support a language possibly

exposed through a GUI component (Malt+) and en-

vironments that are not designed to teach program-

ming but offer an API in JavaScript such as Geoge-

bra (Carvalho et al., 2021). Geogebra is an appli-

cation designed to teach geometry, algebra, statistics

and calculus through a dynamic and interactive user

interface. If an environment encapsulates concepts

that may be difﬁcult to express with the language na-

CSEDU 2023 - 15th International Conference on Computer Supported Education

310

tively supported, then it becomes apparent that the

option to use a more expressive language would en-

hance the usefulness and thus the educational value

of it. That combined with the fact that there would

be no cognitive overhead for existing learners makes

the idea even more appealing. Equally appealing is

the idea to reuse learning environments like Geoge-

bra in different ways and offer even programming

education through them. That would increase sig-

niﬁcantly the usefulness and value of those environ-

ments as it would offer the opportunity to educators

to take advantage of the strengths of different lan-

guages to convey different concepts using well tested

and familiar to students interfaces. Respectively, it

would also increase reusability of those environments

allowing access to different communities of people

and thus increasing the educational value of exist-

ing investments. Combining the strengths of differ-

ent languages with different conceptual abstractions

like objects, emotions, metaphors, and abstract pro-

cesses supported by different environments is like us-

ing the best of both worlds to synthesise and convey

compelling learning scenarios to prospective learners.

10 CONCLUSIONS AND FUTURE

WORK

This paper presents an authoring environment de-

signed to assist learning designers and developers to

deﬁne grammars for new and existing languages for

the web. This work took place in the context of the

EU funded project ExtenDT2

and the development

took place on the AWS (Amazon Web Services) plat-

form. The beneﬁt of using this tool is to optimise

the process of deﬁning input languages and make the

output easily transformed into JavaScript. The in-

tention of this work is to allow communication with

web functionality in any language and thus take ad-

vantage of language-speciﬁc features combined with

existing functionality to enhance learning and opera-

tional beneﬁts. Preliminary usability testing gave us

positive feedback. Furthermore, focus group discus-

sions gave us directions on potential future uses. We

envisage in future iterations to develop the tool further

and combine it with many different learning or other

JavaScript components in order to exploit its full po-

tential and beneﬁt. We also intend to carry out more

elaborate evaluation cycles to assist with design im-

provements and the ergonomics of the interface.

https://extendt2.eu/

REFERENCES

Azad, A. and Smith, D. T. (2014). Teaching an introductory

programming language in a general education course.

Journal of Information Technology Education. Inno-

vations in Practice, 13:57.

Balat, V., Vouillon, J., and Yakobowski, B. (2009). Experi-

ence report: Ocsigen, a web programming framework.

In Proceedings of the 14th ACM SIGPLAN interna-

tional conference on Functional programming, pages

311–316.

Becker, B. A. and Quille, K. (2019). 50 years of cs1 at

sigcse: A review of the evolution of introductory pro-

gramming education research. In Proceedings of the

50th acm technical symposium on computer science

education, pages 338–344.

Becker, B. W. (2001). Teaching cs1 with karel the robot

in java. In Proceedings of the thirty-second SIGCSE

technical symposium on Computer Science Education,

pages 50–54.

Bergin, J., Roberts, J., Pattis, R., and Stehlik, M. (1996).

Karel++ A gentle introduction to the art of object-

oriented programming. John Wiley & Sons, Inc.

Bergin, J., Stehlik, M., Roberts, J., and Pattis, R. (2005).

A gentle introduction to the art of object-oriented pro-

gramming in java. cafepress. com. Google Scholar

Google Scholar Digital Library Digital Library.

Bouilliez, P. (2014). Glass cat–a tool for interactive visual-

ization of the execution of oz programs in the pythia

platform. Universit

e Catholique de Louvain.

Canou, B., Chailloux, E., Vouillon, J., et al. (2012).

How to run your favorite language in web browsers.

WWW2012 dev track proceedings.

Carvalho, C. V. D. A., De Medeiros, L. G. F., De Medeiros,

A. P. M., and Santos, R. M. (2021). Papert’s mi-

croworld and geogebra: A proposal for enhancing

functional teaching. Modern Perspectives in Lan-

guage, Literature and Education Vol. 5, pages 1–12.

Cooper, S., Dann, W., and Pausch, R. (2000). Alice: a 3-d

tool for introductory programming concepts. Journal

of computing sciences in colleges, 15(5):107–116.

Duke, R., Salzman, E., Burmeister, J., Poon, J., and Mur-

ray, L. (2000). Teaching programming to beginners-

choosing the language is just the ﬁrst step. In Pro-

ceedings of the Australasian conference on Comput-

ing education, pages 79–86.

Ezenwoye, O. (2018). What language?-the choice of an

introductory programming language. In 2018 IEEE

Frontiers in Education Conference (FIE), pages 1–8.

IEEE.

Ford, B. (2004). Parsing expression grammars: a

recognition-based syntactic foundation. In Proceed-

ings of the 31st ACM SIGPLAN-SIGACT symposium

on Principles of programming languages, pages 111–

122.

Goosen, L. (2008). A brief history of choosing ﬁrst pro-

gramming languages. In IFIP International Confer-

ence on the History of Computing, pages 167–170.

Springer.

Online Polyglot Programming Education with LFT (Lingua Franca Transformer)

311

Hannaﬁn, M., Land, S., and Oliver, K. (1999). Open learn-

ing environments: Foundations, methods, and mod-

els. Instructional-design theories and models: A new

paradigm of instructional theory, 2:115–140.

Henriksen, P. and K

olling, M. (2004). Greenfoot: com-

bining object visualisation with interaction. In Com-

panion to the 19th annual ACM SIGPLAN conference

on Object-oriented programming systems, languages,

and applications, pages 73–82.

Irimia, A. (2001). Enhancing the introductory computer sci-

ence curriculum: C++ or java? Journal of Computing

Sciences in Colleges, 17(2):159–166.

Kahn, K. (1996). Toontalktm—an animated programming

environment for children. Journal of Visual Lan-

guages & Computing, 7(2):197–217.

olling, M. and Henriksen, P. (2005). Game programming

in introductory courses with direct state manipulation.

In Proceedings of the 10th annual SIGCSE conference

on Innovation and technology in computer science ed-

ucation, pages 59–63.

Kynigos, C. and Latsi, M. (2007). Turtle’s navigation and

manipulation of geometrical ﬁgures constructed by

variable processes in a 3d simulated space. Informat-

ics Educ., 6(2):359–372.

Laakso, M.-J., Kaila, E., Rajala, T., and Salakoski, T.

(2008). Deﬁne and visualize your ﬁrst programming

language. In 2008 Eighth IEEE International Confer-

ence on Advanced Learning Technologies, pages 324–

326. IEEE.

Lewis, M. C., Blank, D., Bruce, K., and Osera, P.-M.

(2016). Uncommon teaching languages. In Proceed-

ings of the 47th ACM Technical Symposium on Com-

puting Science Education, pages 492–493.

Lindoo, E. (2020). Results of using a multi-programming

language approach to decrease drop-fail rates in cs1.

Journal of Computing Sciences in Colleges, 36(2):31–

41.

Maloney, J. H., Peppler, K., Kafai, Y., Resnick, M., and

Rusk, N. (2008). Programming by choice: urban

youth learning programming with scratch. In Pro-

ceedings of the 39th SIGCSE technical symposium on

Computer science education, pages 367–371.

Mannila, L. and de Raadt, M. (2006). An objective compar-

ison of languages for teaching introductory program-

ming. In Proceedings of the 6th Baltic Sea conference

on Computing education research: Koli Calling 2006,

pages 32–37.

Matsumura, T. and Kuramitsu, K. (2016). A declarative

extension of parsing expression grammars for recog-

nizing most programming languages. Journal of In-

formation Processing, 24(2):256–264.

Minor, J. T. and Gewali, L. P. (2004). Pedagogical issues

in programming languages. In International Confer-

ence on Information Technology: Coding and Com-

puting, 2004. Proceedings. ITCC 2004., volume 1,

pages 562–565. IEEE.

Naveed, S., Sarim, M., and Nadeem, A. (2018). C in

cs1: Snags and viable solution. Mehran Univer-

sity Research Journal of Engineering & Technology,

37(1):1–14.

Papert, S. (1980). Mindstonns vol. 607. New York: Basic

Rooks.

Parker, K. R., Chao, J. T., Ottaway, T. A., and Chang, J.

(2006). A formal language selection process for intro-

ductory programming courses. Journal of Information

Technology Education: Research, 5(1):133–151.

PATTIS, R. (1981). Karel the robot john wiley & sons. New

York.

Serrano, M., Gallesio, E., and Loitsch, F. (2006). Hop: a

language for programming the web 2. 0. In OOPSLA

companion, pages 975–985.

Smith, C. and Rickman, J. (1976). Selecting languages for

pedagogical tools in the computer science curriculum.

ACM SIGCSE Bulletin, 8(3):39–47.

Sobral, S. R. (2019). Cs1: C, java or python? tips for a

conscious choice.

Sobral, S. R. (2020). The ﬁrst programming language and

freshman year in computer science: characterization

and tips for better decision making. In World Confer-

ence on Information Systems and Technologies, pages

162–174. Springer.

Sobral, S. R. (2021). The old question: which programming

language should we choose to teach to program? In

International Conference on Advances in Digital Sci-

ence, pages 351–364. Springer.

Solomon, C. J. and Papert, S. (1976). A case study of a

young child doing turtle graphics in logo. In Proceed-

ings of the June 7-10, 1976, national computer con-

ference and exposition, pages 1049–1056.

Tharp, A. L. (1982). Selecting the “right” programming

language. ACM SIGCSE Bulletin, 14(1):151–155.

Van Haaster, K. and Hagan, D. (2004). Teaching and learn-

ing with bluej: an evaluation of a pedagogical tool. Is-

sues in Informing Science & Information Technology,

Wainer, J. and Xavier, E. C. (2018). A controlled experi-

ment on python vs c for an introductory programming

course: Students’ outcomes. ACM Transactions on

Computing Education (TOCE), 18(3):1–16.

Wen, E., Warren, J., and Weber, G. (2020). Browservm:

Running unmodiﬁed operating systems and applica-

tions in browsers. In 2020 IEEE International Confer-

ence on Web Services (ICWS), pages 473–480. IEEE.

Wexelblat, R. L. (1979). First programming language: Con-

sequences (panel discussion). In ACM Annual Confer-

ence, page 259.

Zschaler, S., Demuth, B., and Schmitz, L. (2014). Sales-

point: A java framework for teaching object-oriented

software development. Science of Computer Pro-

gramming, 79:189–203.

CSEDU 2023 - 15th International Conference on Computer Supported Education

312