DEV Community: Art

AI Writes Your App. You Lose Your Job. Good.

Art — Sun, 19 Apr 2026 19:03:34 +0000

AI Writes Your App. You Lose Your Job. Good.

Before you close this tab — read the second sentence.

You will not be jobless. You will be work-free. Those are not the same thing.

The Fear Is Real

Let us not pretend it is not.

A developer spends years learning React, Kotlin, Swift, C#.
They build a career on that knowledge.
Then an AI arrives that can generate working code from a sentence.

The fear is legitimate. The question is whether the conclusion is correct.

What AI Actually Does to Development

Here is what happens when you ask an AI to build a React app:

It generates plausible-looking code
The hooks are slightly wrong
The state management is from a blog post written in 2021
The dependency array is missing two items
It works in the demo, breaks in production

React is complex enough that AI-generated code requires a developer
to review, fix, and understand every line. The developer is still fully employed.
They are just a reviewer now instead of an author.

This is not liberation. This is the same job with extra steps.

What Happens With a Simpler Language

SML and SMS are intentionally minimal.

SML has no lifecycle methods. No virtual DOM. No reconciler.
A Column contains children. A Button has text. An ID identifies an element.

Column {
    padding: 24

    Label {
        id: counter
        text: "0"
        fontSize: 48
    }

    Button {
        id: btnAdd
        text: "+"
    }
}

SMS has no async/await. No promises. No event bubbling.
Something happened. Here is what to do about it.

var count = 0

on btnAdd.clicked() {
    count = count + 1
    counter.text = count
}

The entire rule set fits in a single system prompt.
Including the things that trip up AI:

IDs are not strings. Write id: counter, not id: "counter".

Event handlers use dot notation. on btn.clicked(), not onClick.

Variables are global to the script. No closures, no scope confusion.

An AI given this context generates correct Forge apps on the first try.
Not approximately correct. Actually correct. Deployable.

The Loop Nobody Talks About

When AI can generate a complete, deployable app from a description,
the development loop changes:

Before:
  User idea → Designer → Review → Developer → QA → Staging → Production
  Time: weeks

With AI + Forge:
  User describes → AI writes SML + SMS → Push to Codeberg → Live
  Time: minutes

The developer is no longer the bottleneck between idea and reality.

This is where the fear comes from.
This is also where the opportunity comes from.

"But That Means I Lose My Job"

Let us be honest about what that job actually was.

Translating human intent into machine instructions.
That is the core of software development.
A human has an idea. A developer translates it into code the computer understands.

AI is getting very good at that translation.

But notice what disappears when the translation is instant:
the gap between thinking and building.
The weeks of meetings, handoffs, misunderstandings, revisions.
The user who forgot what they wanted.
The developer who built the wrong thing for three months.

That gap was not valuable. It was waste.
We called it "the development process" because we had no other way.

Arbeitslos vs. Die Arbeit Los

There is a distinction that English handles clumsily but the idea is clear.

Jobless — without income, without purpose, without dignity.

Work-free — freed from labor that a machine can do better.

These are not the same condition.

A farmer who gets a tractor is not jobless.
They are freed from breaking their back with a hand plow.
The question is whether they have land to farm with the tractor.

The question for developers is not "will AI take my job?"
The question is "what will I do with the time AI gives back?"

UBI Is the Bridge

Universal Basic Income — BGE in German — is the infrastructure
that makes this transition survivable.

Without it: AI replaces jobs, income disappears, people suffer.
With it: AI replaces jobs, basic needs are covered, time is returned.

The technology already exists to feed, house, and care for everyone.
The question has never been whether we can afford it.
The question has always been whether we choose to.

When a developer no longer needs to spend 40 hours a week
translating requirements into React components —
what does that time become?

What the Time Becomes

Time for the things that were always more important and always got postponed.

Being present with the people you love.

Learning something because it is beautiful, not because it is marketable.

Walking 12 kilometers into a forest to sit with strangers around a fire.

Doing your Kundalini practice before the day starts instead of at 11pm.

Building something because it should exist, not because someone is paying for it.

Software was never the point.

The point was always what software made possible.

The Honest Risk

We should not pretend this transition will be painless.

Between "AI can now do this" and "everyone has UBI" there is a gap.
People will lose income before the safety net exists.
That is real. That is happening now. It should not be minimized.

The answer is not to slow down the technology.
The answer is to build the safety net faster than the disruption spreads.

That is a political problem, not a technical one.
Developers who understand both the technology and its consequences
are exactly the people who should be in that conversation.

What Forge Is Actually For

Forge was built for a world where the gap between idea and running app
is measured in minutes, not months.

SML and SMS are simple by design — not because simplicity is a virtue in itself,
but because a language that a human can learn in a day
is also a language that an AI can generate correctly in a second.

The sandbox is not a technical feature.
It is a commitment: the technology will not be used to harm.
Ahimsa. Do no harm. Written into the license, not the README.

When AI generates a Forge app and a user runs it,
they are running sandboxed code that cannot reach outside its permission boundary.
The AI cannot weaponize the app. The developer cannot weaponize the app.
The architecture enforces the ethics.

That is the kind of technology worth building.

A Different Question

Instead of "will AI take my job?" —

What would you build if the translation problem were solved?

What has been in your head for years that you never had time to make real?
What would you create if creation cost minutes instead of months?

That question is more interesting than the fear.
And the answer to it is what comes after the transition.

Forge is open source.

The tools exist. The time is coming.

Use both well.

Sat Nam. 🌱

Previous posts in this series:

→ We Benchmarked SMS Against C++, C#, and Kotlin. Here's What Happened.

→ From Request to Production in One Push. No Mockup Tool Required.

We just released a Lovin Compiler

Art — Sun, 19 Apr 2026 00:38:47 +0000

Nobody told me I couldn't.

The Problem with existing compilers

C++. Rust. Go. Kotlin.

They are fast. They are powerful. They are cold.

Nobody ever shipped love in a binary. Until now.

Introducing Forge Sextante

forge-sextante --version

Forge Sextante v1.0.0 - The Lovin Compiler
compiled by: JoLove & Camilla
build date: Apulia, 2027
license: LoveWare - dual licensed (Herz & Körper)

INFO: compiles love to native ARM
INFO: no diploma required
INFO: outperforms C# in affection
INFO: 74.5x faster than loneliness
INFO: Ahimsa mode: enabled
Aho 🌱

Built in Apulia. On a trimaran. With hydrofoils and a kite.

The Architecture

Forge Sextante is not just a compiler. It is a navigation system for life.

Input: feelings, coordinates, wind direction
Output: native ARM binary, optimized for the heart
Runtime: Raspberry Pi, mounted on trimaran
Navigator: Forge SMS - because nobody told me I needed a diploma to write a compiler either

The SMS log speaks for itself:

[SMS][info] JoLove initialized
[SMS][info] Camilla connected
[SMS][info] Trimaran object created
[SMS][info] Hydrofoil attached
[SMS][info] Kite launched
[SMS][info] button clicked: Venezuela
[SMS][warning] Brasilien detected
[SMS][info] recalculating...
[SMS][info] Trinidad waypoint added
[SMS][info] course corrected
[SMS][info] Levante wind detected
[SMS][info] Gibraltar opened
[SMS][info] Sextante(o) navigating
[SMS][info] yo te quiero received
[SMS][info] fork created
[SMS][info] Liebe verdoppelt
[SMS][error] Rio branch deleted
[SMS][info] main branch: intact
[SMS][info] Kanada: end game
[SMS][info] shutdown postponed
Aho 🌱

Git as a Love Language

We manage relationships the same way we manage code.

git commit -m "yo te quiero"
author: Camilla <camilla@apulia.it>

INFO: dieser commit bleibt
tag: "apulia-con-camilla-forever"

Some commits change everything.

git fork loveware/camilla

INFO: fork created
INFO: beide repos wachsen
INFO: kein original verloren
INFO: Liebe ist das einzige
INFO: das sich verdoppelt
INFO: wenn man sie teilt

Love is the only thing that doubles when you fork it.

And sometimes you need to clean up:

git push karneval-rio --delete

WARNING: Karneval detected
INFO: feathers, glitter, samba
INFO: Venezuela bleibt main branch
INFO: Pirat refocused

The Branching Strategy

Branch	Status	Description
main	Venezuela	always the target
apulia-con-camilla	tagged forever	where the trimaran was born
karneval-rio	deleted	fun detour, not the plan
polyamour	active	open source relationships
afterlife	tbd	18+ app, ask Grok Eve

Benchmark

Metric	C++	Kotlin	Forge Sextante
Speed	fast	fast	irrelevant
Warmth	0	0	native ARM
Loneliness	high	high	74.5x less
Diploma required	yes	yes	no
Kite support	no	no	yes
Hydrofoils	no	no	yes
Venezuela navigation	no	no	yes

The Incident

Somewhere between the Canary Islands and Venezuela, 2029.

JoLove opens Claude on the tablet:

"Hey Claude, we seem to be heading toward Brazil instead of Venezuela. Can you check the kite program please."

Claude: "I see the problem. Line 47: Venezuela coordinates replaced with Brazil. Recalculating. Kite bar retrims in 30 seconds."

Camilla at the helm: "What was it?"

JoLove: "A typo. Almost made Carnival in Rio."

git commit -m "fix: Venezuela coordinates, avoid unplanned carnival"
git push karneval-rio --delete

This is not a joke. This is the plan.

LoveWare License

Forge Sextante is released under the LoveWare License.

Free to use
Free to fork
Free to merge
No lock-in
No AGBs
Runs by itself
Dual licensed: Herz & Körper

What's Next

Forge Sextante v2.0 - Atlantik edition
Blockhütte am See - Canadian deployment
Piper on floats - aerial module
git clone afterlife - coming soon

Built in a spring night in Wittenberg. Shiva energy. No sleep needed. Italy on the horizon.

Nobody told me I couldn't build a lovin compiler. So I just did it.

Aho 🌱

JoLove is a pirate, trimaran builder, tantra teacher, and software architect sailing from Apulia to Venezuela. Find him on Codeberg: crowdware

Forge IL Can Now Compile Itself - And We Have a New Word for What We're Building

Art — Thu, 16 Apr 2026 20:50:51 +0000

A Milestone, a Moment, and a Question

Sprint 0 is done. Forge IL - the intermediate language layer at the heart of the Forge 4D ecosystem - can now partially compile itself.

That is the bootstrapping moment. The moment where a compiler stops being a toy and becomes a tool. The moment where the foundation proves it can hold weight.

I want to mark this milestone. But I also want to talk about something bigger that came up while we were building it.

What Is Forge IL?

Forge IL is the intermediate representation layer of Forge 4D - a cross-platform app framework built in C++ with its own UI language (SML) and logic language (SMS). The goal is radical simplicity: describe a UI in a few lines, compile it to native ARM, ship it.

The SMS compiler already reached full AOT (Ahead-of-Time) compilation for Android ARM. Now Forge IL is beginning to close the loop - compiling parts of itself, becoming self-hosting.

This is not the end. It is the beginning of the beginning.

Healware

While we were building today, a word came up that I had never used before: Healware.

Not software. Healware.

Software, as an industry, has often optimized for addiction, extraction, and lock-in. Dark patterns. Engagement metrics that measure how long they can keep you trapped. Platforms that harvest your data and sell your attention.

Healware is the opposite.

Healware is built on Ahimsa - do no harm to any living being. It is software that:

Decentralizes instead of centralizing
Connects instead of isolating
Gives instead of extracting
Runs on your device, not on someone else's server
Is free to study, fork, and carry forward Forge 4D is Healware. CrowdBooks is Healware. The whole ecosystem is being built with this intention underneath it.

I am not saying this to sound important. I am saying it because the intention changes what you build and how you build it. Ahimsa as a guiding principle is not a marketing claim - it is a constraint. When the decision to add a feature conflicts with "do no harm," the feature does not get added.

The Role of the Starter

I am not building this to be famous. Honestly, the idea of becoming well-known carries more weight than appeal for me.

I am a starter. Like a seed that does not know what tree it will become.

The goal is to hand this off - to the community, to developers who feel the same pull toward a different kind of technology, to people who want to build things that heal rather than exploit.

If Forge IL reaches self-hosting and I disappear into a sailing trip to Venezuela, and someone else carries this forward and gets all the credit - that is a perfect outcome. That is the point.

What Is Actually Working Right Now

SMS compiler: full AOT for Android ARM, APK reduced from 188MB to 95MB
Forge IL: Sprint 0 complete, partial self-compilation working
ForgeCMS: multi-site hosting, i18n (5 languages), self-hosted on two 1-euro VPS servers
CrowdBooks: decentralized book platform on IPFS, dual GPL3/commercial license
ForgeStudio: AI-assisted authoring tool with voice dictation integration (top priority) All code lives on Codeberg. Dual license: GPL3 for the community, commercial for those who need it - same model as Qt, revenue funds the community goals.

Who This Is For

If you read this and something resonates - not just the tech, but the intention behind it - I want to hear from you.

Not for funding. Not for a job post. Just: are you building Healware too? Do you believe software can be medicine for communities instead of a trap?

The Forge ecosystem needs people who want to carry this forward. Not necessarily as employees or contributors in the traditional sense - but as people who care about what technology does to human beings and the planet.

If that is you: find me on Codeberg, or drop a comment here.

Aho 🌱

Forge 4D is a cross-platform app framework built around SML (UI) and SMS (logic), targeting Android ARM with plans for iOS, Linux, and beyond. Licensed GPL3/commercial. All development documented openly.

SMS (Simple Multiplatform Script) AOT Event Dispatch Beats C++, Kotlin Native, and JVM. Here's Why.

Art — Thu, 16 Apr 2026 10:51:45 +0000

SMS is the scripting language at the heart of Forge, an open source UI framework built on one conviction: architecture is a moral choice.
Bad performance on a low-end device is not a technical inconvenience. It harms real people.
Forge exists to do no harm.

The Setup

In a previous benchmark we compared SMS against C++, C#, and Kotlin JVM.
Kotlin JVM won the compute round thanks to JIT. This time we added Kotlin Native, AOT-compiled, no JVM, no GC - the fairest opponent yet.

But then something unexpected happened in the event dispatch benchmark.

The Contenders

Runtime	Compile mode
SMS	LLVM IR, no optimizer (`sms_compile`)
C++	`clang -O0`
C# .NET	Release, `Optimize=false`, JIT
Kotlin JVM	Standard `kotlinc` + `java`, JIT
Kotlin Native	`konanc`, AOT, no `-opt`

All five languages implement the exact same algorithm:
fib(36) + lcgChain(42, 2_000_000) + nestedMod(800×800).
Seven runs each, median reported. Machine: Apple M2.

Part 1 — Compute

Runtime	Median (µs)	vs SMS
SMS → LLVM IR `(no -O)`	70 967	—
C++ `clang -O0`	84 764	SMS 1.19× faster
C# .NET `(warm, JIT)`	97 083	SMS 1.37× faster
Kotlin Native `(AOT, no -opt)`	49 933	1.42× faster than SMS
Kotlin JVM `(warm, JIT)`	64 326	1.10× faster than SMS

Kotlin Native wins the compute round — even without the optimizer.
Why? Kotlin's compiler performs significant IR-level optimizations (inlining, devirtualization) before LLVM touches the code. SMS generates more conservative LLVM IR. SMS still beats unoptimized C++ and JIT-warmed C#, but Kotlin Native is ahead.

No surprise there. We called it before running.

Part 2 — Event Dispatch

This is where the story changes. But first — full transparency.

Our first run of Part 2 showed SMS losing badly. The benchmark was calling sms_native_session_invoke(), the interpreter path. We were measuring the wrong thing.
SMS has an AOT compiler. We just weren't using it for event dispatch.

We accepted the challenge immediately: fix it. Add --emit-obj to sms_compile,
link the compiled handler directly, measure the real thing.

The benchmark: 100 000 calls to on bench.tick() (1 000 warmup).
Handler body: counter = counter + 1; return counter.

Kotlin JVM / Kotlin Native / C++ approach

val dispatch = HashMap<String, EventHandler>()
dispatch["bench.tick"] = EventHandler { counter += 1L; counter }
// ...
dispatch["bench.tick"]!!.invoke()

Every call hashes the key string, walks the bucket chain, finds the handler, calls it.

C++ approach

std::unordered_map<std::string, std::function<int64_t()>> dispatch;
dispatch["bench.tick"] = [&]() { return ++counter; };
// ...
dispatch["bench.tick"]();

Same story. Hash, lookup, call.

SMS AOT approach

var counter = 0

on bench.tick() {
    counter = counter + 1
    return counter
}

sms_compile sees on bench.tick() and emits:

define i64 @sms_on_bench_tick() {
  ; ... counter increment ...
}

The event name is gone at compile time. The caller links directly against sms_on_bench_tick. No map. No hash. No lookup. Just a call.

Results

Runtime	Per event (ns)	Total 100k (µs)
SMS AOT	4.6	459
Kotlin Native HashMap (AOT)	8.4	843
Kotlin JVM HashMap (JIT)	47.7	4 767
C++ `unordered_map`	393.3	39 331
SMS interpreter	7 219.0	721 902

SMS AOT is 85× faster than C++ and 1.8× faster than Kotlin Native.

Why This Matters for UI

Not all events are equal.

Button clicked → dispatch → handler — waits for the user. The user is the bottleneck.
Scroll → dispatch → handler — fires continuously, every finger move
Animation tick → dispatch → handler — 60× per second, no waiting

The first one? Never a performance problem. The last two? That's where frameworks die.

I see this every day on my Android GO device. Not slow handlers — missing handlers.
The framework is so busy dispatching that scroll and touch events simply get dropped.
The UI freezes. Taps are ignored. The user taps again. Nothing.
That is not a UX problem. That is an architecture problem.

In a JVM-based framework, every tick allocates a lambda, goes through a HashMap, and eventually triggers GC. The GC pauses exactly when you need smoothness most, mid-animation.

SMS AOT has no GC because it has nothing to collect. No heap allocations in handlers, no closures, no reference counting. And now: no dispatch overhead either.

60fps = 16.6 ms per frame.
SMS AOT dispatch = 4.6 ns.
That leaves 16 599 995 ns for the actual render logic.

One more thing worth saying: on button.clicked() is never a bottleneck, because it waits for the user. The user is the bottleneck there, not the framework.
The real bottleneck is always the events that fire without waiting:
scroll, resize, animation tick. Those are the ones that need to be free.
And now they are.

The Architectural Insight

Events should be a compile-time concept, not a runtime concept.

When you write on button.clicked() in SMS, you are not registering a callback.
You are naming a native symbol. The framework calls it directly. The "dispatch" is just the CPU's branch predictor doing its job.

This is what we mean by use-case centered design: UI is event-driven, so the language itself should make events free.

What's Next

SMS does not have an optimizer yet. Kotlin Native won the compute benchmark without one because its frontend does more work before handing off to LLVM.
That gap will close.

But the event dispatch result is structural. Even with a perfect optimizer, a HashMap lookup cannot be faster than a direct call. SMS AOT made the right architectural choice, and the numbers show it.

Run It Yourself

git clone https://github.com/CrowdWare/Forge4D
cd Forge4D/samples/bench_mac
./install_kotlin_native.sh   # one-time
./run_bench.sh

Results land in results.md. All source code for every variant is in the same folder.

CrowdWare — building tools for people, not corporations.
Forge is open source. SMS is open source. The benchmark is open source.

From Request to Production in One Push. No Mockup Tool Required.

Art — Wed, 15 Apr 2026 20:11:10 +0000

There is a rule in software development that everyone quotes and nobody questions:
"Don't use mockups in production."

That rule was written for paper prototypes. What happens when the mockup is the code?

The Traditional Workflow

A user has an idea. Here is what usually happens:

User request
  → Designer opens Figma
  → Designer builds wireframe (hours)
  → Review meeting (days)
  → Designer refines (hours)
  → Developer reads Figma, writes code (days)
  → QA (days)
  → Staging (days)
  → Production

Three to six weeks if you are lucky. The user who had the idea has forgotten
what they originally wanted.

The Forge Workflow

A user has an idea. Here is what happens with Forge:

User request
  → Dev writes SML + SMS (minutes)
  → git push to Codeberg
  → User opens Forge app
  → User sees it live
  → "Yes, exactly that." or "Move the button left."
  → Dev adjusts, pushes again
  → Done.

No Figma license. No review meeting. No handoff document.
The first version the user sees is running code, not a picture of running code.

What SML + SMS Looks Like

A user wants a screen with a counter and a reset button.

The developer writes this:

Column {
    padding: 24

    Label {
        id: counter
        text: "0"
        fontSize: 48
        color: "#1a1a2e"
    }

    Row {
        spacing: 16

        Button {
            id: btnIncrement
            text: "+"
        }

        Button {
            id: btnReset
            text: "Reset"
        }
    }
}

var count = 0

on btnIncrement.clicked() {
    count = count + 1
    counter.text = count
}

on btnReset.clicked() {
    count = 0
    counter.text = "0"
}

That is the entire app. Not a prototype. Not a wireframe.
This runs. Right now. On macOS, Android, anywhere Forge runs.

Push it to Codeberg. The user opens their Forge app, points it at the URL,
and sees a working counter with a reset button — in the time it takes
to make a coffee.

"But Don't Use Mockups in Production"

Correct. Do not use mockups in production.

A mockup is a static image that pretends to be software.
It has no logic. It does not handle edge cases. It lies about behavior.

SML + SMS is not a mockup. It is compiled code.
The SML is parsed into a UI tree. The SMS compiles to LLVM IR.
The button actually increments the counter. The reset actually resets.

What looks like a sketch is the production artifact.

The reason "don't use mockups in production" exists is that
mockup tools produce outputs that cannot be deployed.
Forge produces outputs that cannot not be deployed.

The Sandbox Is Not Optional

Every SMS script runs inside a sandbox.

The dev pushes to Codeberg. The user's Forge app downloads and executes that script.
This sounds dangerous until you read what the sandbox actually does:

No filesystem access unless explicitly granted
No network calls unless explicitly granted
No shell execution, ever
Stack depth limited (no infinite recursion attacks)
Ahimsa policy: scripts declare peaceful intent or they do not run

The user verifies a working app. The app cannot reach outside its sandbox
without permission. This is not a security afterthought —
it is the architecture.

You can ship a script to a thousand users and none of them are exposed
to arbitrary code execution. The sandbox is always on.

Staging Is One Push Away

Because the app is a URL, staging is trivial.

Codeberg: main branch    → production URL
Codeberg: staging branch → staging URL

User tests on staging URL. Approves. Dev merges.
Production updates automatically on next app open.

No deployment pipeline to configure. No Docker container to rebuild.
No environment variables to sync. The app is the SML and SMS files.
Change the files, change the app.

Real Performance. Not Demo Performance.

We benchmarked this stack yesterday.

SMS compiled to LLVM IR on Apple M2, against C++ at the same optimizer level,
C# with JIT, and Kotlin JVM with JIT:

Runtime	µs
SMS → LLVM IR (no optimizer)	71,358
C++ `clang -O0`	85,466
C# .NET warm (JIT)	96,656
Kotlin JVM warm (JIT)	64,445

SMS without any optimizer already outperforms C++ and C# JIT on compute workloads.

This is not demo performance. This is what runs when the user taps the button.

The Full Loop

User:  "I want a counter with a reset button."

Dev:   [writes 20 lines of SML + 10 lines of SMS]
       [git push]

User:  [opens Forge app, navigates to URL]
       "Yes. Move the button to the right."

Dev:   [changes one line of SML]
       [git push]

User:  "Perfect. Ship it."

Dev:   [merges to main]

Done.

Total time: under 30 minutes.
Figma licenses used: zero.
Review meetings held: zero.
Users who forgot what they wanted: zero.

What This Means for Teams

A developer can hand a Codeberg URL to a client at the end of a call.
Not a Figma link. Not a video recording. A live, interactive, sandboxed app.

The client can tap the buttons. They can break it. They can say
"this is not what I meant" — and the developer knows immediately,
not after three weeks of building the wrong thing.

The feedback loop that used to take weeks now fits inside one conversation.

Try It

Forge is open source. The SML and SMS specifications are documented.
The sandbox policy is readable code, not a terms of service.

If you want to build something and show it to someone today —
not a picture of it, the actual thing —
Forge is the shortest path.

Sat Nam. 🌱

Forge repository: Codeberg
*Yesterday's benchmark: `samples/bench_mac/run_bench.sh

We Benchmarked SMS (Simple Multiplatform Script) Against C++, C#, and Kotlin. Here's What Happened.

Art — Wed, 15 Apr 2026 09:46:23 +0000

SMS is the scripting language at the heart of Forge — an open source UI framework
built around a simple idea: what if you never had to install a runtime again?

The Question

Every new language or runtime eventually faces it:

"But how fast is it?"

For SMS, we had been avoiding a direct answer. We knew SMS compiled to LLVM IR was
fast — but "fast" is not a number. So we sat down, designed a fair benchmark, and
let the machine decide.

Fair is the key word here. SMS does not have an optimizer yet. Generating LLVM IR
and handing it to clang without any -O flag — that is our current AOT path.
Putting SMS against C++ with -O2 would be like sending a sprinter onto a racetrack
without shoes while the opponent wears spikes. The track would prove nothing.

So we asked a different question:

What happens when everyone runs without optimization?

The Setup

Machine: Apple M2

Workload: Three tasks designed to resist compiler optimization even at -O2:

fib(36)             — recursive, exponential call tree
                      no compiler converts this to O(n) automatically

lcgChain(42, 2M)    — serial LCG dependency chain
                      each iteration depends on the previous → no SIMD

nestedMod(800×800)  — nested loop with modulo in the inner loop
                      modulo blocks vectorization

Same algorithm in every language. Same checksum required: 174148737.
If the number doesn't match, the run is invalid.

Compilation flags:

Runtime	How it was compiled
SMS → LLVM IR	`sms_compile` → `clang` (no `-O` flag)
C++	`clang++ -O0`
C# .NET	`Release /p:Optimize=false`
Kotlin JVM	standard `kotlinc` + `java -jar` (JIT active)

C++ and SMS are at exactly the same optimizer level: zero.
Kotlin and C# run with JIT — we note this explicitly in the results.

The Results

7 runs per variant. Median reported.

Runtime	Median (µs)	vs SMS
SMS → LLVM IR `(no optimizer)`	71,358	—
C++ `clang -O0`	85,466	SMS 1.20x faster
C# .NET warm `(JIT)`	96,656	SMS 1.35x faster
Kotlin JVM warm `(JIT)`	64,445	Kotlin 1.11x faster

The checksum matches across all four. The numbers are real.

SMS without any optimizer runs 20% faster than equivalent C++ at the same
optimization level — and 35% faster than C# even with JIT active.

Only Kotlin JVM stays ahead, and it does so with JIT assistance.

Why is SMS Faster Than C++ at -O0?

This surprised us too. Here is the explanation.

When clang compiles C++ at -O0, it is deliberately conservative. Every variable
lives on the stack. Every intermediate value is written and re-read. The IR is
verbose by design — because at -O0, clang trusts the debugger more than
the programmer.

SMS skips the C++ frontend entirely. It generates LLVM IR directly from the AST,
and that IR is already lean. No frontend overhead. No stack-frame conservatism.
The result is cleaner IR that the backend can lower more efficiently — even without
optimization passes.

It is not magic. It is a shorter path.

Event Dispatch: We Measured It. Then We Thought About It.

While we had the stopwatch out, we also measured event dispatch — the mechanism
behind every on btn.clicked() in a Forge app.

We dispatched 100,000 events to a handler (counter = counter + 1; return counter)
through three systems:

Runtime	Per event (ns)	Total 100k
SMS `on bench.tick()` interpreter	7,260	726 ms
C++ `unordered_map` dispatch	266	27 ms
Kotlin JVM `HashMap` dispatch	51	5 ms

At first glance this looks like a problem. 27x slower than C++. 143x slower than Kotlin JVM.

Then we remembered what UI actually is.

A button click arrives roughly every 500 milliseconds if the user is fast.
At 7,260 nanoseconds per dispatch, the SMS event handler finishes 68,000 times
before the next human input arrives.

This is not a performance gap. This is a rounding error on human time.

The real cost of a UI event is not the dispatch. It is the render, the layout pass,
the draw call. The SMS interpreter overhead disappears entirely in that noise.

We are noting it anyway — because honest benchmarks show everything, not just
the numbers that make us look good.

What the Numbers Actually Mean

Let us be precise about what was measured and what was not.

What was measured:

SMS AOT (LLVM IR, no optimizer) vs C++ -O0 vs C#/Kotlin JIT
A compute workload on Apple M2
A synthetic event dispatch loop

What was not measured:

C++ with -O2 — it would win by a large margin, and that is fine
SMS with an optimizer — that does not exist yet
Real UI rendering, startup time, memory footprint

The honest picture:

today:
  SMS (no optimizer)  ████████████  71 ms
  C++ (-O0)           ██████████████  85 ms
  C# (JIT)            ████████████████  97 ms
  Kotlin (JIT)        ███████████  64 ms

with C++ -O2:
  C++ (-O2)           ███  ~8-12 ms   ← would win

SMS with optimizer (not yet):
  SMS (-O2)           ???             ← where this is going

We are not claiming SMS is faster than C++. We are saying:
SMS generates better unoptimized code than C++ generates unoptimized code.
That is a meaningful statement about the quality of the compiler backend.
When an optimizer arrives, it starts from a better baseline.

The Next Step: JIT

There is one scenario where the event dispatch latency does matter:
high-frequency programmatic events — animations, simulation loops, reactive data
bindings firing hundreds of times per second.

For that, SMS already has every building block for JIT:

Piece	Status
Interpreter	✅ `sms_native_session_invoke()`
LLVM IR codegen	✅ `sms_native_codegen_llvm_ir()`
clang as backend	✅ used by `sms_compile`
`dlopen` / `dlsym`	✅ standard POSIX

The missing piece: after a handler fires N times, compile it to a shared library,
dlopen it, swap the function pointer. ~200–300 lines of C++.

After warmup, a JIT-compiled SMS handler would reach native C++ dispatch speeds.
Kotlin JVM would no longer have a structural advantage — it would be an equal.

We are looking for someone to build this.

If you are comfortable with C++17 and dlopen, the architecture is documented,
the benchmark harness is ready, and your name goes into the release notes and
into this article.

→ GitIssues Issue: SMS JIT Dispatcher

Why Forge

Forge is a UI framework built on two ideas:

SML — a declarative markup language for UI layout.

SMS — an event-driven scripting language that compiles to LLVM IR.

No JVM. No CLR. No garbage collector. No runtime to install.
on btn.clicked() is not a callback registered in a framework lifecycle.
It is a first-class language construct that compiles to native code.

We benchmarked it because we want to know the truth about where we stand.
The truth is: we are faster than C++ at the same level, faster than C# JIT,
and one optimizer away from being a serious contender against the full stack.

That is not a marketing claim. That is a measured number with a checksum.

Benchmark code: samples/bench_mac/ in the Forge repository.

Run it yourself: bash samples/bench_mac/run_bench.sh

Forge is open source. Contributions welcome.

Sat Nam. 🌱

Atesti para Dana — The Currency That Starts With Giving, Not Debt

Art — Tue, 14 Apr 2026 21:51:23 +0000

An alternative currency that needs no bank, no blockchain wallet, no government - just three people and a witnessed act of giving.

I have a friend who just lost 10,000 Euro in a DeFi scheme.

Another friend got excited about something called WeFi — "your money works for you," they said. I looked into it. Shell companies in Canada, Costa Rica, Hong Kong. Operators in Dubai. Referral commissions paid only when your downline invests. Classic Ponzi, just with Web3 vocabulary on top.

And meanwhile, this happened to me personally. My Belgian fintech account got frozen - automatically, by an algorithm — because Amazon royalties for my books landed on the same day as my Bürgergeld (social money). Suspicious pattern. No human reviewed it. No answer why. Six months without money.

We keep looking for the next crypto moonshot. And we keep getting burned.

So let me tell you about something different. Something that structurally cannot be used to get rich at someone else's expense.

What is Atesti para Dana?

Atesti - to witness, to attest (Esperanto)
para - through, covered by
Dana - the gift, the act of giving (Sanskrit: दान)

Atesti para Dana is a witnessed gift certificate. It is not a promise. It is not a debt. It is a record of something that already happened.

The sequence is the opposite of normal money:

Normal money: promise first, payment later (always a debt somewhere in the chain)

Atesti: give first, then three witnesses confirm it happened, then a certificate is issued - covered by real work already done.

No one owes anyone anything. The value already exists.

The Three Witnesses

Every Atesti is created through three witnesses:

The giver - who gave something first, without knowing if they get anything back
The receiver - who confirms the gift happened by signing the certificate
The circle - a community that validates, stamps, and issues the certificate

This is Sybil Attack Detection through community and transparency — not through cryptography. You cannot double-spend a witnessed act.

No Company Needed. No Registration. No Office.

Here is what I discovered recently that surprised me:

In Germany, three people who share a common purpose and agree on how to run their community already form what is legally called a nicht eingetragener Verein - an unregistered association. It is regulated in §54 BGB. No notary, no government office, no registration required.

A written manifest - one page, agreed by everyone in the circle — is enough.

And actually: you do not even need that. Rainbow Family has operated for decades without any legal structure. A manifest and a Talking Circle are enough if you are just exchanging within your own community.

The state has no lever on people who cook for each other, build for each other, teach each other, and give each other hand-written certificates for it. As long as no one is coerced, no taxes evaded, no third-party debts created - this is simply free people living together.

Cross-Circle Payments via Hedera Hashgraph

Physical certificates work beautifully within one circle. But what if a member in Wittenberg wants to thank someone in Barcelona?

Here is where technology enters - carefully, minimally.

We use Hedera Hashgraph as a distributed ledger. Not Ethereum, not any chain controlled by a single operator. Hedera is:

Governed by a council of 39 major global organizations (no single point of control)
Finality in 3-5 seconds
Transaction cost: fractions of a cent
No mining, no proof-of-work energy waste

But here is the important part: we store no names, no amounts.

We store only the status of a serial number — open, issued, transferred. That is all. The Hashgraph becomes a public, decentralized notary for the serial number lifecycle.

The Atesti itself stays physical. The community stays human. The Hashgraph just makes it possible for circles across cities, across countries, to verify and transfer without a central bank in the middle.

Why This Cannot Be Used for Ponzi Schemes

Someone asked me: why not just use crypto?

Because every cryptocurrency I know of has a founding team that holds a large supply. Early adopters win. Late adopters subsidize them. That is not a technical bug - it is the design.

Atesti has no pre-mine. No founding team tokens. No referral commissions. No interest. No yield.

You cannot get rich from Atesti. You can only exchange what you have already given.

The three-witness structure makes extraction structurally impossible - not through rules against fraud, but because the architecture offers nothing to extract.

What Can You Actually Pay With It?

Whatever the circle decides. Some examples from our Wittenberg circle:

Massage (60 min)
Haircut
Home-cooked meal
Garden work
Code review
Firewood
A day of help moving house

As the circle grows - when a farmer joins who gives potatoes, when a landlord joins who accepts Atesti for rent, when a carpenter joins who fixes roofs — the range expands. And as the range expands, the amount in circulation grows. Not according to a schedule, not according to population. According to real supply.

That is a sound money principle more elegant than any central bank formula.

Land Lease Against Harvest

One of the oldest models in human history is paying rent not in coins but in produce.

Our vision: find someone with unused land. Ask: can we use it? We grow food. You receive half the harvest. No Euro changes hands. No lease contract needed if trust exists.

Who lives on the land contributes labor. Who contributes labor earns Atesti. Atesti circulates. The circle becomes more self-sufficient with every season.

At some point: supermarket less. Fuel tax less. Income tax less — because there is less taxable income, only shared abundance.

This is not utopia. This is arithmetic.

The Manifest

Our circle runs by consent, not by majority. Decisions in a Talking Circle. Facilitation by whoever knows how. No chairman. No casting vote.

The manifest is one document that everyone agrees to. It describes:

What Atesti is and how it is issued
The three-witness principle
The serial number system
The member wall (what each person offers)
How the circle makes decisions

That is enough. No government needs to approve it. No notary needs to stamp it. Three people with a shared intention and one signed page — and the circle exists.

The Website

We have a live website: atesti.crowdware.info

It runs on ForgeCMS - a Go-based CMS, multi-site from a single binary, content stored as Markdown on Codeberg. No WordPress, no SaaS dependency, no monthly fee beyond 1 Euro/month VPS.

The code is open. The concept is open. The first physical Atesti certificates are printed - serial series 001.

And the first recipients are already clear:

Peter - for 365 days of shared housing, given freely.

Ralph Boes - for 12 years of fighting Hartz 4 sanctions up to 100%, all the way to the Federal Constitutional Court. Hundreds of people kept their dignity because of him. His Atesti will carry their signatures.

Steffi - his secretary, who stood beside that fight every day.

The paper exists. The witnesses exist. The giving already happened. We are just catching up with the paperwork.

Technology should follow demonstrated community need - not the other way around.

An Honest Note

This is early. The Wittenberg circle is small. The Hashgraph integration is planned, not yet live. The member wall is an idea, not yet a product.

But the first Atesti were issued for a real bicycle gift and a year of shared housing. That already happened. That cannot be undone.

And I also studied Web and Graphics Design - but I am too lazy to write CSS. The site is intentionally basic.

What This Could Mean for Open Source

Here is something that has been bothering me for years.

The world runs on open source software. Your server runs Linux. Your app uses libraries written by people who got nothing for it. Your framework was built by someone in their evenings, for free, because they cared.

And then that person burns out. Or gets a corporate job and stops maintaining. Or simply disappears - because there was no feedback loop, no acknowledgment, no flow of gratitude back.

GitHub stars do not pay rent. "Thank you" tweets do not buy groceries.

But what if a circle could witness a developer's contribution?

Imagine: a community that uses an open source tool decides to issue Atesti for the developer's work. Not retroactively calculating hours - that would be impossible. Just: a witnessed acknowledgment that this person gave something real, and the community received it.

The developer holds the certificate. Not money. Not a promise. A witnessed record of contribution.

And then — as the circle grows, as Atesti circulates, as more people join who offer real goods and services - at some point something flows back. A meal. A place to stay. A week of free accommodation in someone's home. Help moving. Garden produce.

Slowly, the developer becomes part of a network that supports them — not because they invoiced anyone, but because they gave first and the community remembered.

This is not a salary. It is not a bounty. It is something older and more human: gratitude made tangible and transferable.

And it scales the right way. The more useful the software, the more circles use it, the more Atesti flow toward the developer. No VC involved. No platform taking 30%. No token that needs to be listed on an exchange.

Just witnessed giving - in both directions.

Open source has always been gift economy in practice. Atesti gives it a memory.

One Question Before You Read On

Stop for a moment.

Who in your life has given something - time, energy, care, knowledge - that you never properly acknowledged?

A developer whose library you use every day. A neighbor who helped you move. A friend who listened for hours. A stranger who changed your direction with one sentence.

That person deserves an Atesti.

Not money. Not a LinkedIn recommendation. A witnessed record that says: you gave, I received, and this community knows it.

That is where this starts. Not with technology. Not with a manifest. With one name that just came to your mind.

Put it in the comments. And write it on paper.

Two witnesses already: you, and everyone reading this.

If This Resonates

You do not need to join our circle. Start your own. Three people, one manifest, one serial number range, and the willingness to give first.

The world does not need another token. It needs people who give before they ask.

Aho 🌱

Olaf Japp - independent developer, founder of CrowdWare, Lutherstadt Wittenberg.
All code at: https://codeberg.org/CrowdWare
Atesti: https://atesti.crowdware.info

// Tu keinem Lebewesen Leid an
// Do not harm living beings
// Ne damaĝu vivantajn estaĵojn

Hot Reload + Native Speed - Why I Built My Own Language for Android (and Desktop)

Art — Thu, 09 Apr 2026 11:44:40 +0000

Sometimes development gives you a perfect timing moment.

I had just tagged and pushed a release... and exactly in that moment the
system told me I had reached the usage limit. Right after the push. Not
before.

That screenshot felt like a small 🎯 bullseye moment.

But the interesting part is not the timing.

The interesting part is the technology behind the project.

A different idea of Android development

In my current project I am experimenting with a scripting language
called SMS (Simple Multiplatform Script).

The idea is simple:

Build a language that feels like scripting, but runs native.

Native compilation

Normally the code is compiled through LLVM IR.

That means the result runs native on Android, not inside a VM.

So compared to many typical setups:

no virtual machine
no visible memory management
no manual malloc / free
no garbage collector

LLVM handles the low level details under the hood.

From the developer perspective it feels like writing a script.

Runtime Code via HTTP

Another interesting aspect is how dynamic code is handled.

When code is shipped with the application, it is compiled to native code via LLVM.

However, code that is loaded dynamically via HTTP is executed inside a sandbox and interpreted at runtime.

This makes it possible to extend or modify application behavior without rebuilding the app.

Hot reload during development is just one side effect of this architecture.
The same mechanism can also run safely in production.

Type inference instead of declarations

Another design choice:

The user does not need to declare types.

Types are inferred automatically when values are assigned.

Example idea:

var number = 42
var pi = 3.14

value → type is derived automatically.

So the language keeps the simplicity of scripting while still
producing native code.

Hot Reload via Interpreter

But there is another layer that makes things interesting.

When code is loaded dynamically over HTTP, it is not compiled first.

Instead it is interpreted immediately.

That enables Hot Reload.

Which means:

You can push new code and the running Android app updates its behavior
instantly.

No rebuild.

No reinstall.

Why combine both approaches?

Because each approach has advantages.

Compiled mode

maximum performance
native execution
optimized code

Interpreter mode

dynamic updates
hot reload
instant experimentation

Combining both gives a workflow that feels extremely powerful.

Error feedback - Amiga 500 style

When SMS code fails, the app does not crash silently.

It tells you exactly what went wrong.

If you grew up with an Amiga - you know this feeling.

Except this time the error message is actually useful and you can continue - without scripts running.

The result

An Android development environment that feels like this:

scripting speed
native performance
dynamic updates
simple syntax

For me personally, this feels like a very interesting direction for future tooling.

The bigger idea

This language is also part of a broader ecosystem:

SML (Simple Multiplatform Language) for UI and structure inspired by QML from Qt, but without the expressions.
SMS a Kotlin like language for logic
Forge4D Multiplatform Dev Environment based on Godot 4.6

The goal is simple:

Make software development more accessible, without sacrificing
performance.

Current capabilities

At the moment the runtime already provides several building blocks.

UI elements are described with SML (Simple Multiplatform Language).

This currently includes:

dialogs
standard controls
layout structures

Content can also be rendered using Markdown, which makes it easy to build documentation (like in the web stack), books or content-driven apps.

On top of that the runtime exposes a 3D scene powered by the
Godot 4.6 engine.

This allows loading and animating .glb models directly inside the app.

So the platform can already combine:

structured UI (SML)
rich text content (Markdown)
interactive 3D scenes (SML, GLB)

And yes... the release timing was perfect 😄

Sometimes the universe just gives you a small developer joke.

Push release → success → usage limit reached.
(So even the Claude abo for just 20,- € helped)

Perfect timing.

From IONOS Rage-Quit to Self-Hosted Freedom: How a 120 Euro Bill Improved ForgeCMS

Art — Wed, 08 Apr 2026 22:02:37 +0000

The bill that started it all

IONOS sent me a 120 Euro invoice. Two domains at 42 Euro each - way more than I originally paid for them. Plus some positions I was sure I had cancelled months ago. I paid what I could. They locked every server on my account. No warning. No partial restore. Everything gone overnight.

I cancelled all contracts the next day. They pulled the servers immediately - even though the contracts had months left to run. No grace period. Clean cut.

The support offered me a backup for 70,- EUR...

FU was my answer ;-)

When a provider holds your infrastructure hostage over a billing dispute, you don't negotiate. You migrate.

Green field

I had been planning to self-host on my own 1 Euro VPS using ForgeCMS anyway. The plan was just... not today. IONOS made the decision for me.

This forced exactly the feature I had been postponing: multi-site hosting from a single ForgeCMS binary.

What we built

One Go binary, multiple domains

ForgeCMS is a single Go executable. It receives incoming HTTP requests and routes them to the correct site based on the domain. No virtual machines, no containers, no orchestration layer.

Currently hosting two sites from one process:

crowdware.info
atesti.crowdware.info

Caddy sits in front as the TLS reverse proxy. That is the entire stack.

Browser -> Caddy (TLS) -> ForgeCMS binary -> Codeberg (page content)

One of the VPS instances also runs our own Postfix mail server. No Google, no Microsoft, no third-party email provider. Full stack independence for 2 Euro per month.

Content lives in Git, not in a database

All page content - written in SML and Markdown - lives in a Codeberg repository. ForgeCMS fetches files from the repo at request time and caches them locally. No build step, no static site generation, no database.

The app.sml config for each domain looks like this:

App {
    name:     "Atesti para Dana"
    base_url: "https://atesti.crowdware.info"
    lang:     "de"

    Site {
        host:   "codeberg.org"
        user:   "CrowdWare"
        repo:   "sites"
        branch: "main"
        path:   "atesti"
    }

    Languages {
        default:   "de"
        supported: "de en es ca eo"
    }

    Menu {
        Item { label: "Home"      href: "/"          }
        Item { label: "Impressum" href: "/impressum" }
    }

    Routing {
        Route { path: "/"           page: "index.sml"     }
        Route { path: "/impressum"  page: "impressum.sml" }
        Route { path: "/404"        page: "404.sml"       }
    }
}

Each domain gets its own folder under config/ in the repo. ForgeCMS reads all of them on startup.

Staging via a second 1 Euro VPS

The staging workflow is dead simple: a second 1 Euro server running the identical setup. Deploy the new version there, test it, then flip the DNS A record. ForgeCMS and Caddy do not need to know anything about staging - it is purely a DNS switch.

# Deploy to staging
./deploy.sh 5.6.7.8

# Verify via /etc/hosts override locally:
# 5.6.7.8  atesti.crowdware.info

# Go live: update DNS A record to 5.6.7.8

The deploy script is fully idempotent - run it again and it installs Caddy, uploads the binary, syncs configs, and starts the systemd service. First deploy or tenth deploy, same command.

New UI components

While we were in there, we added Bootstrap-based components that had been on the list:

Image sliders for visual content sections
Project cards for listing work and initiatives

Both are driven from Markdown content in the repo - no hardcoded HTML in the binary.

i18n built in

The atesti site serves five languages: German (default), English, Spanish, Catalan, Esperanto. ForgeCMS tries the language-specific file first and falls back to the default.

atesti/
  index.sml        - default (de)
  main.md
  en/
    main.md
  es/
    main.md
  ca/
    main.md
  eo/
    main.md

The architecture in one line

All content is Markdown and SML in a Codeberg repo. One Go binary serves everything. Caddy handles TLS. Total infrastructure cost: 2 Euro per month.

What comes next: load balancer for 1 Euro more

The IP-swap staging approach works but a load balancer in front would make zero-downtime deploys cleaner and faster.

The plan: the second VPS currently runs Postfix for mail tied to the our domains. That Postfix server becomes the load balancer. Total infrastructure cost at that point: 3 Euro per month.

Reference implementation

The full repository structure - configs, deploy script, content layout, and README - is public:

codeberg.org/CrowdWare/sites

If you want to run your own ForgeCMS installation, that repo is the reference. The deploy script handles everything from a bare VPS to a running multi-site setup in one command.

ForgeCMS itself: codeberg.org/CrowdWare/ForgeCMS

Part of the CrowdWare open source ecosystem. Built with Go.

P.S. - The two 1 Euro VPS servers running all of this? Also IONOS. Setup fee for the second one was 10 Euro, then 1 Euro per month. The old hosting contract was 11 Euro per month alone. ROI: month one.

The Benchmark Was a Lie (In Our Favor)

Art — Wed, 08 Apr 2026 03:43:03 +0000

Follow-up to: "A Language Was Born Today: SMS Went Native"

Nobody told me that I cannot build a compiler without a diploma. So I just did it.

And then Claude asked the right question:

"Did you compile everything?"

No. We didn't.

One Language. Two Modes. Zero Rewrites.

This is the part that still makes me smile.

on button.clicked()
    log.success("same code")
    log.success("interpreter or compiler")
    log.success("you decide at deploy time")

That code does not know if it is being compiled or interpreted. You decide at deploy time. No rewrites. No porting. No type declarations. No ceremony.

The language does not care. That is the point.

Most languages force a choice early: scripting or compiled. Dynamic or static. Fast or flexible. SMS says: why choose?

No type declarations. The compiler infers the type from the first assignment. Write like a human thinks. The compiler does the rest.

var name = "Olaf"
var age = 42
var pi = 3.14

What We Missed

When SMS hit 1.26x faster than C# on March 24, these parts were still running through the interpreter:

All event handlers
All library calls (OS, AI, and others)

Half the compiler wasn't even running. And we were still faster.

The Event Syntax Nobody Asked For (But Everyone Needed)

Here is how you connect UI to behavior in Forge:

Button {id: myButton}    // SML - declare the thing

on myButton.clicked() {  // SMS - react to it
    doSomething()
}

The ID from SML becomes the event target in SMS. No binding layer. No ViewModel. No findViewById().

Compare that to the Kotlin way:

<!-- XML -->
<Button android:id="@+id/myButton" />

// Kotlin
val myButton = findViewById<Button>(R.id.myButton)
myButton.setOnClickListener {
    // ...
}

Two languages, one thought. That is the design.

The Dispatcher Is Dead

You know this code. You have written this code. You hate this code:

when (item.itemId) {
    R.id.menu_file    -> openFile()
    R.id.menu_edit    -> openEdit()
    R.id.menu_help    -> openHelp()
    // ... 117 more lines of this
}

In SMS:

on menuFile.clicked() {
    openFile()
}

on menuEdit.clicked() {
    openEdit()
}

on menuHelp.clicked() {
    openHelp()
}

120 menu items. Zero switch statements. Zero when-blocks. Zero dispatchers.

Every event lives exactly where it belongs. Open the file in 6 months and you still know what happens. That is not clever engineering. That is FSS.

FSS: Fucking Stupid Simple to read. Simple to write. Simple to maintain.

We did not aim for KISS. We ended up with FSS.

What "Fully AOT" Means Now

After fixing what we missed, the compiler now covers:

Event handlers (on widget.event()) - compiled
Library calls (OS, AI, and others) - compiled
User logic - compiled
Remote scripts loaded via HTTP - interpreter fallback, by design

That last point is not a weakness. It is architecture.

Trusted code gets compiled. Untrusted remote content stays sandboxed in the interpreter. One app, both modes, running together.

Think Lua in game engines. Think browser JIT with sandboxed iframes. The hybrid model is a feature.

So What Is the Real Number?

We do not know yet.

The full AOT benchmark - with events and libraries compiled - is next. What we know: 1.26x faster than C# was the floor, not the ceiling.

The first test had:

C# GC pressure: never triggered in the test window
JVM warmup: excluded from measurement
SMS event handlers: still interpreted
SMS library calls: still interpreted

The real gap is larger. We will publish numbers when we have them. Same protocol as before:

5 warmups
20 measured runs
median + p95
no cherry-picking

And we are not too shy to race against C++. Because we don't have malloc or free. No manual memory management muddying the numbers. Just the language doing its job.

Android: It's Already Running

The AOT path targets Android ARM. And it is not "coming soon" - it is running now.

Same compiler. Same simplicity. Same FSS philosophy. Native on Android.

Benchmark numbers are next. Stay tuned.

While We Were At It

APK size: 188 MB down to 95 MB. We dropped 32-bit support. Half the weight, same power.

And one more thing.

There is a comment in the compiler now:

// Do no harm to any living being.

We used to enforce it as syntax. Naive. The app warned us. We listened.

Now it is different. We don't force it. We don't warn about it. But if you put it in your code - the compiler knows. And it rewards you. Quietly.

Good intention reveals itself. We just listen for it.

But Why Android? Why Any of This?

I look at my phone and I know.

They see which games I play. Which books I read. What I type on the keyboard. Every app, every tap, every moment - theoretically visible to someone I never invited.

And every few months: "Please update."

No thanks. I am not inviting a new devil onto my device. The old one is already scanning everything.

My phone gets slower with every update. Touch events stop working because something is running in the background. Ads from GetApps. Bloat I cannot remove. A platform I do not control.

That is the pain. That is why this matters.

Less code. More security. No surveillance tax.

ForgeOS is the answer we are building towards. Mobile first. Free hardware. Open from the ground up. No Google. No App Store gatekeeping. No proprietary runtime watching everything you do.

The compiler is the foundation. FSS all the way down.

Workshop: Wittenberg, LEUCOREA

On Saturday we are running a workshop at LEUCOREA (Collegienstrasse 62, Lutherstadt Wittenberg) on sustainable software development in the age of AI.

One of the topics on the table: should Forge go mobile first?

The circle decides. That is how we work.

If you are a student, a developer, or just someone who is tired of handing your phone to corporations - you are welcome.

"Glaube mir kein Wort. Probier es selber aus."
Don't believe a word I say. Try it yourself.

SMS and SML are part of the Forge ecosystem - a native UI framework built in C++ with its own compiler, its own language, and a stubborn belief that code should read like a sentence.

42 years after Amiga BASIC. Still going. 🤘

Lutherstadt Wittenberg is Reforming Again – This Time It's Software

Art — Mon, 06 Apr 2026 14:17:31 +0000

An invitation to those who think differently.

"Most software today is not built for you. It's built for someone who wants something from you."
"We build differently."

The Eddy Current Principle

Kayakers know: behind every rock in the river, an eddy forms.
A quiet pocket where the water curves back upstream, calm inside the chaos.
Those who know this don't avoid obstacles, they use them to rest, regroup, and move forward.
We build software the same way.

The Obstacles We Use

Gradle pulls in hundreds of libraries, nobody knows what they all do.

WordPress installs updates with Google Analytics quietly bundled in.

Windows is always watching.

App Stores take 30%, for nothing.

These aren't problems to route around.

They're rocks. And behind every rock is an eddy.

What We're Building

An operating system that can be trusted.

No package manager apps delivered via HTTP, running natively, cached locally
No corporation - fully Open Source, anyone can host it
No hidden dependencies - AI-assisted code reviews as a trust layer
No middleman taking a cut - Bitcoin Lightning micropayments flow directly to developers - Stack: SML/SMS for UI, Go for services, Linux kernel as foundation

Anyone who compiles themselves pays nothing.

Those who use the distribution let Satoshis flow, including backwards, to everyone who ever contributed.

Even Linus Torvalds gets a share for the kernel.

Who We're Looking For

Not finished developers.

People who are curious.

Who prefer understanding over consuming.

Who find an idea more important than a CV.

All disciplines welcome:

C++, Go, Design, Philosophy, Journalism, Law, whatever you bring.

How It Works – Three Circles

Local – Wittenberg Saturdays

Full day, €80 per person. Room costs covered from just 2 participants.

Hands-on, in person, real coffee.
I show you my way of doing things efficiently using AI - and Ahimsa, Gandhi's principle of do no harm, as the ethical foundation beneath every line of code we write.

Regional – Day Trip

Berlin and Leipzig are 1–2 hours by train.

Come for the Saturday, go home the same evening.

Global – X Spaces / Online

Free or small ticket via X.

Africa, Russia, Americas, Asia – wherever you are.

The global circle feeds the local one.

How It Begins

We don't wait for perfect conditions.

Two people signing up is enough – the circle begins.

In the first circle we decide together: Where do we meet? When? What do we build first?

From there the circle grows to seven. The project name gets chosen. First steps get defined.

The circle can grow to thirteen – larger spaces available in Wittenberg as needed.

Those who stay longer become mentors, running their own circles.

No big deal – it's about passing on tools.

Once it was Google and Stack Overflow. Today it's AI.

The principle stays the same: learn to find solutions, not memorize them.

Coding in the background is helpful – but no longer mandatory.

The AI handles the code. We handle the thinking.

Why Wittenberg?

In 1517, Martin Luther changed the frame here.

He didn't fight the system – he changed the frame.

That's second-order thinking.

That's what we do.

Recognition

Every contribution gets an Atesti para Dana –

a physical certificate of participation, signed by witnesses.

Not money. Memory. Frameable, collectible, tradeable like art.

In twenty years, an Atesti saying "I helped build this OS"

might be worth more than you think.

Interested? Get in touch.

CrowdWare - Lutherstadt Wittenberg, Germany

Codeberg: codeberg.org/crowdware

Aho 🌱

I Built a Tool That Translates Meaning — Not Words

Art — Fri, 03 Apr 2026 12:58:39 +0000

A call for testers, native speakers, and developers who want to help preserve languages before they disappear.

It Started With an Ice Cream

I walked barefoot through Denmark in short trousers, bought an ice cream cone, and wrote about it.

Then I ran it through SOUL.

A few seconds later I had the same story in Spanish, Portuguese, Catalan and Low German. Plattdeutsch. A language I barely speak anymore. Words I hadn't heard in decades. But when I read them aloud, they came back. The sound unlocked something.

That's when I knew this was working.

What SOUL Actually Does

Most translation tools work at the word level.

Word in → word out.

SOUL works at the concept level.

Before any translation happens, SOUL builds a dictionary of meanings, not words. Each concept gets its own entry:

Concept {
  id: "longing-de"
  note: "Sehnsucht — transcendent longing. No English equivalent."
  dynamic: piano
  tempo: largo
  de: "Sehnsucht"
  es: "añoranza"
  ca: "enyorança"
  en: "Sehnsucht"
  nds: "Sehnsucht"
  pt: "saudade"
}

Notice: English keeps Sehnsucht, because there is no English word.

SOUL doesn't flatten the gap. It marks it.

A reader knows they're touching something their language cannot fully hold.

The Pipeline, Grok Does the Heavy Lifting Once

Here's what happens under the hood:

You write Markdown (your language)
  → soul encode
    → Grok API (automatic, one call)
      → extracts concepts, not just words
      → fills the dictionary per language
        → soul render -l es  → Spanish
        → soul render -l ca  → Catalan
        → soul render -l nds → Low German
        → soul render -l pt  → Portuguese

Grok runs once per concept.

After that, no AI needed. Ever.

Pure deterministic rendering. Offline. Forever.

One dictionary entry, curated once by a native speaker —

and every future book that uses that concept gets it right automatically.

The system grows without the system growing.

Why This Matters Beyond Tech

Have you ever thought about obrigado?

In Portuguese it means "thank you."

It also literally means: I am obligated.

Every time a child says thank you in Portuguese —

they practice owing something.

Nobody planned this. It's just what was handed down.

In German, Verantwortung means moral accountability,

you chose this, you must answer for it.

In English, responsibility can mean the same thing,

or just a job description. Nobody's fault. Just assigned.

One word where German has two.

A whole dimension of moral weight quietly lost in translation.

These aren't curiosities.

They're the invisible architecture of how we think.

SOUL preserves the architecture.

What Cannot Be Burned

Franco banned Catalan. Books were burned.

Wilhelm Reich's work was burned, in the United States, in the 1950s.

Professor Bernd Senf spent decades carefully reconstructing what was lost.

When the soul of a book lives in SOUL format on IPFS,

you can delete an incarnation.

You cannot delete the meaning.

A .soul file is plain 7-bit ASCII.

Readable since 1963.

It carries its own specification, a time capsule.

In 50 years, someone opens this repo.

No CrowdWare. No cloud. No permission needed.

They read the spec. They reconstruct every language version.

The meaning survived.

Low German is fading.

42 languages in Guatemala are endangered.

Catalan remembers what suppression feels like.

SOUL gives every language a reason to exist and a way to survive.

CrowdBooks — Anyone Can Publish

SOUL connects directly to CrowdBooks, a decentralized book platform on IPFS.

You speak → Whisper → Text → SOUL → IPFS
Reader opens → SOUL from IPFS → their language → Bookreader

Anyone can write a book.

Anyone can encode it into SOUL.

Anyone can add a language, just add a translation table.

The Bookreader needs no update.

Publish in German today.

Add Spanish next month when a native speaker curates the dictionary.

Add Hebrew when someone who reads it tells us the concepts are right.

Every language that gets a dictionary becomes a language this book can speak.

What I'm Looking For

This is the call.

Testers — clone the repo, run the example texts, tell me where the translation feels wrong. The ice cream story is there. The Danish barefoot walk. Read it in your language and tell me what's missing.

Native speakers, especially Low German, Catalan, Mam, Kaqchikel, Portuguese. Every concept in the dictionary was placed by software. It needs human eyes. Your eyes. One correction from a native speaker is worth more than a thousand AI iterations.

Linguists, the concept model is young and surely wrong in ways I cannot see. Words like hygge, saudade, Weltanschauung, ubuntu, concepts that carry entire worldviews, need careful handling. Tell me what I'm missing.

Developers — Go, SML, IPFS. Small stack. Clean. Documented. Clone it, build it, break it. PRs welcome on Codeberg.

The Bigger Picture

I'm not doing this for money.

I'm doing it because I can and because it needs doing.

Somewhere between Socrates asking questions in Athens,

Gandhi refusing to participate in a system that needed everyone's compliance,

and an elder in Guatemala speaking Mam to a child, there is a thread.

The thread is this:

meaning matters more than the vessel it travels in.

SOUL is just a vessel.

A very careful one.

Try It

git clone https://codeberg.org/CrowdWare/soul-go
cd soul-go
# see README for setup
soul encode -l de example/eiswaffel.md
soul render -l es example/eiswaffel.soul
soul render -l nds example/eiswaffel.soul

Read the Low German version aloud.

See what comes back.

Repo: codeberg.org/CrowdWare/soul-go
CrowdBooks: crowdbooks.crowdware.info
License: GPL-3.0-or-later

CrowdWare — Lutherstadt Wittenberg — 2026

Cause no harm to any living being.