Programming Rewards Difficulty, Not Usefulness — Felienne Hermans at DDD Europe 2026

Felienne Hermans is a professor of computer science in Amsterdam, a high school CS teacher, and the author of the Hedy programming language. Her DDD Europe 2026 talk opens with her saying she has fallen out of love with the field. What follows is not a complaint. It is an argument with a mechanism, and the mechanism is testable — so we tested the part of it that can be run on a laptop.

The claim

Hermans argues that programming culture uses difficulty as a proxy for worth. Not usefulness, not reach, not how many people a thing serves — difficulty. Spreadsheets are dismissed as “not real programming” despite being the most widely used programming environment on earth. Making something easier is read as subtracting value rather than adding it.

She found the mechanism in an unlikely place: a 2016 paper on glaciology. There are two kinds of glaciers, high-mountain and low-lying rural ones, and we have far more data on the hard-to-reach ones. Not because they matter more. Because climbing a mountain makes you the hero of the story and standing in a village next to an accessible glacier does not. What gets valued decides what gets measured, which decides what we can conclude.

“Reading this paper about glaciers told me more about the programming language community than just existing in the programming language community for two decades.” — [17:00]

Applied back to her own work, the pushback she had spent years failing to understand suddenly parsed:

“If you take something that is hard, in my case, Python, and you make it easier, you make it into Hedy by localising, you are taking away value.” — [18:00]

We ran her numeral test on current runtimes

The most checkable part of the talk is a demo. Hermans shows that ٢+٩ — the Arabic-Indic digits for two and nine, used by hundreds of millions of people — fails across the top of the TIOBE index. It is the kind of demo that ages, so we reran it on what is installed today rather than repeating her slide.

Runtime	Version	Result of ٢+٩
Python	3.14.7	SyntaxError: invalid character '٢' (U+0662)
Node.js	24.15.0	SyntaxError: Invalid or unexpected token
Ruby	4.0.5	NameError: undefined local variable or method '٢'
PHP	8.5.5	Fatal error: Uncaught Error: Undefined constant "٢"
SQLite	3.50.6	Error: in prepare, no such column: ٢

Five out of five reject it, on releases from 2026. The demo has not aged.

Two things are worth adding that the talk does not.

The refusal is in the grammar, not the runtime. Python does not fail because it cannot handle these digits. It handles them perfectly well the moment they arrive as data:

int('٢٩')        # 29
'٩'.isdigit()    # True
int('٢') + int('٩')  # 11

The standard library knows exactly what those characters are. It is the literal syntax that refuses them. That is a stronger version of Hermans’ point than the one she makes on stage: this is not a limitation anyone ran into, it is a line someone drew. Unicode identifiers were added to Python in PEP 3131 in 2007 — non-ASCII was considered, and digits were left out of scope.

Our SQL result differs from hers. Her slide shows SQL passing, with “no error here.” SQLite 3.50.6 rejects it. Whatever engine produced her result, the outcome is engine-dependent, and “SQL handles it” is not a safe generalisation. We are flagging the discrepancy rather than smoothing it over, because the talk’s argument does not need SQL to pass.

The part that lands on AI tooling

The second half turns to LLMs, and the useful move is not the critique itself but the criterion she borrows to make it. Peter Naur’s 1984 “Programming as Theory Building”:

“What characterises intellectual activity, over and beyond activity that’s merely intelligent, is a person building and having a theory.” — [35:00]

A theory, in Naur’s sense, is what lets you answer why is it like this — to defend the design, recall the four approaches you rejected, and argue about it next month. Hermans’ conclusion:

“Maybe we have artificial intelligence, but certainly I would say we don’t have artificial intellectual activity. We don’t have machines that can produce knowledge and then also reason about the knowledge and defend the knowledge.” — [36:00]

This is a usable evaluation criterion, and it is sharper than most of what gets used to compare coding agents. Throughput benchmarks measure whether the diff lands. Naur’s test asks whether anyone still holds the theory afterwards. Those come apart precisely on the work that hurts later: an agent can produce a merged, passing change while the theory of why it is that way exists nowhere — not in the model, which keeps no consistent model of its own reasoning, and not in the reviewer who approved a diff they did not derive.

Her chess argument is the other durable piece. Engines have outplayed humans since 1997, and competitive chess simply barred them. Herbert Simon saw it coming in 1956:

“In ten years a computer will be the world champion in chess, unless it is barred from competition.” — [45:00]

The point is not that we should ban anything. It is that adoption was a decision, and it went the other way for chess:

“That something can exist, but we can still choose not to use it.” — [33:00]

Where the argument is weakest

Three places, and the talk does not defend them.

The causal story is one-directional. “Hard is valued, therefore easy things go unstudied” explains the spreadsheet reception well. It explains less well why JavaScript — dismissed on the same slide as “easy” — became the most-invested-in runtime ecosystem in the industry. Money and distribution do work here that prestige alone does not.

The strongest historical claims are the least load-bearing. The von Neumann and IBM sections are accurate and genuinely under-taught — Edwin Black’s IBM and the Holocaust documents the punch-card business in detail. But the origins of a field constrain its present much less tightly than the talk’s momentum implies, and a listener who rejects that leap can still accept everything in the first half.

“Programming is to make programmers happy” is the sharpest line and the weakest claim — a talk delivered to a conference audience about what that audience secretly values is not evidence about the field. The 2017 finding she cites, that caring about social change predicts not studying CS, is real support for a selection effect. It is not support for the motive she assigns to everyone who stayed.

None of this touches the numeral demo, which is the load-bearing evidence, and which reproduces.

What to take from it

Run her test on whatever you are building. If your input parser, your identifier rules, or your ID generator assumes ASCII digits, you have made the same choice Python made, probably without noticing.

Then take Naur’s question to whatever coding agent you are evaluating. Not “did the tests pass” but: a month from now, when someone asks why it is like this, does anyone have the theory? If the answer is no, the tool did not save the work. It moved it to whoever picks up the file next.

The talk is 48 minutes and Hermans draws her own slides. The glacier section starts around 15:00 and is the part worth watching even if you skip the rest.