Why I Built the Bonezegei Scripting Language

Editorial assistance provided by Gemini AI

In the software engineering world, building a new programming language from scratch is often viewed as a monumental task reserved for academic researchers or massive tech conglomerates. But sometimes, a language isn’t born in a corporate boardroom—it is born at a developer's workbench out of sheer necessity and a desire for a better workflow.

If you spend enough time writing software, automating system operations, or developing applications for Single Board Computers (SBCs) like the Raspberry Pi, you eventually hit a wall of compromise. I kept finding myself frustrated by the tools available to me. They were either too complex to set up or too resource-heavy for my hardware.

Unable to find a tool that perfectly fit my workflow, I decided to build one. That is how my personal project, the Bonezegei Scripting Language (BSL), was created. Because BSL is currently in its early stages of development, this isn't a feature showcase or a marketing pitch. Instead, this is the story of the technical frustrations that fueled its creation, the design philosophy behind it, and where the language is heading next.

The Developer's Dilemma

When architecting software that needs to run efficiently—especially on constrained hardware like an SBC—developers are generally forced to choose between two very different paradigms. Factually speaking, both come with significant trade-offs.

1. C and C++: High Performance, High Developer Friction
There is no denying that C and C++ are the industry standards for system-level programming. They offer raw execution speed and granular control over hardware memory. However, the developer experience can be incredibly taxing. You are forced to navigate manual memory allocation, complex compiler toolchains, and rigid header files just to execute basic logic. I wanted the execution predictability of C, but I was exhausted by the heavy boilerplate required to get a project off the ground.

2. Python and Node.js: High Agility, High Hardware Overhead
To escape the friction of C, the modern solution is to use high-level interpreted languages like Python or JavaScript. While these allow for rapid prototyping, they introduce a massive technical downside: interpreter bloat. A JavaScript engine like V8 or a standard Python environment consumes a substantial amount of RAM and CPU. Running these heavy engines on a small SBC just to execute a background system task often feels like using a sledgehammer to drive a small nail.

The Syntax Factor

Beyond performance metrics, there was a deeply personal hurdle. Python is undeniably the most popular language in the world right now, but I have to be completely candid: I have never liked Python's syntax. The strict reliance on whitespace and mandatory indentation consistently disrupted my workflow. I greatly prefer the C-style syntax found in JavaScript. The explicit structure of curly braces {} and well-defined code blocks simply makes more sense to how my brain organizes logic.

Building a Quiet Middle Ground

I realized exactly what I was looking for: a language that featured the intuitive, curly-brace syntax of JavaScript, but was compiled and executed without a massive, memory-hungry virtual machine. So, I opened my editor and began writing a custom interpreter from scratch using standard C.
The architectural philosophy behind Bonezegei is straightforward:

Familiar, Explicit Syntax: If you know basic C or JavaScript, you can read and write Bonezegei instantly. There are no mandatory spaces or strict indentation rules—just clear, predictable syntax.

Lightweight: Because the interpreter is built natively in C, its memory footprint is small. It can run seamlessly on an SBC without dragging the system's resources down.

Where Bonezegei is Today (Stage One)

Bonezegei is currently in "Stage One." It remains a solo passion project that I am refining and expanding daily.
As of today, the language runs stably on Windows and Linux. I actively use it to develop system scripts and lightweight applications for my Single Board Computers. While the core engine is solid, my primary focus right now is building out libraries so that developing full-fledged desktop applications becomes a frictionless experience.