Code Is Poetry
As a developer who works in a slightly unusual way, my job is to build the tool itself. While most people build services using established languages like Java, Python, or C++, I serve as the CTO of a team sculpting a new programming language called Topaz. The design philosophy of this language boils down to a single phrase. We want to create a language where code becomes poetry.
This is not a literary flourish. It is an engineering objective expressed differently. We aim to minimize maintenance costs and cognitive load.
Just as poetry chisels away unnecessary words to increase the density of meaning, good code must strip away unnecessary control flow. This leaves only the essence of the logic. Simplicity means reducing the number of states and branches. This shortens the path required to read and modify the code.
We do not leave this process of refinement to the goodwill of the developer. Instead, we chose to standardize it at the language level. By embedding formatters directly into the compiler and designing the syntax to default to an expression-oriented path, we force all code to naturally converge into its simplest form. Sitting before my monitor every day, I realize the principles of writing good code and writing good prose are identical at their roots.
Naming Defines Existence
In the Book of Genesis, God said "Let there be light," and there was light. Naming a variable or a function in programming is a similar act. It represents the exact moment meaning is born into the meaningless void of memory.
Reality is full of ambiguity. A function name forced into English often demands a "mental translation tax" for non-native speakers. This Reading Cost grows geometrically as a project scales. We decided to fully support Unicode identifiers in Topaz. This allows developers to code in the language that best captures their domain.
function greet(name: string) -> string {
return "Hello, {name}!"
}
While risks like normalization mismatches exist, we designed the compiler to enforce NFC normalization. It triggers build warnings when visually confusable characters are mixed. Finding the precise name is not a matter of taste. It is an effective design decision to eliminate system ambiguity.
The Flow of Connection
Great writing flows like water. There are no jarring bumps between sentences. Code should act the same way. The process of data transformation must continue naturally without breaking stride.
Traditional nested function calls like func(func2(data)) force the developer to read results from the inside out. This imposes a cognitive load as the brain tries to reconstruct the execution order in reverse. We introduced the Pipeline Operator (|>) in Topaz for this exact reason.
data
|> sort
|> filter(condition: x => x > 0)
|> printResult
Temporary variables and nested parentheses disappear. Only the process of data flowing and being refined remains. We drastically reduce the cost of reading code by exposing the execution order directly in the syntax.
The Aesthetics of Subtraction
The first rule of writing is to "kill your adverbs." Flowery modifiers are often shields for unconfident sentences. We implement this in the world of code through a design oriented around expressions.
While existing languages rely on "Statements" that change state, Topaz treats everything as an "Expression" returning a value.
let grade = match score {
case 90..100 => "A"
case 80..89 => "B"
case _ => "C"
}
As conditional blocks disappear, the complexity of the logic lowers. We ruthlessly reduce temporary state and assignment. Although expressions alone cannot eliminate all side effects, they minimize the cracks where errors can slip in.
"Write Less, Express More." This is not a literary slogan. it is an engineering strategy to eliminate the hiding places of bugs.
Structural Necessity
The ultimate common ground between poetry and code is inevitability. We must understand why it has to be this word and why this command must be in this position.
Just as changing a single word in a poem breaks its rhythm, a developer touching a single line of code can bring down a system. We introduced a strong type system and macros to prevent this instability.
function process(value: int | string | null) {
match value {
case int => value * 2
case string => value.length
case null => 0
}
}
The combination of union types and pattern matching is powerful. The compiler verifies that the developer has handled every possible case. This is Type Safety that permanently seals logical gaps. We also provide templates that understand structure, going far beyond simple string substitution.
// Prevent SQL injection at compile time
let query = sql`SELECT * FROM users WHERE id = ${id}`
// Elevate measurement logic to a reusable structure
measure("Data Processing") { ... }
Catching developer errors at the design stage instead of at runtime is our absolute goal.
Simplicity Is Engineering
As the world becomes more complex, software entropy inevitably increases. The only way to maintain order is to maintain simplicity.
A programming language is not merely a list of features. It is a tool that fixes the mindset of the team using it. Topaz is a deliberate experiment guiding that stream of thought toward safety. The beauty we pursue is not just code that looks good. It is code that is easy to read, has a clear flow, and inevitably filters out errors.
Truth is always simple. That simplicity is only beautiful when it is the result of refining intense complexity. Polishing the Topaz compiler today, I think about the future. I hope the code written in this language acts as a poem that brings joy to someone.
And so, code becomes poetry.