--- title: "Words to Create Worlds" author: "Milad Habibi" date: 2026-08-02 slug: words-to-create-worlds tags: ["language","simplicity","tokens","cost","ai"] canonical: https://simorg.tech/blog/words-to-create-worlds/ --- $$$Image fileName=words.jpg$$$ For most of the history of our craft, words were free. We could add a keyword here, a wrapper there, one more layer of abstraction to make a module read nicely, and the only price was the patience of the next engineer who opened the file. Verbosity was a matter of taste. Nobody sent you an invoice for it. That is not true anymore. A large share of the code written today is read and written by machines that charge by the word. Every keyword, every bracket, every polite layer of ceremony has become a line item. And unlike a human colleague, an agent does not read your codebase once and remember it. It reads again on the next task, and the next, and the next. This quietly changed what makes a programming language good. We did not design Simorg as an answer to that invoice. The work started before the agentic wave, for reasons that had nothing to do with cost. We were after something simpler: a language where you describe what should happen and nothing else. The savings arrived later, as a side effect. But they turned out to be the side effect that people notice first, so let's talk about it honestly. ## A Small Program Here is a complete guessing game in Simorg. It picks a number, asks you for a guess, and keeps asking until you get it right. ``` "@stl/random0.1.7" #random "@stl/terminal-input0.1.6" #terminal :terminal.promptAndReadLine $guess 9 random.integer $TARGET "Enter your guess: " guess guess = TARGET "Congratulations! You guessed right!" ? guess > TARGET "Target is smaller, Guess again: " guess guess < TARGET "Target is bigger, Guess again: " guess ``` Seven lines of code, and two of them are imports. Now the same program in a language you already know: ``` const readline = require('readline').createInterface({ input: process.stdin, output: process.stdout, }) const target = Math.floor(Math.random() * 10) function ask() { readline.question('Enter your guess: ', (answer) => { const guess = parseInt(answer, 10) if (Number.isNaN(guess)) { console.log('Please enter a number.') return ask() } if (guess === target) { console.log('Congratulations! You guessed right!') return readline.close() } console.log(guess > target ? 'Target is smaller.' : 'Target is bigger.') ask() }) } ask() ``` Nothing is wrong with the second one. It is ordinary, competent code, and most of us would write something close to it. But look at what the words are actually doing. <<>>, <<>>, <<>>, <<>>, the callback, the parser, the guard against a value that is not a number, the call that closes the stream. Almost none of that is the guessing game. It is the machinery you have to describe so that the machine can run the guessing game. The Simorg version has no such layer, because there is nothing to describe. That is the whole idea. ## Zero Reserved Keywords Simorg has no reserved keywords. Not fewer, none. There is no <<>>, no <<>>, no <<>>, no <<>>, no <<>>, no <<>>, no <<>>, no <<>>. There is no assignment operator either, which is why <<<=>>> gets to go back to meaning equality, the way it does in mathematics. Read the first of the three conditions again. ``` guess = TARGET "Congratulations! You guessed right!" ? ``` A value arrives in <<>>. It is compared to <<>>. If they match, the event passes forward and reaches the sentence, which vibrates and sends its own value on to the logger. If they do not match, nothing happens, because nothing needs to happen. There is no branch to open and close, no scope to declare, no <<>> waiting for its turn. We would love to claim we removed the keywords on purpose. We did not. We were working on something else: making data the owner of processing instead of its cargo. Some months into it we noticed that <<>> had nothing left to do. Then <<>>. Then the rest of them, one by one, until the list was empty. Simplicity was not the plan. It was what remained after we stopped adding things. ## Written From The Data's Point Of View In a classical language, business logic is captured by an external observer. That observer is you. You stand outside the program and narrate it: first do this, then check that, then loop until something. Control flow is the citizen, data is the passenger. Everything the language gives you, the keywords, the exceptions, the abstractions on top of abstractions, exists to help that observer keep the story straight in their head. Simorg removes the observer. Data drives. Your job is to lay out the environment through which data can flow, which is much closer to what an electronics engineer does when designing a circuit. You do not tell electrons what to do at each step. You arrange the paths, set the conditions, and the electrons do the rest. In Simorg you arrange the paths and the bytes do the rest. The practical consequence is that every token in a Simorg program points at something real. A value, a variable, a gate, an operator, a blueprint. There are no tokens whose only job is to explain the program to a compiler, and no tokens whose only job is to reassure a reader. This is what we mean when we say the language spends nothing on ceremony. ## Nothing To Guard Against Two more things are missing from Simorg, and both of them used to be large parts of your codebase. The first is nothingness. No <<>>, no <<>>, no <<>>, no <<>>. Data is what drives execution, and a thing that does not exist cannot drive anything. Nothingness is handled by the engine as a passing state on the way to existence, not as a value you are handed and expected to check. The second is the exception. Simorg does not throw at runtime. If a value cannot be converted, the engine logs it and the event that depended on it simply does not happen. Nothing tears down the call stack, because there is no call stack to tear down. Take a moment with what that removes from a normal working day. The null checks. The optional chaining. The try blocks wrapped around code that is probably fine. The guard clauses at the top of every function. The tests that exist only to prove the guards work. In most codebases this defensive layer is not a corner of the work, it is a serious share of it, and it is written, reviewed, maintained, and now read by an agent on every single pass. In Simorg it is not there to read. ## Where This Shows Up On The Bill Cost in the agentic era comes from three places, and language simplicity touches all three. Reading. Before an agent can change anything, it has to load enough of your code to understand it. Fewer lines and less ceremony mean a smaller context for the same understanding. Writing. A program that takes seven lines instead of twenty four costs less to generate, and it costs less again on every regeneration, which is the part people underestimate. Agents rarely get it right the first time. Being wrong. This one is the quiet expense. A language with no reserved keywords, no assignment semantics to confuse with equality, no null, and no exceptions is a language with a smaller surface to be wrong about. Fewer invented APIs, fewer half-remembered idioms, fewer retries. Every retry is a full round trip you paid for. We are not going to hand you a percentage. We are early, honest numbers need a lot more real workloads than we have, and marketing arithmetic is not what we want to be known for. Count the tokens in the two programs above yourself. That comparison is the argument. ## Simplicity Compounds The language is only half of it. The other half is what happens when a solution already exists. The Simorg repository holds blueprints and artifacts: pieces of working software wrapped in Simorg code and published by artisans. An agent working with a blueprint deals with its surface, not its internals. It does not read a dependency tree to use a random number generator. It does not pull a library's source into context to send a message to a device. That has two effects worth noting. Artisans keep their work protected, since artifacts do not have to be opened to be used. And every artifact that gets published lowers the cost of the next solution built on top of it. The ecosystem gets cheaper as it grows, rather than heavier. ## What Simplicity Does Not Mean Simorg is young. The engine and the toolchain are in beta, the standard library covers the basics and not much more, and the ecosystem is small enough that you will hit a gap in an afternoon of real work. A language being simple is not the same as everything being easy yet, and we would rather say that here than let you discover it on your own. There is also a genuine learning curve, though it is an unusual one. The hard part is not what you have to learn. It is what you have to put down. Engineers who have spent fifteen years thinking in control flow spend their first hours looking for the <<>>. Once the shape of a dataflow clicks, most people stop reaching for it. ## Words To Create Worlds Our ancestors believed words were channels of power. After a few thousand years, that belief is holding up better than most. A programming language is the path that meaning travels down before it becomes a running system. If the path is crowded with ceremony, everything that walks it, human or agent, pays a toll. We think that toll is optional, and we think the way to remove it is not to compress the language but to stop needing the parts we were compressing. Machine problems belong to machines. The mind of an artisan is too good to spend on syntax. If you want to see the language for yourself, start with $$$ToPageLinker keyword=Simorg in 10 Minutes toRoute=/docs/reference-book/simorg-in-10-minutes$$$, or grab a build from the $$$ToPageLinker keyword=download page toRoute=/download$$$. If you are building something real and want to work with us while the technology matures, the $$$ToPageLinker keyword=Pilot Program toRoute=https://logos.simorg.tech/signup$$$ is open for applications. Happy creation!