A while ago, I started a project called Exper.
The idea was simple: learn more about interpreters and language design by building my own programming language.
At first, it was extremely simple. Over time, it gained features such as:
- Variables
- Functions
- Structs
- Loops
- Conditionals
- Lists
- String interpolation
Today, Exper can already run relatively large programs.
What has helped me the most is not small examples, but a text-based RPG that I am building to test the language.
The RPG forces the implementation of real-world features:
- Inventory systems
- Objects
- Combat mechanics
- Data structures
- Reference passing
- List manipulation
Interestingly, most bugs only appear when you try to build something real.
For example, I recently discovered several issues involving reference passing and mutability while implementing an inventory system for potions.
Those problems would probably never appear in simple calculator examples.
Example
struct Player {
name,
hp = 100
}
player = Player()
player.name = "Callebe"
console.log("{player.name} has {player.hp} HP")
What I've Learned
Building a programming language is much harder than it seems.
Every time you think you're done:
- A scope bug appears.
- Then a mutability bug.
- Then a parser bug.
- Then a list bug.
- Then a reference bug.
But that's exactly what makes the project interesting.
What's Next
- Better method support
- Compound operators
- Module system
- Classes
- Exceptions
The goal is not to compete with Python or JavaScript.
The goal is to understand how they work internally.
So far, Exper has been an amazing teacher.
full source code here
Top comments (6)
The language is shaping up well.
At this stage, replacing eval with an AST-based interpreter will make execution more predictable, and implementing proper lexical scoping will stabilize functions and closures.
Separating parsing, evaluation, and runtime will improve maintainability and make it easier to add features like objects or new operators later.
Handling control flow through structured call frames rather than global state will prevent subtle bugs as the language grows.
I changed the GitHub repository
Thank. I changed the GitHub repository.
Great work! I checked your repository, and overall it looks solid.
One thing I noticed is that the naming conventions don't appear to be fully consistent throughout the codebase. Standardizing the naming rules would improve readability and make the project easier to maintain as it grows.
thank you for your feedback. I am 12 years old and I am programming this code by myself
You've done well. Keep going.