Principles
The Essence of essence
The criteria that decide what goes into the language, and more often what stays out. They are worth holding your own code to as well.
01
Explicit is better than implicit.
You should be able to tell what a program does by reading it, rather than by knowing which conversions and defaults the language applies behind your back. So Essence applies none: no coercion, no truthiness, no value that is secretly true or false, and no case quietly falling through to a branch nobody wrote. Spelling something out costs a few characters once, and saves every reader from guessing.
02
Extensibility is better than completeness.
No library is ever finished, because nobody can predict everything you will need from it. Essence is built to be extended from the outside: a type can be given new abilities long after it was created, no matter if it is yours or comes from a library. Room to extend beats a bigger surface with no way in.
03
Creating correct code must be enjoyable.
Correctness that costs a fight is correctness people route around, so every check the language makes has to earn its place by helping. The compiler is built to be worth reading: it shows what it understood and where it stopped, points at the rule you crossed, and performs the repair itself when there is an obvious one. Being rigorous should feel like the cheap path, not the expensive one.
04
Prototyping must be fast – thus refactoring must be painless.
Fast prototyping is worth little on its own: a first draft is a guess, and a language that makes the guess cheap to write and expensive to revise has only helped you commit to it sooner. So speed at the start carries an obligation — unmaking a decision has to cost no more than making it did. A rename reaches every file, and whatever stops fitting is listed rather than left for you to find.
05
Readability counts.
Code is read far more often than it is written, and by more people than wrote it, so wherever the reader's time and the writer's convenience collide, the reader wins. Names are spelled out instead of abbreviated, arguments are labelled so a call reads as a sentence, and layout is not a matter of opinion: one canonical format, nothing to configure, nobody's attention spent on it.
06
There should be one – and preferably only one – obvious way to do it.
Two ways of writing the same thing is a decision the writer has to make and every later reader has to work back through, and nothing was gained by either. So a job has one construct, a construct has one spelling, and where a difference would be pure style the formatter settles it and it stops being a choice at all. What you learn from one program carries to the next.
07
Practicality beats purity.
Real programs run into things a tidy model did not plan for: a platform that works the way it works, a library you have to talk to, a case that will not fit the rule. Holding the model together anyway does not make any of that go away — it moves the work to you. So Essence bends where it has to, to stay practical.
08
Simple is better than complex.
A language you can hold in your head is worth more than one that can express anything. Essence prefers few ideas that each go a long way over many that each cover a case, because complexity compounds: every new idea has to work with all the ones already there, so the tenth costs far more than the first. Every addition is asked whether the language would be simpler without it.
09
Complex is better than complicated.
Complex means many parts working together; complicated means tangled — difficulty that comes from how a thing was built, not from the problem itself. A hard problem does not get easier by being ignored; the only question is where the difficulty lives.
10
Beautiful is better than ugly.
Ugliness is rarely only about taste: it usually means something underneath does not fit. It also spreads — a construct that is awkward to write gets avoided, and what people write instead is usually worse. So beauty is not decoration; it is the shape of the code matching the shape of what it does.
11
Clever is seldom good.
Cleverness is written once and paid for by everyone who reads it afterwards, usually at the worst possible moment. Where a rule could be surprising and powerful or boring and predictable, Essence takes predictable — in the language, in the standard library, and in what the compiler does with a program it finds questionable, which is to report it rather than guess what you meant.