Osiris: A Multi-Language Transpiler for Educational Purposes

Marrão, Breno; Leal, José Paulo; Queirós, Ricardo

doi:10.4230/OASIcs.ICPEC.2025.17

Osiris: A Multi-Language Transpiler for Educational Purposes

Breno Marrão

DCC – FCUP, Porto, Portugal José Paulo Leal

CRACS – INESC TEC, Porto, Portugal
DCC – FCUP, Porto, Portugal Ricardo Queirós

ESMAD – Polytechnic of Porto, Portugal
CRACS – INESC TEC, Porto, Portugal

Abstract

While server-side assessment of programming exercises, with its ease of installing diverse compilers and execution environments, is common, it presents three key limitations: the necessity of a constant Internet connection, increased bandwidth consumption, and centralized execution load. The alternative is to rely on JavaScript, the single programming language supported by all standard web browsers. This paper introduces Osiris, a pure JavaScript multi-language transpiler designed to enable the execution of diverse programming languages within web browsers. Targeted primarily at Virtual Learning Environments (VLE) for language programming education, Osiris employs a parser generator to translate small student programs into JavaScript based on language-specific grammars with semantic rules. It also includes a comprehensive, though not exhaustive, JavaScript library that emulates the standard libraries of its supported languages. Validation of Osiris indicates the pedagogical effectiveness of browser-based transpilation for introductory programming education.

Keywords and phrases:

Transpiler, Programming Education, JavaScript, Python, Virtual Learning Environments, Client-Side Execution

Copyright and License:

2012 ACM Subject Classification:

Applied computing

\rightarrow

Interactive learning environments

Funding:

This research was co-funded by the European Union, grant number 2023-1-PL01-KA220-HED-000164696.

DOI:

10.4230/OASIcs.ICPEC.2025.17

Event:

6th International Computer Programming Education Conference (ICPEC 2025)

Editors:

Ricardo Queirós, Mário Pinto, Filipe Portela, and Alberto Simões

Series and Publisher:

Open Access Series in Informatics, Schloss Dagstuhl – Leibniz-Zentrum für Informatik

1 Introduction

Virtual learning environments have become increasingly prevalent in programming education, offering considerable benefits in terms of accessibility and flexibility, especially for those new to the field. However, their dependence on server-side code execution introduces inherent limitations. Typically, code is sent to a server for processing, and the results are then returned to the user. This model presents challenges, including the necessity of a continuous internet connection, increased server load, and substantial bandwidth usage, particularly in extensive or remote learning scenarios.

To address this issue, a potential solution involves transferring code execution to the client side. This approach is feasible for JavaScript, which can be readily executed within a web browser. While JavaScript is important, many other programming languages embody paradigms crucial for students but cannot be executed in this environment. To overcome this limitation, Osiris, a transpiler that converts various programming languages into JavaScript for client-side execution, was developed. This process leverages a parser generator, which, informed by the formal grammar of each source language and a set of defined semantic rules, automatically produces the equivalent JavaScript code. Python was selected as the first language implemented in Osiris, as it is currently the most in-demand programming language for beginners, with 66% of learners favoring it, according to the 2024 Stack Overflow Developer Survey [9].

Osiris was submitted to a two-fold validation: an offline validation with a large dataset of student Python programs taken from a programming competition; and an online validation with a browser-based Virtual Learning Environment (VLE), involving students who completed basic programming exercises in JavaScript and Python. In online validation, results showed that Osiris can correctly handle the vast majority of student-written programs while spotting a few points requiring improvement. In offline validation, the comparable results achieved by students in both languages demonstrate that the two languages yield indistinguishable outcomes for pedagogical assessment at the introductory level.

The subsequent sections of this paper are organized as follows: Section 2 provides the background and motivation for this work, Section 3 details the design and implementation of Osiris, Section 4 presents the evaluation of the approach, and finally, Section 5 concludes with a discussion of the findings and potential avenues for future work.

2 Background

Traditional server-side code execution in VLEs has been widely adopted due to its flexibility in supporting multiple programming languages through centralized compiler and interpreter installations (e.g., Codio [2], CodeGrade [1], Vocareum [3]).

Client-side execution emerged as a promising alternative by eliminating network dependencies and running code directly in students’ browsers. Early implementations focused on JavaScript, the only language natively supported across all major browsers [11]. While effective for teaching JavaScript, this excluded other pedagogically important languages such as Python, now the most popular introductory language with a 66% adoption rate according to Stack Overflow’s 2024 Developer Survey [9].

Transpilation (source-to-source compilation) offers a viable solution by converting code from other languages into browser-executable JavaScript. Existing transpilers such as PyJS (Python to JavaScript) and Babel (ES6+ to ES5) demonstrate the technical feasibility of this approach [13, 8]. However, educational environments have specific needs that general-purpose tools often overlook. For instance, many beginner exercises rely on terminal-style interactions – such as print and input – which are not natively supported by browsers. Additionally, introductory courses typically use only a small subset of the standard library, making partial but pedagogically sufficient implementations feasible.

At the core of any transpiler lies its parser generator. To determine the most suitable option for the Osiris transpiler, a review was carried out focusing on the most widely adopted parser generators compatible with JavaScript. Each candidate was analyzed and tested against our specific requirements to identify the best fit for our goals. The following parser generators were evaluated:

ANTLR4: employs the ALL(*) parsing strategy (Adaptive LL(*)), which represents a significant advancement in parsing technology. This strategy combines the predictive parsing capabilities of traditional LL(k) parsers with the power and flexibility of GLR-like algorithms. ANTLR4 generates both lexer and parser from grammar specifications written in its own format, which closely resembles EBNF notation. The framework supports semantic actions through visitor and listener patterns, enabling clean separation between grammar definition and semantic processing. Additionally, ANTLR4 provides robust error recovery mechanisms and generates human-readable error messages [14].
Chevrotain: uses a JavaScript DSL approach for grammar definition, requiring developers to define parsing rules through JavaScript constructors and method calls. While offering tight JavaScript integration and automatic Concrete Syntax Tree generation with visitor pattern support, it has a significant learning curve due to its API-specific programming patterns [12].
Jison: follows a Bison-like grammar format using BNF-style notation, making it familiar to developers with traditional parser generator experience. It supports LALR(1) grammars with additional modes for LR(0), SLR(1), and LR(1), but can be restrictive with complex or ambiguous constructs. Semantic actions are embedded directly within production rules [4].
PEG.js: utilizes Parsing Expression Grammars with ordered choice operators in EBNF-like syntax. It offers flexible semantic action implementation through inline grammar rules or post-processing functions, generating self-contained JavaScript parsers suitable for browser environments [15].
Nearley: implements the Earley parsing algorithm with Leo’s optimizations for right-recursion, achieving linear-time performance for LL(k) grammars. It supports ambiguous grammars by returning all possible parse trees but uses a custom grammar format with JavaScript-like syntax, requiring post-processing functions for semantic actions [5].

The selection criteria were based on the following key requirements:

Browser compatibility:: The parser had to work seamlessly in a browser-based environment without relying on server-side components.
Support for full programming language grammars:: It needed to handle the complexity of real-world languages such as Python.
Robust error reporting:: Clear and informative error messages were essential for supporting learning and debugging in educational settings.
Accessible grammar format:: The grammar specification should have widespread community adoption, with readily available grammars online to support rapid development and future extensibility.

Table 1: Comparison of Parser Generators.

Feature	ANTLR4	Chevrotain	Jison	Nearley	PEG.js
Grammar Formalism	ALL(*)	LL(k)	LALR(1)	Earley	PEG
Grammar Format	ANTLR syntax	JS DSL	Bison-like	(custom)	PEG syntax
Browser Support	Yes¹¹1via JS target	Yes	Yes	Yes	Yes
GitHub Stars	$\sim$ 18k	$\sim$ 2.6k	$\sim$ 4.4k	$\sim$ 3.7k	$\sim$ 4.9k
Semantic	Visitor/Listener	Embedded	Embedded	Postprocessing	Inline or post-
Actions	classes	in JS	JS actions	JS functions	-processing functions

Based on our selection criteria, a comprehensive evaluation of each parser generator was conducted to identify the optimal choice for the Osiris transpiler framework. The evaluation revealed significant limitations in several alternatives that ultimately led to the selection of ANTLR4.

Among the evaluated options, Chevrotain demonstrated the most significant limitations. With approximately 2.6k GitHub stars, it exhibited the lowest community adoption, indicating limited community support and fewer available resources for troubleshooting. More critically, the framework’s JavaScript DSL approach creates a substantial barrier to scalability, as the scarcity of pre-existing grammars in this format would necessitate implementing each language grammar from scratch, severely limiting scalability across different programming languages.

Similarly, Jison faces significant limitations despite offering moderate community support with approximately 4.4k GitHub stars. The primary concern lies in the availability of language-specific grammars, which remains problematic for our multi-language requirements. Even for widely-used languages like Python, comprehensive grammar implementations in Jison’s format are scarce, and this scarcity extends to other educational languages, creating substantial barriers to supporting diverse programming languages within the Osiris framework.

Both Nearley and PEG.js present more sophisticated parsing approaches but still fall short of our requirements. Nearley implements the Earley parsing algorithm, which offers theoretical advantages in handling ambiguous grammars and provides O(n³) worst-case complexity with O(n) performance for most practical grammars [6]. However, with approximately 3.7k GitHub stars, Nearley’s community support remains limited, and the custom grammar format makes it difficult to find or adapt existing language grammars. PEG.js utilizes Parsing Expression Grammars (PEG), which offer several advantages including unambiguous parsing and the ability to handle complex language constructs through ordered choice [7]. While the framework’s grammar format aligns well with languages like Python, and there is an official Python PEG grammar available²²2https://docs.python.org/3/reference/grammar.html, the scalability to other educational languages remains questionable, as PEG grammars for other languages are less commonly available. Despite PEG.js demonstrating reasonable community adoption with approximately 4.9k GitHub stars and offering flexibility through semantic actions that can be implemented either inline or through post-processing functions, it still lacks the comprehensive grammar ecosystem needed for our multi-language educational platform.

In contrast, ANTLR4 emerged as the clear choice for the Osiris framework due to its powerful parsing strategy, active community, and flexible architecture. Its ALL(*) parser combines the simplicity of LL(k) with GLR-like power, offering linear performance in practice despite theoretical complexity of O (n4) [10]. ANTLR4 outperforms general strategies like GLL and GLR, making it suitable for real-world grammars. The strong community support, evidenced by approximately 18k GitHub stars, ensures reliable documentation, regular updates, and broad support. Its visitor pattern allows stateful and customizable AST traversal, enabling detailed semantic analysis and complex transformations that are key for educational transpilation. Most importantly, the actively maintained grammars-v4 repository³³3https://github.com/antlr/grammars-v4 offers high-quality grammars for many languages, accelerating development and supporting the scalability required for a comprehensive educational transpilation framework.

3 Design and Implementation

Osiris empowers VLEs by enabling the execution of code in multiple programming languages locally, removing the reliance on a continuous remote server connection. This capability was achieved through the following design goals.

$\blacksquare$

Osiris is a JavaScript package providing a service to the client-side of VLEs, without requiring the use of any particular user interface or framework.
$\blacksquare$

It translates code from various programming languages into JavaScript for execution in JavaScript engine environments, such as web browsers.
$\blacksquare$

Osiris is designed to translate and execute small programs, particularly those intended for introductory programming exercises.
$\blacksquare$

It aims for comprehensive coverage of the syntax of each supported language.
$\blacksquare$

It provides minimal coverage of each supported language’s API, focusing on the essentials required for introductory exercises, such as I/O and basic math functions.

To accomplish this translation, Osiris employs a parser generator. Using a grammar for each supported language, it defines semantic rules that map each construct to its JavaScript equivalent. For basic program functionality, Osiris also includes a library containing a minimal subset of each language’s core API.

The first subsection outlines Osiris’s architecture, emphasizing its integration within a virtual learning environment and its use of a parser generator. Subsequent subsections detail the implementation of Osiri’s core features, which are common to all languages, and the implementation of support for a particular language – Python.

3.1 Architecture Overview

Osiris⁴⁴4Available as an npm package at https://www.npmjs.com/package/osiris-educational-transpiler follows a modular, language-specific architecture. Each supported language is encapsulated in its own module, allowing clear separation of concerns and easier maintenance. This design also facilitates the addition of new language support while ensuring consistent JavaScript output.

Osiris provides two main execution modes:

Transpilation with VLE-side execution: As illustrated in Figure 1, the VLE initializes Osiris and interacts with it by sending source code. Osiris loads the necessary helper functions and uses ANTLR to parse the code. The Visitor then traverses the parse tree and generates equivalent JavaScript code. This JavaScript can be executed directly by the VLE using its preferred method, such as eval(). An example of VLE-side execution:

⬇

import Osiris from "osiris-educational-transpiler/python";

const transpiler = new Osiris();

const result = transpiler.sendCode(’print("Hello, World!")’);

if (result.success) {

console.log(’Transpiled Code:’, result.code);

eval(result.code);

} else {

console.error(’Transpilation Error:’, result.error);

}
Execution via Web Worker: As shown in Figure 2, Osiris also provides a runCode() function that executes the transpiled JavaScript in a sandboxed Web Worker. In this setup, the VLE initializes Osiris and sends the source code for transpilation. If successful, the VLE then calls runCode(), which supports communication through a terminal-like interface. The runCode() function receives a display callback to show outputs, while user input is handled via the sendIO() function.

Refer to caption — Figure 1: Execution with transpilation and evaluation by the VLE.

3.2 Osiris

When Osiris receives the program’s code it invokes ANTLR to parse it with to the selected language’s grammar. If parsing succeeds, the AST is passed to a custom ANTLR visitor that transforms the tree into equivalent JavaScript code. Otherwise, syntax errors are reported.

The AST is traversed using a custom implementation of the Visitor pattern. This pattern allows a clean separation between the structure of the tree and the logic applied to each node. Each grammar rule is handled by a corresponding method, and the logic is split across modular files for maintainability. Internal state is maintained to track scopes, control structures, and the current execution context, which is critical for correctly handling nested constructs and function definitions.

Osiris employs a custom error listener that extends ANTLR’s default behavior to capture syntax errors and report them in a structured format, including line number, column, and a clear message. This detailed feedback is especially useful in educational settings, helping users identify the precise location and nature of syntax issues.

Osiris provides two main methods for interacting with VLEs. The sendCode method receives source code and returns either transpiled JavaScript or an error message if the process fails. Once transpiled, the code can be executed in two ways:

The VLE evaluates the code using its preferred method (e.g., eval); or uses the runCode method, which executes the code inside a Web Worker. The runCode method executes the transpiled code in a Web Worker to ensure sandboxed execution. This setup also supports I/O interactions with students through a terminal-like interface. Web Workers run scripts in background threads, isolated from the main execution context, enhancing both security and stability.⁵⁵5https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers

3.3 Python support

This section describes the support for Python 3.12.6 in Osiris. The underlying grammar consists of 198 rules, and the translation process carefully tracks the current context – such as whether the code is inside a class, a function, or an if statement, along with the active variable and function names. To ensure accuracy, unit tests were implemented for each grammar rule.

A key challenge in the translation lies in the semantic differences between Python and JavaScript. For instance, Python and JavaScript evaluate boolean expressions differently: an empty list evaluates to False in Python but True in JavaScript. Equality comparisons also differ, as Python’s equal operator (==) checks for value equality with specific type coercion rules, whereas JavaScript’s corresponding operators (== and ===) behave differently. To handle this, Osiris uses custom evaluation functions.

Other complex cases include Python’s chained comparisons (e.g., x == 3 < 5), which are not natively supported in JavaScript, and Python’s flexible operators, such as multiplying an integer by a string (3 * "hello"), which require dedicated functions to replicate Python’s behavior. In particular, multiplication, subtraction, and addition operators needed special handling through custom functions.

Additionally, Python’s indexing and slicing (e.g., x[...]) posed challenges, since Python allows slices, negative indices, and other flexible behaviors that JavaScript arrays do not support natively. Osiris includes special handling to emulate these features correctly.

One of the main challenges in supporting Python was its extensive set of built-in features. Osiris addresses this by using a dedicated module for translating core Python functionalities that are relevant in educational contexts. This module covers basic types, commonly used functions, and error handling, with the goal of preserving behavior consistent with Python semantics. All transpilation and execution occurs client-side in the browser, eliminating the need for server-side interaction. These libraries are added to the global scope when Osiris is initialized.

While Osiris offers solid Python-to-JavaScript transpilation, some limitations exist:

$\blacksquare$

except blocks in try statements are not supported.
$\blacksquare$

Basic f-string formatting (e.g., f"{value:.2f}") is only partially supported.
$\blacksquare$

else blocks in while and for loops are not supported.
$\blacksquare$

Parameter typing in function definitions (e.g., *args: int, **kwargs: str) and handling of **kwargs are not implemented.
$\blacksquare$

Python’s support for infinite precision and complex numbers is not replicated due to JavaScript limitations.
$\blacksquare$

Python-specific constructs such as decorators, the with statement, and the del statement are not supported.

These limitations indicate areas for future improvement to achieve closer compatibility with Python’s full behavior.

4 Evaluation

Osiris evaluation was two-folded. Firstly, it was evaluated offline using a dataset of student submissions to introductory problems solved in Pyton. Secondly, it was evaluated online with students taking beginner programming classes in JavaScript an Python.

This dual approach was chosen because each setting performs a different kind of evaluation. The offline evaluation focuses on the effectiveness of Osiris’s Python-to-JavaScript transpilation, assessing how well it handles real-world student code. In contrast, the online evaluation with a VLE examines how seamlessly Osiris integrates into educational platforms and whether it impacts the student experience.

4.1 Offline evaluation

The dataset used for offline evaluation consists of 160 anonymized submissions from high school students, to solve in Python a collection of introductory programming problems. These submissions were taken from several recent editions of ToPAS⁶⁶6https://topas.dcc.fc.up.pt/, a high-school programming contest.

The evaluation process was automated: each Python program was transpiled into JavaScript using Osiris and executed in a controlled environment. One transpilation failed due to a for loop with an else clause, which Osiris does not currently support. After excluding these two cases, each program was executed with a set of test cases. The output produced was compared to the expected output to assess correctness. The evaluation results are shown in Table 2 and in the graphs in Figures 4 and 4.

Table 2: Offline evaluation results.

	Metric	Value	Percentage
Submissions	Total analyzed	159	100.00%
	Successfully transpiled	158	99.37%
	Excluded (infinite loop)	1	0.63%
	Fully correct	143	90.5%
	Not fully correct	15	9.5%
Test Cases	Total analyzed	1689	100.00%
Test Cases	Passed	1572	93.07%

Figure 3: Distribution of fully correct vs. not fully correct submissions.

Figure 4: Number of passed vs. failed test cases across all submissions.

One submission was excluded for causing an infinite loop, leaving 159 submissions. Each submission is paired with its corresponding test case inputs and expected outputs. Out of 159 Python submissions, 158 were successfully transpiled without errors.

The failing test results are due to several issues: two submissions use Python’s exit() function, which terminates the evaluation process since we use eval(), preventing further testing. Additionally, two submissions import and use Python’s datetime module, causing errors. There is also a known problem with how Osiris handles Python’s print function – although the output looks visually identical, subtle differences cause test comparisons to fail. There are also errors related to the partial support of basic f-string formatting (e.g., f"{value:.2f}"). Finally, some submissions produce incorrect results that require further investigation.

4.2 Online evaluation

To perform the offline evaluation, Osiris was integrated into Agni [11], a VLE with client-side execution. The Osiris package was installed into Agni from NPM. Agni was then modified to enable exercise solving in several languages, including JavaScript and those provided by Osiris (currently just Python). Figure 5 illustrates this integration.

The offline evaluation was conducted as follows. Two introductory programming classes were divided into two groups. Each group received six programming exercises – three in Python and three in JavaScript. The exercises differed between the groups in both languages to ensure a broader and more diverse evaluation. Additionally, students filled out an anonymous questionnaire, and the Agni accounts used during the evaluation were also created anonymously.

The goal was to demonstrate that, within Agni – a VLE that executes student code client-side in JavaScript – students would not perceive a significant difference between writing code in Python and in JavaScript when using Osiris.

To evaluate whether there was a significant difference in the difficulty encountered by students while completing programming exercises in Python compared to JavaScript within Agni, a Chi-squared test for independence was conducted. The independent variable is the language in which the exercises were presented to the students (Python or JavaScript). The dependent variable is whether the participant reported experiencing difficulty with the exercises (Yes/No). The observed frequencies of these reports are presented in Table 3.

Table 3: Frequency of reported difficulty while completing exercises by language.

Language of Exercises	With Difficulty (Yes)	Without Difficulty (No)	Total
Python	6	14	20
JavaScript	14	7	21

The Chi-squared test yielded a statistic of $\chi^{2}\approx 5.52$ (degrees of freedom, $df=1$ , $p\approx 0.019$ ). The $\chi^{2}$ statistic measures the discrepancy between the observed data and what would be expected if there were no association between the variables. The degrees of freedom indicate the number of independent values that can vary in the analysis. The $p$ -value represents the probability of observing data as extreme as, or more extreme than, the data collected if the null hypothesis (no association between language and difficulty) were true. This statistically significant result ( $p<0.05$ ) indicates that this probability is low enough to reject the null hypothesis, suggesting a significant association between the language in which the exercises were presented and the reported difficulty within the Agni VLE.

The observed proportions show that 30% of participants reported difficulties with Python. In contrast, 67% of participants reported difficulties with JavaScript. The statistically significant Chi-squared test confirms that this difference in the proportion of participants experiencing difficulty is unlikely to be due to random chance.

In summary, the analysis suggests that students encountered significantly more difficulty while completing the JavaScript exercises than those presented in Python within the Agni VLE. This indicates a perceived difference in difficulty between the two languages in the context of the exercises, even though the Python code was ultimately transpiled to JavaScript for execution within the environment.

However, the initial analysis of difficulty reports might be influenced by factors beyond the languages’ inherent challenges. Further investigation into students’ attempts to solve the exercises reveals additional insights.

An initial examination of the success rates based on student attempts shows revealing patterns in performance across both programming languages:

Table 4: Success rates of student attempts on exercises before and after removing attempts involving unsupported input functions.

	Before Removing Input Attempts	After Removing Input Attempts
Python	5/13 (38.46%)	5/7 (71.43%)
JavaScript	24.65/40 (61.63%)	24.65/35 (70.43%)

Upon closer examination of the unsuccessful attempts, it was found that a significant number of students in the Python group (6 out of 13 attempts) tried to use the input() function, and a number in the JavaScript group (5 out of 40 attempts) tried to use prompt(). These functions are not directly supported within the Agni environment as they were intended to implement output through function return values for automated assessment.

The proximity of the adjusted success rates suggests that when students used the intended methods for interacting with the exercises, there was no substantial difference in their ability to solve the problems between Python and JavaScript.

To evaluate whether this observed similarity is statistically significant, a two-proportion z-test was conducted. The null hypothesis is that there is no difference in the proportion of successful attempts between the two languages. The alternative hypothesis is that the proportions differ. Let:

$\blacksquare$

$p_{1}$ : proportion of success in Python = $\frac{5}{7}\approx 0.7143$
$\blacksquare$

$p_{2}$ : proportion of success in JavaScript = $\frac{24.65}{35}\approx 0.7043$

The test yielded a z-score of $z\approx 0.043$ with a corresponding two-tailed p-value of $p\approx 0.9656$ . Since $p>0.05$ , we fail to reject the null hypothesis. This confirms that the difference in success rates between Python and JavaScript, after excluding attempts involving unsupported input functions, is not statistically significant. Combined with the earlier finding that a smaller proportion of Python users reported difficulty overall, this indicates that the transpilation process did not introduce significant barriers to solving the exercises. The higher initial difficulty reported by the JavaScript group might be attributed to other factors or nuances within the JavaScript language itself for novice programmers in this specific exercise set.

5 Conclusions and Future Work

This paper introduces Osiris, a pure JavaScript multi-language transpiler specifically designed for educational Virtual Learning Environments. By leveraging ANTLR for parsing and employing carefully crafted semantic rules, Osiris successfully translates code from other programming languages, exemplified here with Python, into JavaScript for client-side execution within web browsers. This approach effectively addresses the limitations associated with server-side code execution, such as the need for constant internet connectivity, increased bandwidth consumption, and centralized server load.

The evaluation using the ToPAS dataset demonstrated Osiris’s capability to transpile and correctly execute a significant majority of introductory Python submissions, achieving a high percentage of passed test cases. The identified limitations, such as the lack of support for certain Python constructs, provide clear directions for future development.

Furthermore, the integration of Osiris into the Agni VLE and the subsequent study with beginner programming students yielded insightful results. While the initial analysis indicated a statistically significant difference in the reported difficulty between Python and JavaScript exercises, favorable to Osiris, further investigation into student attempts revealed that this perceived difficulty might be influenced by a higher use of JavaScript by students than Python. After accounting for this, targeting the actual attempts made, it was discovered that students were utilizing Agni in unintended ways. Upon removing these irrelevant attempts, the success rates in both languages became remarkably similar. This suggests that for introductory programming exercises, and when students adhere to the intended interaction methods within the VLE, the use of Python transpiled to JavaScript does not present a significant pedagogical disadvantage compared to using JavaScript directly.

Looking ahead, several avenues for future work are planned to enhance Osiris:

Expanding Language Support

The current implementation primarily focuses on Python. Future efforts will involve extending Osiris to support other popular introductory programming languages, thereby broadening its applicability.

Adding Comprehensive Debugging Functionalities

Implement robust and interactive debugging tools. This includes features such as:

$\blacksquare$

Interactive Breakpoints: Allowing students to set breakpoints in their original source code to pause execution.
$\blacksquare$

Step-by-Step Execution Control: Providing controls for stepping over, stepping into, and stepping out of function calls for granular inspection.
$\blacksquare$

Variable Inspection and Watchers: A dedicated panel to inspect and monitor variable values in the original language context.
$\blacksquare$

Call Stack Visualization: Displaying the current function call stack to aid in understanding program flow.

These features will significantly enhance students’ ability to understand program behavior and identify logical errors across all languages within the VLE.

Expanding Language Support

The current implementation primarily focuses on Python. Future efforts will involve extending Osiris to support other popular introductory programming languages, such as Logo, thereby broadening its applicability. Logo’s visual output capabilities will also be used to design new challenges that test and validate Osiris’s multi-language API in scenarios where graphical feedback is essential.

Addressing Current Limitations

The identified limitations in Python syntax support, such as for-else blocks, match blocks, f-string formatting, will be addressed to achieve greater fidelity with standard Python.

Enhancing the Python Language API and Library Emulation

Expand the current JavaScript implementation of Python’s core functionalities to include a broader range of built-in functions and potentially emulate essential aspects of popular introductory Python libraries. This would allow students to work with more diverse and realistic programming exercises within the browser environment.

In conclusion, Osiris presents an approach to delivering programming education within web-based VLEs without the reliance on constant server-side interaction. The validation study suggests that for introductory levels, the pedagogical outcomes using transpiled Python closely resemble those of JavaScript. Continued development and expansion of Osiris have the potential to significantly enhance the accessibility and flexibility of programming education.

References

[1] Codegrade - automated code assessment platform. https://codegrade.com/. Accessed: 2025-05-16.
[2] Codio - cloud-based computer science platform. https://codio.com/. Accessed: 2025-05-16.
[3] Vocareum - cloud-based coding lab and autograder. https://vocareum.com/. Accessed: 2025-05-16.
[4] AlaSQL. Jison: Bison / YACC / LEX in JavaScript, 2025. URL: https://gerhobbelt.github.io/jison/.
[5] Kartik Chandra and Tim Radvan. Nearley: A Parsing Toolkit for JavaScript, 2014. URL: https://nearley.js.org/.
[6] Jay Earley. An efficient context-free parsing algorithm. Communications of the ACM, 13(2):94–102, 1970. doi:10.1145/362007.362035.
[7] Bryan Ford. Parsing expression grammars: A recognition-based syntactic foundation. In Proceedings of the 31st ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, pages 111–122, 2004. doi:10.1145/964001.964011.
[8] Babel Maintainers. Babel.js, 2014. URL: https://babeljs.io/.
[9] Stack Overflow. Developer survey results 2024, 2024. URL: https://survey.stackoverflow.co/2024/.
[10] Terence Parr and Sam Harwell. Adaptive ll(*) parsing: The power of dynamic analysis. In Proceedings of the ACM International Conference on Object Oriented Programming Systems Languages & Applications (OOPSLA), pages 579–598. ACM, 2014. doi:10.1145/2660193.2660202.
[11] Ricardo Alexandre Peixoto de Queirós. Integration of a learning playground into a lms. In Proceedings of the 27th ACM Conference on on Innovation and Technology in Computer Science Education Vol. 2, pages 626–626, 2022.
[12] SAP SE. Chevrotain: JavaScript Parsing DSL, 2025. URL: https://chevrotain.io/documentation/2_0_0/index.html.
[13] James Tauber and contributors. Pyjs - python web framework, 2007. Accessed: 2024-03-01. URL: https://pyjs.org/.
[14] The ANTLR Team. ANTLR4 JavaScript Target, 2025. URL: https://github.com/antlr/antlr4/blob/dev/doc/javascript-target.md.
[15] The ANTLR Team. PEG.js: Parser generator for JavaScript, 2025. URL: https://pegjs.org/.

[bib.bib1] [1] Codegrade - automated code assessment platform. https://codegrade.com/. Accessed: 2025-05-16.

[bib.bib2] [2] Codio - cloud-based computer science platform. https://codio.com/. Accessed: 2025-05-16.

[bib.bib3] [3] Vocareum - cloud-based coding lab and autograder. https://vocareum.com/. Accessed: 2025-05-16.

[bib.bib4] [4] AlaSQL. Jison: Bison / YACC / LEX in JavaScript, 2025. URL: https://gerhobbelt.github.io/jison/.

[bib.bib5] [5] Kartik Chandra and Tim Radvan. Nearley: A Parsing Toolkit for JavaScript, 2014. URL: https://nearley.js.org/.

[bib.bib6] [6] Jay Earley. An efficient context-free parsing algorithm. Communications of the ACM, 13(2):94–102, 1970. doi:10.1145/362007.362035.

[bib.bib7] [7] Bryan Ford. Parsing expression grammars: A recognition-based syntactic foundation. In Proceedings of the 31st ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, pages 111–122, 2004. doi:10.1145/964001.964011.

[bib.bib8] [8] Babel Maintainers. Babel.js, 2014. URL: https://babeljs.io/.

[bib.bib9] [9] Stack Overflow. Developer survey results 2024, 2024. URL: https://survey.stackoverflow.co/2024/.

[bib.bib10] [10] Terence Parr and Sam Harwell. Adaptive ll(*) parsing: The power of dynamic analysis. In Proceedings of the ACM International Conference on Object Oriented Programming Systems Languages & Applications (OOPSLA), pages 579–598. ACM, 2014. doi:10.1145/2660193.2660202.

[bib.bib11] [11] Ricardo Alexandre Peixoto de Queirós. Integration of a learning playground into a lms. In Proceedings of the 27th ACM Conference on on Innovation and Technology in Computer Science Education Vol. 2, pages 626–626, 2022.

[bib.bib12] [12] SAP SE. Chevrotain: JavaScript Parsing DSL, 2025. URL: https://chevrotain.io/documentation/2_0_0/index.html.

[bib.bib13] [13] James Tauber and contributors. Pyjs - python web framework, 2007. Accessed: 2024-03-01. URL: https://pyjs.org/.

[bib.bib14] [14] The ANTLR Team. ANTLR4 JavaScript Target, 2025. URL: https://github.com/antlr/antlr4/blob/dev/doc/javascript-target.md.

[bib.bib15] [15] The ANTLR Team. PEG.js: Parser generator for JavaScript, 2025. URL: https://pegjs.org/.