The philosophy

1. Clarity is the point

Vision's design starts from a belief that code should be legible to a careful reader who has not seen the codebase before. Not just understandable after effort — readable, the way prose is readable, without decoding.

This is not primarily an aesthetic preference. When code is opaque, only the person who wrote it can safely change it. Opacity concentrates knowledge, raises the cost of maintenance, and excludes people who would otherwise contribute. The wall between those who code and those who don't is not inevitable — it is, mostly, a stack of unnecessary symbols.

Vision replaces the symbols with words. The grammar is fixed and small. Names carry the human meaning. The structure is in the indentation, which you can see. The result is code that explains itself on the page.

2. Failure is never ignored

A program that silently ignores a failure is lying to the person running it. The file wasn't written. The network request didn't succeed. The data was corrupt. In most languages, the code for "I checked and everything is fine" looks identical to the code for "I didn't bother checking."

Vision refuses to compile a program that leaves a failure unhandled. The but if clause is not optional. This forces the author to make a decision at every failure site — handle it here, pass it up, or exit. Every path through the program is accounted for.

3. Effects are visible

Side effects — writing to a file, reading a clock, sending a network request — are the primary source of hard-to-reproduce bugs. They change state outside the program, which means they can fail in ways that pure logic cannot, and their failures can be difficult to observe.

Vision marks every side-effecting line with >>. The marker is enforced by the compiler; you cannot accidentally omit it. A reader looking for the places where state is changed can find them at a glance, in any codebase, without reading documentation. A line without >> is provably free of side effects.

4. Grouping is explicit

Operator precedence is a source of subtle bugs that do not produce errors — they produce wrong answers. The wrong answer is only found when someone notices that something downstream is incorrect.

Vision refuses to compile expressions that mix operators without explicit grouping. The order is always on the page. There is no rule to remember, no precedence table to consult. The calculation means exactly what it appears to mean.

5. Memory is automatic

Manual memory management is a solved problem. The solutions — garbage collection, region-based memory, ownership types — each have tradeoffs, but none of them require the programmer to write malloc and free by hand. Vision manages memory beneath the floor. You name things; they live as long as they are needed.

There are no pointers in Vision code. There is no null. There is no use-after-free, no double-free, no buffer overflow. These are not vision's problems; they are handled, invisibly, at compile time.

6. Owned and verifiable

Vision is built by one person — June — at Asha Software. The source is at kepr.uk/vision. The build is deterministic and reproducible. The compiler's binary can be verified against the source using koh verify.

There is no telemetry. No crash reporting. No update pings. No analytics. The language does not phone home. What runs on your machine is exactly what you built or verified; nothing is hidden.

Why this, now

Software has become large, opaque, and fragile — not because complexity is unavoidable, but because the languages and tools we inherited from the 1970s optimise for things that mattered then (memory and CPU) and not for what matters now (human understanding, safety, and trust).

Vision is a bet that a language can be fast enough, safe enough, and small enough without requiring the reader to decode it. The wall between "people who code" and "people who don't" was never real — it was always, mostly, a failure of language design. Hope in every line.