In this post, I want to explain how I approached the design of my own programming language, Light, and why some of its rules were designed the way they are.
When designing Light, I was not only deciding how programs should be written. I also had to define how those programs should behave, how different features should interact, and what rules should remain consistent throughout the language.
One question guided many of these decisions:
What rule should govern this, and how should it interact with the rest of the language?
This led to a design centered around explicit structure and dynamic flexibility.
Light defines structural rules for program entry, control flow, data access, and reusable program units. At runtime, variables remain dynamically typed while operations such as array access, expression evaluation, and type conversion follow defined rules.
The same principle applies to Purpose blocks and libraries. They are not isolated features; their behavior is designed to fit into the language's existing execution and data model.
A feature is not complete simply because its syntax works. Its behavior must remain predictable when combined with everything around it.
That is why I focus not only on what a feature can do, but also on where it belongs, what rules govern it, and how it interacts with existing constructs.
For me, this is the foundation of Light's design philosophy:
explicit rules, structured execution, and dynamic flexibility without sacrificing consistency.
Light is still under active development, including its standard libraries, so its design will continue to evolve as the language grows.
Your thoughts and feedback are appreciated.
Related: Building Light Programming Language — What I Learned After 9 Months
Explore Light on GitHub: GitHub Repository
Top comments (0)