Building Quidra: A Programming Language Designed for Maximum Meaning Per Token

小林大起 — Tue, 13 Oct 2026 15:53:33 +0000

What if shorter code isn't always better?

I'm building Quidra, an experimental, open-source programming language guided by one idea: Maximum Meaning Per Token (MMPT).

The goal isn't to make every program as short as possible. It's to remove unnecessary ceremony while keeping the information that helps humans, compilers, and code-generating tools understand what a program actually does.

Quidra is statically typed, implemented in C++20, and uses LLVM for native compilation. It isn't a Python wrapper or a transpiler to another high-level language.

Try it: Playground · GitHub · Website

Less syntax, but not less meaning

Consider mutation. A short function call can hide an important fact: the function might change the variable you pass to it.

In Quidra, mutable access to existing storage is explicit at both ends:

void increment(int &value)
    value += 1

int count = 7
increment(&count)

print(count)
print(NL)

The parameter int &value declares writable access. The call increment(&count) makes that authority visible to the reader without requiring them to inspect the implementation.

Yes, & is an extra token. But it conveys a distinction that can affect correctness. To me, that's a good trade.

Assignment should not secretly create aliases

Quidra uses value semantics for ordinary assignments:

int[] original = [1, 2, 3]
int[] copy = original

copy[0] = 9

Changing copy doesn't change original.

The compiler and runtime are free to optimize the implementation, including with copy-on-write, as long as observable behavior stays the same. The point is not to force expensive physical copies; it's to give assignment a predictable meaning.

Tensor shapes belong in contracts

In numerical computing, many errors come from assumptions about tensor shapes that never appear in function signatures.

Quidra can express shape constraints directly in a type:

real32 first_sample(const tensor<real32>{3, _, _} pixels)
    return pixels[0, 0, 0].item()

Here, tensor<real32>{3, _, _} means a tensor with real32 elements, exactly three dimensions, and a first dimension of size 3. The other two dimensions are unconstrained.

The const parameter also communicates that the function doesn't have permission to modify its argument.

Shape information doesn't eliminate every runtime check. But when the compiler can prove a mismatch, I'd rather find out before running the program.

Conversions should be decisions, not surprises

Quidra distinguishes mathematical numeric types from fixed-width representations. For instance, int is arbitrary-precision, while int64 and real64 have specific machine representations.

Converting an existing typed value is explicit:

int value = 10
real64 converted = real64(value)

This can be more verbose than implicit promotion. That's intentional: changing a value's representation may change its range or precision, and the source code should make that decision visible.

Quidra also supports T | error for typed failure and try for propagation, while allowing a fail-fast path when a caller doesn't need to retain the error explicitly. The aim is to make important failure contracts available without surrounding every ordinary operation with ceremony.

A native compiler, not just a syntax experiment

The Quidra compiler is written in C++20 and uses LLVM for native code generation. The project includes a REPL, JIT/AOT execution paths, diagnostics, language tooling, tensors, and automatic differentiation infrastructure.

There are also separate first-party repositories for Math, NN, Vision, Video, and DNN. Quidra is intended to be a general-purpose language, with numerical computing and machine learning as important applications—not its only use cases.

You can find the implementation, specifications, and examples in the GitHub organization.

Can language design make LLM-generated code more reliable?

This is one of the questions motivating Quidra.

LLMs can already write code in established languages. But syntax that is easy to produce isn't necessarily code that is easy to verify or safely modify.

My hypothesis is that explicit mutation, predictable value semantics, checked numeric conversions, and visible shape and error contracts could help both developers and code-generation tools reason about programs.

That is a hypothesis, not a proven advantage. Meaningful comparisons will require controlled experiments and careful attention to how much existing language knowledge an LLM has already learned.

I'm as interested in finding where this approach fails as in finding where it works.

What Quidra isn't (yet)

Quidra is experimental and pre-1.0. Its ecosystem, tooling, and real-world adoption are far smaller than those of Python, Rust, or C++. Some design decisions may change as the implementation and tests evolve.

And explicitness has a cost: sometimes a program needs more characters. MMPT is about meaningful tokens, not winning a character-count contest.

I'd love your feedback—and contributors are welcome

I'm particularly interested in these questions:

Which distinctions deserve explicit syntax, and which can safely be inferred?
Where would these design choices create friction in real programs?
How should we measure whether a language helps people or LLMs write more reliable code?

Quidra is MIT-licensed, and I'm looking for open-source collaborators interested in compilers, C++/LLVM, language design, developer tooling, testing, documentation, math, and ML. You don't have to be a compiler expert: there are approachable first contributions, too.

Constructive criticism is very welcome. A language gets better when people try to break its assumptions.

Disclosure: AI assistance was used to draft and edit the English wording of this article. The design, code examples, and current implementation are documented in the linked repository.

DEV Community: 小林大起