An error should teach,
not just interrupt.

A beginner can write a program with a single misplaced symbol and end up staring at an error message that assumes they already understand the language. That is a poor feedback loop. The tool has identified a problem, but it has not necessarily helped the learner recover.

While building TongaLang, I treated the desktop IDE as part of the language's educational design. The interpreter executes programs; the IDE helps a learner write, inspect, run and correct them. Its job is not to hide every difficulty. It is to make the next useful step visible.

Diagnostics with context

TongaLang's diagnostics cover lexical, syntax and semantic issues. A diagnostic is more useful when it can identify the exact source location, explain the issue in language a learner can understand, and provide a hint that points toward a correction.

The language engine records source positions and stable diagnostic codes. The IDE uses those details to highlight the relevant text and present a Problems pane. Explanations can be shown in English and Tonga, reflecting the project's goal of making the language experience more approachable.

The distinction between an error and a hint matters. A diagnostic should say what the implementation knows; a hint should help the learner investigate. The interface should not pretend to know more than the parser or runtime can establish.

Safe fixes, not silent rewriting

Where the correction is deterministic, TongaLang can offer a guarded one-click fix. The user sees the proposed action and chooses whether to apply it. The change is undoable, and the IDE protects against applying a stale suggestion after the source has changed.

This is a deliberate boundary. An educational tool should not quietly rewrite a learner's work and leave them unsure why the program changed. When a correction is ambiguous, the better response is to explain the problem and let the learner decide what to do.

One place to inspect problems

The collapsible Problems pane groups diagnostics into a workflow. A learner can navigate to the relevant code, copy diagnostic details when asking for help, and apply a safe fix when one is offered. Keyboard navigation and source highlighting help keep the workflow usable beyond a mouse-only interaction.

The pane is not a substitute for understanding the grammar. It is a bridge between the language engine's precise report and the learner's next action.

Making the AST visible

The abstract syntax tree is often hidden inside an interpreter implementation. TongaLang includes a graphical AST explorer so learners can inspect the structure produced by parsing. Nodes retain source locations, connecting the tree back to the text in the editor.

This makes an abstract idea tangible. A conditional is no longer only a block of text with braces; it is a structured node with a condition and branches. A function declaration has a name, parameters and a body. The AST view can help explain how a parser sees a program.

Interactive input without freezing the window

Input exposed a different class of problem. When a TongaLang program calls bala(), execution needs to wait for the learner's response. A naive implementation can block the GUI event loop, making the whole window appear frozen.

I built a shared, resizable Program Input dock for the Editor and Output views. When a running program requests input, the dock becomes available while the rest of the interface remains responsive. Submitted values are echoed into the Output transcript before execution continues, so the learner can see both the program's output and the input that shaped it.

Keeping one input workflow also avoids scattering controls across multiple screens. The learner should not have to guess which panel owns the next interaction.

Small interface decisions matter

The IDE includes dark and light themes with semantic colours for language constructs, grouped and scrollable settings, Back and Forward view history, a collapsible navigation menu, a grammar reference and an internal console. These features are not the central research question, but they determine whether the environment remains usable as the project grows.

For example, scrollable settings matter when a window is short. Semantic colours matter when learners need to distinguish language constructs at a glance. A console matters because internal messages should not be mixed into the source editor.

How I tested the experience

The repository documents tests for diagnostics, safe fixes, stale edits, input handoff, repeated and blank input, visible transcripts, navigation, scrolling, themes and GUI recovery workflows. The project README records 179 passing automated tests across the current suite.

That does not prove the IDE is effective for every learner. Usability with actual beginner cohorts still needs structured evaluation. Automated tests establish that expected software behaviours work; learner studies would help establish whether those behaviours improve understanding.

Try the IDE

• TongaLang source code and screenshots
• Installation instructions
• Latest release
• TongaLang project case study

The principle behind the IDE is simple: useful feedback should help a learner understand the program, not just tell them that the program failed. That is the standard I want TongaLang's tools to keep moving toward.

Written by Leo Mabuku · Software developer and Computer Science graduate · Get in touch