Overview
Oker is my personal journey into the world of programming language design. Instead of just learning languages, I wanted to challenge myself to create one of my own. The idea came from curiosity, persistence, and the excitement of seeing code I wrote come alive in a language I built myself.
At its core, Oker is designed to be simple and human-friendly, while still supporting all the features needed to make it a complete language: variables, functions, loops, conditionals, classes, error handling, and file operations.
Motivation
The main reason behind Oker was to test my limits as a developer. I asked myself: “What if I didn’t just learn programming languages but actually built one?”
I wanted to understand the inner workings of interpreters and compilers.
I wanted to push myself to solve problems I had never faced before.
I wanted to build something unique, with my own design choices and syntax.
AI also played a role in this project. I used it as a supportive tool to guide me through complex concepts and fix roadblocks, but every decision, syntax design, and idea behind Oker came from my vision.
Development Phases
Oker has gone through two major phases so far:
Python Interpreter Version
The first version of Oker was written in Python.
It was purely interpreted, meaning every line of code was executed directly.
This allowed me to move fast and test ideas quickly, but it came at the cost of performance.
C++ Compiled Version
Later, I transitioned Oker into a C++ compiled language.
The goal of this phase was optimization and faster compilation times.
This step was challenging but helped me get closer to how real-world programming languages work under the hood.
Currently, Oker is still under active development. It is not a finished product, but every step adds new depth to my understanding of language design.
Challenges and Learnings
Building a language from scratch is not easy. Some of the challenges I faced include:
Understanding parsing and abstract syntax trees (ASTs).
Managing errors in a clear and consistent way.
Making syntax both flexible and simple.
Handling the trade-offs between interpreted and compiled implementations.
Through these challenges, I learned:
The difference between interpreters and compilers at a deep level.
How design choices, such as syntax rules, affect the developer experience.
How performance and optimization matter when scaling a project.
Current Status and Next Steps
Status: Oker is still a work in progress.
Next goals:
Expand the standard library.
Improve error messages and debugging support.
Add more complex data structures.
Explore IDE integration for smoother use.
Links
GitHub Repository Oker Language