DEV Community: Art

Why SML/SMS doesn't run on Windows - and why that's a feature

Art — Mon, 11 May 2026 17:31:46 +0000

Let me tell you a story.

I was leading a raid in World of Warcraft. 24 people. Everyone waiting on me. And Windows decided that exact moment was the perfect time for an update. No warning. No mercy. Just a reboot.

I switched to Mac the next day.

For years it was great. Steve Jobs understood something most tech CEOs never will: the user is not the product. The user is the guest. You treat guests with respect.

Then Steve left us.

And slowly - update by update, policy by policy - Apple became just another corporation. A beautiful one. But one that now decides what software you can run, what hardware you can repair, and what belongs to you and what belongs to them.

So here we are.

We are building SMS - a programming language that compiles to native binaries via LLVM. Open source. GPL-3. No telemetry. No stakeholders. No investors.

It runs on Mac and Linux. Not on Windows - and that is not an oversight. That is a choice.

Because we are not building for a world where your OS reboots your raid.
We are not building for a world where a corporation decides what runs on your machine.
We are building for the world we actually want to live in.

Ahimsa. Do no harm. Not even to your users.

If you are on Windows and want to try SMS - WSL2 works fine. One small rebellion inside the machine.

But if you are tired of building software on platforms that belong to someone else - come build with us.

SMS is free. Linux is free. Your time is not.

https://codeberg.org/CrowdWare/sms-cpp

ForgeOS Dojo - learn AI-assisted development, build something that matters

Art — Mon, 11 May 2026 17:08:06 +0000

"No Stakeholders. No Investors. Just Users."

In 28 days we built a new programming language from scratch.
Today it compiles itself.

Now we want to go further - together.

We are opening the ForgeOS Dojo: a learning community where you will master AI-assisted software architecture while building something real.

Not a todo app. Not another CRUD API.

An entire mobile OS. Free. No ads. No forced updates. No spyware.

You will learn:

How to work with AI as your architect (Claude) and your coder (Codex)
Sustainable software design - less code, more intention
SMS - our scripting language that now compiles itself to native binaries
How to ship real software that respects its users

What we build together:

ForgeOS - a mobile OS built on SMS and C++
Ahimsa as the single constitutional principle: do no harm - not even to your users

No prior OS experience needed. Just curiosity and the will to build something that matters.

If you are tired of building software for companies that spy on their users - this is your Dojo.

Drop a comment or follow CrowdWare on Codeberg:
https://codeberg.org/CrowdWare

We Wrote a Compiler in the Language It Compiles. It Works.

Art — Mon, 11 May 2026 16:49:00 +0000

Four sprints. One afternoon. 62 tests, all green.

ForgeIL is the compiler layer of Forge - an open source UI framework built around
a radical simplicity: one language, one binary, no runtime installation.

The Idea

There is a test every language eventually faces. Not a benchmark. Not a syntax
comparison. A question:

Can the language compile itself?

A self-hosted compiler is the closest thing software has to a proof of maturity.
If the language can express a lexer, a parser, and a code generator - and the
result of running that code is a working binary - then the language has crossed
a threshold. It is no longer a demo. It is a tool.

SMS is the scripting language at the heart of Forge. It is interpreted at
development time and compiled to LLVM IR at release time. We decided to test
whether SMS could implement its own compiler front-end: a lexer, a parser, and
an LLVM IR emitter - all written in SMS itself.

Four sprints. One afternoon. It works.

What We Built

The self-hosted compiler lives in the forgeil/ directory of
sms-cpp - three SMS source files that
together form a complete compilation pipeline:

SMS Source
    |
    v
tokenize(src)        sprint1-lexer.sms     ->  array of Token
    |
    v
parse(tokens)        sprint2-parser.sms    ->  AST of Node
    |
    v
codegen(ast)         sprint3-codegen.sms   ->  LLVM IR text
    |
    v
clang                                      ->  native binary

A single convenience function wraps it all:

fun compile(src) {
    return codegen(parse(tokenize(src)))
}

That is the entire public API. Give it SMS source text. Get back LLVM IR.

Sprint 1: Lexer

The lexer turned out to be the place where SMS's integer-character API became
a design constraint rather than a limitation. str.charAt(i) returns the
integer char code of the character at position i. So the entire lexer is
built on integer comparisons - no regex, no character class library.

fun isAlpha(code) {
    return (code >= 65 && code <= 90) || (code >= 97 && code <= 122) || code == 95
}

fun isDigit(code) {
    return code >= 48 && code <= 57
}

Two-character operators (==, !=, <=, >=, &&, ||) are handled with
a single lookahead:

if (ch == 61) {  // '='
    if (i + 1 < len && src.charAt(i + 1) == 61) {
        tokens.add(Token("OP", "==", line))
        i = i + 2
    } else {
        tokens.add(Token("ASSIGN", "=", line))
        i = i + 1
    }
}

The result: tokenize(src) returns an array of Token(type, value, line) data
class instances. 12 tests, all green on the first run.

Sprint 2: Parser

A recursive descent parser, written in SMS, for SMS.

The interesting constraint here: SMS does not allow forward declarations. Every
function must be defined before it is called - except at the top level, where
all definitions are registered before main() runs. So mutual recursion between
parseExpr and parseStmt works perfectly, because both are defined at the
module level before any call site is reached.

The precedence chain follows the standard pattern:

parsePrimary -> parsePostfix -> parseUnary -> parseMul ->
parseAdd -> parseCompare -> parseEquality -> parseAnd -> parseOr -> parseExpr

One non-obvious detail: the parser cursor is a single-element array used as a
mutable integer box. SMS arrays are passed by shared reference - field
assignments inside helper functions are visible to the caller. This is how the
cursor advances across the recursive descent without needing a global variable.

fun curTok(cur, tokens) { return tokens[cur[0]] }
fun advance(cur)         { cur[0] = cur[0] + 1 }
fun consume(cur, tokens, expected) {
    var tok = curTok(cur, tokens)
    if (tok.type != expected) { ... }
    advance(cur)
    return tok
}

24 tests. All green.

Sprint 3: LLVM IR Emitter

The code generator takes an AST and produces a complete LLVM IR text string.
Integer-only subset: every SMS value is i64, variables use alloca (memory-form
SSA), and clang/llc applies mem2reg in the optimization pipeline.

The context object accumulates emitted instructions:

data class Ctx(tempCnt, labelCnt, code, terminated, loops)

Because SMS data class instances use shared references (shared_ptr under the
hood), every helper function that mutates ctx.code or ctx.tempCnt has its
changes visible to every other function holding the same ctx. This is the
foundation of the entire emitter design.

A comparison compiles to an icmp followed by a zext - because LLVM
comparisons produce i1 and SMS uses i64 everywhere:

if (op == "<") { emit(ctx, cmpReg $ " = icmp slt i64 " $ left $ ", " $ right) }
emit(ctx, reg $ " = zext i1 " $ cmpReg $ " to i64")

For a function like fun add(a, b) { return a + b }, the emitter produces:

define i64 @sms_add(i64 %_p_a, i64 %_p_b) {
entry:
    %a = alloca i64
    store i64 %_p_a, i64* %a
    %b = alloca i64
    store i64 %_p_b, i64* %b
    %t0 = load i64, i64* %a
    %t1 = load i64, i64* %b
    %t2 = add  i64 %t0, %t1
    ret i64 %t2
}

If the source contains a fun main(), a C-compatible entry point is appended:

define i32 @main() {
entry:
    %ret64 = call i64 @sms_main()
    %ret32 = trunc i64 %ret64 to i32
    ret i32 %ret32
}

19 tests. All green.

Sprint 4: End-to-End

The final sprint is the proof. A new C API function -
sms_native_execute_string_result - captures the string value produced by the
SMS interpreter, instead of the integer it previously returned. This lets the
host application receive the generated IR text directly.

The test then does exactly what you would do on the command line:

// 1. Run the SMS compiler in the interpreter, capture the IR string
std::string ir = get_ir(load_all(), "fun main() { return 42 }");

// 2. Write to a temp .ll file
// 3. Run: clang -O0 -o /tmp/test_bin /tmp/test.ll
// 4. Run the binary, check exit code == 42

Exit code 42. Not chosen at random. The compiler's first words are a nod to
the only question that ever mattered.

forgeil_sprint4_tests: all tests passed (7)

The pipeline holds for arithmetic, if/else branches, and while loops. The tests
skip gracefully when clang is not available, so they run cleanly in any CI
environment.

What the Numbers Look Like

Sprint 1 - Lexer        12 tests  v
Sprint 2 - Parser       24 tests  v
Sprint 3 - Code gen     19 tests  v
Sprint 4 - Self-host     7 tests  v
---------------------------------
Total                   62 tests  all green

What This Is Not

SMS is not trying to replace LLVM's front-end infrastructure. The self-hosted
compiler covers the integer-only subset of the language: functions, variables,
if/else, while, break/continue, arithmetic, and comparisons. Strings, arrays,
data classes, and the standard library are outside its current scope.

The point is not feature completeness. The point is that the language has
enough expressive power to reason about itself. That is a different claim - and
a meaningful one.

The Code

Everything is open source under GPL-3.0 (with a commercial option):

sms-cpp: codeberg.org/CrowdWare/sms-cpp
Lexer: forgeil/sprint1-lexer.sms
Parser: forgeil/sprint2-parser.sms
Code gen: forgeil/sprint3-codegen.sms
Tests: tests/forgeil_sprint{1..4}_tests.cpp

If you want to try it:

git clone https://codeberg.org/CrowdWare/sms-cpp.git
git clone https://codeberg.org/CrowdWare/sml-cpp.git
cmake -B build -DBUILD_TESTING=ON -DSML_CPP_DIR=../sml-cpp
cmake --build build
cd build && ctest -R forgeil --output-on-failure

*Forge is being built in public at crowdware.info.
SMS, ForgeIL, and the self-hosted compiler are part of a longer project:
a UI framework that runs anywhere without asking anything of the user's machine.

ListenCircle: A Digital Talking Circle for Real Human Connection

Art — Wed, 22 Apr 2026 19:13:27 +0000

We built ListenCircle to bring the ancient practice of the Talking Circle into the digital world.

It’s a space where every human being can speak and be heard — regardless of where they come from or what they believe.

No accounts. No logins. No stored identities. Just real people, listening.

🌿 What is a Talking Circle?

A Talking Circle is an ancient form of conversation:

People sit in a circle.

Whoever speaks holds the Talking Stick.

The others listen — without interrupting.

When the speaker is done, the stick passes to the next person.

ListenCircle brings this practice into the digital age — for Rainbow Gatherings, community meetings, and anywhere people want to truly listen.

⚙️ How it works

Creating a circle

Choose a language
Set a topic (or keep it open)
Decide:
- Open Circle — anyone can join
- Closed Circle — invite only
Limit participants (default: 13)

Joining a circle

Open circles appear in the lobby
Join instantly — no account needed
New participants must listen through one full round before speaking

🪶 The Talking Stick

Hold button → speak (push-to-talk)
Release → stick moves to next person
Strict order — no interruptions
Max speaking time: 3 minutes

💛 Reactions

While someone speaks, others can respond with:

🌿 Aho
♥ Thanks

The speaker sees them live.

🔐 Privacy by design

No accounts
No stored identities
No IP tracking
No persistent data

Audio runs peer-to-peer (WebRTC) — never through a server.

🏗️ Architecture

Go backend for real-time logic
WebSockets for signaling
WebRTC for direct audio
ForgeCMS for rendering UI via SML

Separation of concerns:

Backend = logic
CMS = UI

🛡️ Abuse protection (without logins)

Session tokens (not IP-based)
Rate limiting
Join throttling
Speaking timeout
Stick timing rules

All without breaking anonymity.

🚀 Why this matters

Most online communication is:

chaotic
interrupt-driven
attention-seeking

ListenCircle creates something different:

one voice at a time
real listening
no identity games

It’s not just a tool.

It’s a different culture of communication.

🔗 Open Source

👉 https://codeberg.org/CrowdWare/ListenCircle

🌱 Final thought

What happens when people are truly heard?

That’s what ListenCircle is exploring.

Status

It's not yet ready...we just started it today, but I just wanted to start a discussion and you may add feature requests. Just think about the outcome. Are we able to stop wars this way?

Btw...it's free and open source...host your own server on a 1,- EUR VPS.

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.