Coder Legion - Recent posts tagged language

Writing a Programming Language & Native x86-64 Compiler from Scratch in C: The Story of Yolish

Sun, 27 Sep 2026 03:56:49 +0000

Every programmer has, at some point, looked at their favorite programming language and thought:

“Why was it designed this way? How hard can it actually be to build one myself?”

Most developers who explore language design stop at simple arithmetic evaluators or toy interpreters. But when I was building Exploidus OS—a custom x86-64 reactive capability operating system—I ran into a fundamental architectural barrier:

Standard systems languages (like C) have zero concept of operating-system capability tokens. In C, if you have a pointer, you can dereference it. If you have an address space, any line of code can call any syscall unless restricted by complex external sandboxes.

I wanted a modern, expressive language that felt as ergonomic as Python or Rust, but was deeply capability-aware at the syntax level—able to compile directly to bare-metal x86-64 binaries without pulling in gigabytes of LLVM dependencies.

That ambition gave birth to Yolish—a fast, expressive, capability-aware programming language with a tree-walking interpreter, a bytecode virtual machine, and a direct x86-64 native compiler.

Here is how I designed Yolish, wrote its compiler from scratch in pure C, and what I learned building a complete language ecosystem.

1. Language Design: Ergonomics Meets Systems Control

When designing Yolish's syntax (.y), I wanted code to read cleanly without syntactic noise, while enforcing defensive systems programming invariants.

Immutability by Default

Variables in Yolish default to immutable constants using let, while mutable state must be explicitly declared using var:

let name  = "Yolish"   -- immutable constant
var count = 0          -- mutable state
count = count + 1

Pattern Matching with Ranges & Guards

Instead of archaic C-style switch statements with fallthrough bugs, Yolish features expressive pattern matching:

let grade = match score {
    90..100      => "A"
    80..90       => "B"
    n if n >= 60 => "C"
    _            => "F"
}

Structs and `impl` Blocks

Yolish rejects complex class hierarchies in favor of data-first structs and explicit method implementations:

struct Circle { radius }

impl Circle {
    fn area(self) {
        return y.math.pi * self.radius * self.radius
    }
}

let c = Circle { radius: 5 }
y.println(c.area())

2. Bridging Code to the Kernel: First-Class Capabilities

Because Yolish is the official userspace language for Exploidus OS, security cannot be an afterthought.

In Yolish, dangerous operations (network access, raw disk writes, peripheral I/O) are gated by declarative capability annotations:

@cap(net.read, fs.write)
fn sync_data(url, filepath) {
    let payload = y.net.get(url)
    y.fs.write(filepath, payload)
}

When compiled for Exploidus OS, the Yolish compiler inspects these annotations and validates them against the process's cryptographic capability table. If an unprivileged function attempts to make an unauthorized syscall, the operation is blocked before execution even reaches kernel space.

3. The Tri-Engine Architecture: Interpreter, Bytecode VM, and Native Compiler

Building a language engine involves tough tradeoffs. Tree-walking interpreters are easy to write but slow. Bytecode VMs are fast and portable. Native compilers deliver maximum speed but are deeply architecture-specific.

Instead of choosing one, Yolish implements all three:

Source Code (.y)
       |
    [Lexer] -> Tokens
       |
   [Parser] -> Abstract Syntax Tree (AST)
       |
       +---> Tree-Walking Interpreter  (`ys file.y` - Instant startup)
       |
       +---> Bytecode Compiler & VM    (`ys vm file.y` - High speed execution)
       |
       +---> Direct x86-64 Machine Code (`ys -c file.y` - Standalone binaries)

The Interactive Interpreter (ys file.y): Evaluates the AST directly. Perfect for quick scripts, one-liners, and the interactive REPL.
The Bytecode VM (ys vm file.y): Compiles the AST into an optimized instruction stream executed by a custom register/stack-based virtual machine.
The Native x86-64 Compiler (ys -c file.y): Generates real machine code instructions (MOV, ADD, CALL, RET, SSE2 float operations) directly into executable binary containers.

4. No LLVM, No Bloat: Direct Multi-Platform Binary Emission

Most modern compiler projects delegate code generation to LLVM. While LLVM is powerful, it is also a massive, multi-gigabyte dependency with slow compilation times.

I wanted the Yolish toolchain (ys) to be a single, self-contained C binary with zero external dependencies. You can clone the repo and compile the entire language toolchain with a single make command using standard gcc or clang in seconds.

To achieve this without LLVM, Yolish writes binary headers and machine code directly:

Linux ELF64: Directly formats ELF headers, program headers (PT_LOAD), .text sections, and Linux syscall dispatchers.
Windows PE32+: Generates valid Portable Executable (PE32+) headers, image import directories, and embeds Windows application icons.
macOS Mach-O: Generates 64-bit Mach-O load commands (LC_SEGMENT_64).

You can cross-compile for any major operating system with a single CLI flag:

ys -c app.y --target linux    # Emits static Linux ELF64 binary
ys -c app.y --target windows  # Emits Windows PE32+ .exe
ys -c app.y --target macos    # Emits macOS Mach-O binary

5. Runtime Architecture: Mark-and-Sweep Garbage Collection

A systems language with dynamic strings and closures needs safe, automatic memory reclamation.

Yolish implements a custom Mark-and-Sweep Garbage Collector (GC) written from scratch in C:

Root Scanning: Traverses the active call frame stack, global environment variables, and the VM operand stack to identify all actively reachable pointers.
Mark Phase: Recursively traverses heap-allocated objects (strings, dynamic arrays, closures, struct instances), setting the GC mark bit.
Sweep Phase: Scans the global heap allocation pool. Any block whose mark bit is zero was unreachable; it is freed back to the system memory pool, while surviving objects have their mark bits cleared for the next cycle.

Developers have full programmatic introspection into memory usage via gc.stats() and can trigger explicit collection via gc.collect().

6. A Tooling-First Philosophy

A great programming language is more than just a syntax parser; it is an entire developer experience.

Too many new languages fail because they require third-party formatters, linter plugins, and package wrappers before you can write a serious project.

From day one, Yolish was designed with a tooling-first philosophy:

Built-in Test Runner (ys test file.y): Write native test blocks alongside code and execute them without third-party frameworks.
Static Checker (ys check file.y): Performs static semantic analysis, flags undefined variables, and detects type mismatches before runtime.
Code Formatter (ys fmt file.y): Enforces an opinionated, canonical code style across codebases.
Interactive REPL (ys): Instant feedback loop with color-highlighted evaluation.

7. What Writing a Compiler in C Teaches You

Writing a programming language and compiler from scratch in pure C is one of the most humbling and rewarding journeys in software engineering:

Memory Discipline: Managing AST nodes, symbol tables, and lexical scopes in C forces you to understand every single byte you allocate. Memory leaks in a compiler slow down compilation; memory corruption in code generation crashes the output binary.
The Magic of Abstraction: When you write the code that translates a simple if (x > 10) into a CMP and JLE assembly jump, you demystify how computers actually think. You realize that high-level abstractions are not magic; they are just structured transformations of intent.
Simplicity Over Complexity: Features are easy to add to a grammar; keeping the language coherent, orthogonal, and bug-free across interpretation and native compilation is where the real engineering happens.

Conclusion & Open Source

Yolish started as a specialized language project for Exploidus OS, but has evolved into a versatile, cross-platform programming environment with its own native compiler, VM, and standard library.

The entire project is 100% open-source under the MIT license:

GitHub Repository: https://github.com/rahadbhuiya/Yolish
Supported Platforms: Linux, Windows, macOS, and Exploidus OS.

Download the binary, try out the REPL, write a script, and inspect the C compiler source!

Have you ever thought about designing a programming language? What is the one feature you wish your daily language had? Let's discuss in the comments below!

What Was Your First Programming Language?

Sun, 06 Sep 2026 21:21:42 +0000

Once upon a time there was a kid and an IBM PS/2. I was 11, armed with QBasic By Example (1993) and way too much curiosity for my own good. That book became my doorway into programming. PRINT loops, GOTO chaos, line numbers, and the thrill of watching a computer do exactly what I told it to, or crash spectacularly when I didn’t.

From there was a quick jump into C and later C++. I didn’t know it at the time, but that little QBasic book had already wired my brain for how code behaves, not just how it looks on the page. Moving into C felt like leveling up. Suddenly I had pointers, headers, real control flow, and enough rope to hang myself with. The best part was being able to compile and link my own .exe files and give them to friends.

C++ came next, bringing classes, objects, and a whole new way of thinking about structure. Moving from procedural programming into OOP was a huge step and tough to learn... I wont discuss my frustration with pointers...

Eventually I landed in C#, which felt like the modern, sane evolution of everything I’d learned up to that point. It had the structure I liked from C++, the clarity I wished C had, and enough guardrails to let me focus on building instead of fighting the language. It’s been home ever since.

What kicked off your programming life?
Was it Python? JavaScript? TI‑BASIC on a calculator? Scratch? Something weird and obscure?
Drop your first language and your age when you started — I want to see how everyone’s path compares.

Running a 56M-Parameter LLM on Just Three ESP32 Boards

Mon, 10 Aug 2026 08:44:29 +0000

When I was a kid, I loved the movie WALL·E. I often wondered if something like that would be possible in the future.

As I grew up, I learned how robots work and how much it costs to build one. I realized that building intelligent machines isn't just about software—it's also about overcoming hardware limitations.

Projects like this remind me that we're slowly bringing intelligence to even the smallest devices.

When people talk about running AI locally, they usually mean a laptop with a decent GPU, a Raspberry Pi, or an NVIDIA Jetson.

Microcontrollers rarely enter this type of conversation.

After all, an ESP32-S3 only has a few megabytes of memory. Running a language model on it sounds impossible.

I saw a post about running an LLM on an ESP32 by slvDev, and I was fascinated by it.

Then I came across another project by Wladimir Avila, which took the idea even further.

Instead of asking:

"How can we fit a bigger model on one ESP32?"

It asks:

"What if multiple ESP32 boards worked together like a tiny AI cluster?"

That's exactly what esp32s3-distributed-ai does.

The Problem

Modern language models are huge.

Even "small" language models often require tens or hundreds of megabytes of memory, which is far beyond what an ESP32-S3 can provide.

Buying more powerful hardware is the obvious solution.

But this project explores another idea:

Split the model across multiple microcontrollers.

Rather than forcing one board to hold the entire model, each board becomes responsible for a different part of the inference pipeline. The boards then communicate wirelessly to generate text together.

The Hardware

The setup is surprisingly simple.

3 × ESP32-S3 N16R8 boards
ESP-NOW for communication
One board hosts a Wi-Fi access point
A browser-based interface to interact with the model

No cloud.

No router.

No internet connection after flashing the firmware.

Everything runs locally.

How the Model Is Split

Instead of storing the entire transformer on one board, the project partitions it.

             Prompt

                │

         Board C (Web UI)

                │

         Board A (Embeddings)

                │

      Board B (Transformer)

                │

      Board A (Output Head)

                │

         Board C (Browser)

Each board has a specific responsibility.

Board A

Embeddings
Output head

Board B

Transformer layers
KV cache stored in PSRAM

Board C

Remaining embedding table
Wi-Fi access point
Web interface

The boards exchange intermediate activations over ESP-NOW until the next token is generated.

Why ESP-NOW?

One of the most interesting design decisions is the communication layer.

Instead of using MQTT, TCP sockets, or a router, the project relies on ESP-NOW, Espressif's lightweight peer-to-peer wireless protocol.

Advantages include:

No external infrastructure
Low communication overhead
Direct board-to-board messaging
Fully offline operation

According to the author, the boards communicate through a custom protocol built on top of ESP-NOW, with Board C simultaneously hosting the browser interface.

A 56 Million Parameter Model

The project runs a language model with approximately 56 million parameters.

To make this possible, it uses:

4-bit and 8-bit quantization
Split Per-Layer Embeddings (Split-PLE)
Flash memory for large embedding tables
PSRAM for the KV cache

These optimizations allow a model that would never fit on a single board to execute across three inexpensive microcontrollers.

Inspired by Previous Work

This project builds upon another impressive experiment by slvDev, who demonstrated that a 28.9 million-parameter language model could run on a single ESP32-S3.

That work introduced the use of Per-Layer Embeddings (PLE), inspired by Google's Gemma architecture, to dramatically reduce SRAM requirements by storing most embedding parameters in flash memory.

The distributed version extends that idea even further by partitioning the model across multiple devices.

Current Limitations

The project is still experimental.

Some of the current limitations mentioned by the author include:

Brute-force tokenizer implementation
Quality loss from aggressive 4-bit quantization
Generating relatively short responses (around 30 words)
Focusing on demonstrating distributed inference rather than competing with larger LLMs

Why This Matters

The most exciting part isn't that three ESP32 boards can generate text.

It's the engineering mindset behind it.

Instead of scaling up, this project scales out.

Rather than purchasing more powerful hardware, it distributes computation across multiple low-cost devices.

That idea could inspire future work in:

Offline robotics
Smart factories
Distributed IoT intelligence
Edge AI
TinyML research
Sensor networks

As embedded AI becomes more common, approaches like this could make sophisticated models accessible on hardware that costs only a few dollars.

Final Thoughts

This isn't about replacing ChatGPT.

It's about pushing the boundaries of what's possible on resource-constrained hardware.

Seeing three inexpensive ESP32 boards collaborate to run a 56M-parameter language model is a reminder that innovation often comes from clever system design—not just bigger GPUs.

Projects like this show that the future of AI won't exist only in massive data centers. It may also live on tiny devices working together at the edge.

Project Repository

https://github.com/wladimiravila/esp32s3-distributed-ai

Thanks for reading!

I'm Ganesh, and I'm building MakeSense, an AI tool that turns public GitHub pull requests into concise summaries, prioritized insights, and interactive quizzes. It's free, unlimited, and source-available. If you review open-source code, I'd love for you to give it a try and share your feedback.

MakeSense: https://makesensegithub.com/

Whizz: Your Esoteric Language that's Short as BF, but Easier to Write

Thu, 30 Jul 2026 21:29:04 +0000

I just made Whizz, an esoteric programming language that is full of capability and possible experimentation. Before I interest you in that, I'll explain to you something.

What is an esoteric programming language?

An esoteric language (or an esolang, colloquially), is a programming language designed to not fit the coding 'norms' or conventions.

Take an example: BF ('BF' is an abbreviation and euphemism of brainf***).

A standard language would notate a 'Hello, World!' program as something like:

print("Hello, World!")

BF, on the other hand, requires something like this:

++++++++[>++++[>++>+++>+++>+<<<<-]>+>+>->>+[<]<-]>>.>---.+++++++..+++.>>.<-.<.+++.------.--------.>>+.>++.

As you can see, BF, like most esolangs, is different: it's hard to write and a puzzle.

Whizz is inspired by BF, as its incrementing, decrementing and looping are inspired by it.

I made Whizz because I thought languages like BF were way too monotonous to write. Esolangs should be hard and puzzling to write, but not laborious.

BF requires you type '+' as many times you want to increment (without loops): so you have to find shortcuts and unscalable solutions, just to achieve your goal. In Whizz, just type that incrementation repetition count before the '+' sign, and there you have it!

These wonderful features that Whizz boasts keep the challenge in esolang-ing, but contradictorily makes it more 'scalable'. Another notable feature is functions: the epitome of order.

An example of a Whizz program would be:

zeroToNine {
   [ create variables ]
   counter 10+ [ track state ]
   char 48+ [ print this one ]
   space 32+ [ space char ]
 
   (
     char!+ [ print and increment char ]
     counter-; [ decrement counter and end if zero ]
     space! [ print space ]
   )
}

zeroToNine*

This, self explanatorily, outputs '0 1 2 3 4 5 6 7 8 9'. Again, in minimized form:

c10+n48+s32+(n!+c-;s!)

I genuinely hope you experiment with Whizz, and solve puzzles & challenges with it, as if it were BF!

Install it with the ease of a terminal command:

pip install whizz

If you have MacOS, use pip3.

Then, learn the usage & syntax instructions.

Please share your thoughts, and constructive feedback is absolutely encouraged.

Learn more about Whizz at the main site.

Bye!

Why Language Schools Should Prioritize Cybersecurity: A Passwordless Approach

Mon, 27 Apr 2026 09:12:54 +0000

As language schools use more digital tools, they face bigger risks from cyberattacks. Hackers often target schools because of the valuable personal data they hold. Traditional passwords are not strong enough to protect this information and can be easily hacked. A better solution is passwordless authentication.

In this article, we will explore why language schools should prioritize cybersecurity and how adopting passwordless authentication can protect sensitive information while improving user experience.

The Rising Threats to Language School Security

Language schools face a variety of cybersecurity risks, including data breaches, phishing attacks, and the theft of sensitive student information. Hackers target educational platforms because they hold valuable personal data, such as student records, payment details, and communication histories.

Unfortunately, many schools have weak security systems that make them easy targets. For example, a 2020 report found that educational institutions were among the top sectors targeted by cyberattacks, with over 1,200 cybersecurity incidents reported in the U.S. alone.

These attacks not only threaten student privacy but also damage the reputation and trust that language schools have built. With the rise in cyberattacks, it’s crucial for schools to strengthen their security measures before it’s too late.

Why Passwords Aren’t Enough for Language Schools

For years, passwords have been the standard way to secure online accounts, but they are no longer enough to protect against modern cyber threats. Hackers can easily guess or steal passwords through techniques like phishing or brute force attacks, leading to data breaches and identity theft. This makes relying on passwords a risky choice for language schools. Common challenges with traditional password systems include:

Password fatigue: Users often forget complex passwords, leading them to reuse simple ones across different accounts.
Weak password practices: Many individuals choose easily guessable passwords, like “123456” or “password,” which are highly vulnerable to attack.
Security loopholes: When passwords are reused or not updated regularly, they create gaps in security that hackers can exploit.

What Is Passwordless Authentication and How Does It Work?

Passwordless authentication is a secure login method that eliminates the need for traditional passwords. Instead, users authenticate through alternative methods, such as:

Magic links: A one-time link sent to the user’s email to grant access.
One-time passwords (OTPs): Temporary codes sent via email, SMS, or apps like WhatsApp.
Biometrics: Authentication through fingerprints, facial recognition, or other physical identifiers.

The key benefits of passwordless systems include:

Improved security: Without passwords, there's less risk of phishing or password theft.
Reduced login friction: Users don't have to remember or type passwords, making access faster and easier.
Better user experience: A more secure login process leads to higher user satisfaction.

Modern EdTech platforms, especially those offering multilingual learning, must balance ease of access with strong security. Whether you're building a custom LMS or integrating with easy to use language teacher software, implementing passwordless authentication ensures students and instructors can log in securely without friction.

Endnote

Language schools must prioritize cybersecurity to protect sensitive data. Traditional passwords are no longer enough, leaving schools vulnerable to attacks. Adopting passwordless authentication enhances security, reduces login friction, and improves the user experience. By integrating solutions like MojoAuth, language schools can safeguard their platforms and ensure a safer and efficient learning environment.

English is The Worst Programming Language

Sun, 26 Apr 2026 03:52:16 +0000

In the world of software engineering, we obsess over programming languages: their syntax, their type systems, their performance characteristics, their paradigms. We debate Rust versus Go, Python's readability versus C++'s control, Haskell's purity versus JavaScript's chaos. Yet we rarely acknowledge the elephant in the room — or rather, the language we all use every day that makes every other language look like a model of crystalline precision: English.

English is, without question, the worst programming language ever created. It is not merely flawed; it is fundamentally unsuited for the reliable transmission of complex ideas. Anyone who has ever tried to communicate a non-trivial technical concept to another human being knows this instinctively. The ambiguities, the contextual dependencies, the endless opportunities for misinterpretation — English excels at all of them.

If you have spent any time in meetings, code reviews, specification documents, or even casual Slack threads, you have felt the pain. And if you have any background in mathematics, physics, or formal logic, the contrast becomes almost comically stark.

Precision: The Foundation of Reliable Computation (and Communication)

At its core, a good programming language is a formal system designed for unambiguous execution. Every valid program has exactly one meaning under the language's semantics. A compiler or interpreter will produce the same behavior every time, assuming the same inputs and environment. This is not an accident; it is the entire point.

Mathematics and physics adopted formal languages for the same reason. When Newton or Leibniz developed calculus, they didn't just wave their hands and say "the rate of change, you know, kinda like speed but for curves." They created notation — symbols, rules of manipulation, axioms — that allowed precise statements like:

This expression has one, and only one, interpretation among those who understand the formal system. There is no room for "well, depending on what you mean by derivative" or "in my experience, sometimes it's 2x plus or minus a bit."

Physics follows suit. Maxwell's equations in differential form are not poetic suggestions:

These are not open to "opinions-based" interpretation. Misunderstand a sign or a vector component, and your electromagnetic device will quite literally fail to function. Engineers and physicists spend years learning to think within these formalisms precisely because natural language is too sloppy for the phenomena they describe.

Formal languages exist because human natural languages are terrible at edge cases, scope, and unintended interpretations. We invented predicate logic, set theory, lambda calculus, and programming languages to escape the swamp of ambiguity.

English, by contrast, is the swamp.

The Many Ways English Fails as a Specification Language

Consider something as seemingly simple as a requirement: "The system shall process transactions quickly."

What does "quickly" mean? Under 100ms? Under 500ms? Does it depend on load? On hardware? On network conditions? Is this a hard guarantee or a soft target? English offers no mechanism to distinguish these.

Now imagine trying to implement a sorting algorithm based on an English description:

"Sort the list in ascending order, but put the most important items first, unless they're duplicates, in which case keep the original order for those."

Good luck. Is "important" defined? What constitutes a duplicate? Does "original order" refer to stable sort semantics? English leaves all of this to intuition, shared context, and — inevitably — arguments in code review.

Real-world examples abound in software projects:

"Handle errors gracefully" — Does this mean log them? Retry? Notify the user? Crash the process? Return a default value?
"Make the UI intuitive" — Intuitive to whom? A power user? A complete novice? Someone from a different cultural background?
"The cache should be consistent" — Eventual consistency? Strong consistency? What about partition tolerance?

These are not edge cases. They are the norm. Experienced engineers learn to translate vague English requirements into precise specifications, often using formal tools (user stories with acceptance criteria, UML, TLA+, property-based testing) precisely because English alone is insufficient.

Ambiguity at Every Level

English is ambiguous at the lexical, syntactic, semantic, and pragmatic levels.

Lexical ambiguity (multiple meanings for the same word): "Bank" can mean a financial institution, the side of a river, or to rely on something. Context usually helps, but in technical documents, context can itself be contested.

Syntactic ambiguity (parsing issues): Classic example — "I saw the man with the telescope." Did I use the telescope to see the man, or did the man have the telescope? Programming languages avoid this with strict grammar rules and operator precedence.

Semantic ambiguity: "The function should return the largest value." Largest by what metric? In what ordering? For floating-point numbers, what about NaN or signed zeros?

Pragmatic ambiguity: What is left unsaid. In a conversation between colleagues who have worked together for years, massive amounts of information are implied. New team members, or an AI trying to implement from a spec, have no access to that shared mental model.

Compare this to Python, often praised for readability:

def process_data(data: List[float]) -> Optional[float]:
    if not data:
        return None
    return max(data)

Even without types, the behavior is unambiguous to anyone who knows Python's semantics. max([]) raises an exception, but here we explicitly handle the empty case. The return type hint further constrains expectations.

English has no equivalent of type hints, no compiler to catch inconsistencies, no unit tests for prose.

Why We Put Up With It (And Why We Shouldn't)

English has undeniable strengths. It is expressive, flexible, and culturally rich. It can convey emotion, nuance, humor, and poetry in ways that formal languages cannot. Shakespeare didn't write in lambda calculus for a reason.

But when the goal is reliable transmission of executable ideas — specifications, APIs, requirements, designs — those strengths become liabilities. Flexibility is another word for underspecification.

Anyone with real experience communicating complex ideas knows the pattern:

Write what seems like a clear English description.
Send it to a colleague.
Receive back an implementation that is technically correct but completely misses the intent.
Spend hours in discussion clarifying what was "obviously" meant.
Repeat.

This is why mature software organizations invest heavily in:

Precise requirements documents with measurable acceptance criteria
Formal methods (where the cost justifies it — e.g., aerospace, finance, medical devices)
Contract testing, property-based testing, and exhaustive specification
Code as the single source of truth, with comments used sparingly

The very existence of these practices is an admission that English is inadequate.

In physics and mathematics, we don't tolerate "it's approximately true, in the usual sense." We define terms rigorously. We prove theorems. We build models whose predictions can be falsified experimentally. The precision of the language enables the precision of thought and the reliability of results.

Programming aspires to the same rigor. That's why we have static type systems, formal verification tools like Coq or Lean, and languages with strong guarantees (memory safety, data-race freedom, etc.).

English remains the worst because it resists all such discipline. It evolves organically, embraces exceptions, and thrives on interpretation. It is a living, messy, human thing — wonderful for literature, conversation, and persuasion; disastrous for programming.

A Humble Remark

We don't need to abandon English. We need to recognize its limitations and use better tools where precision matters.

Next time you write a technical specification, ask yourself: Could this be misinterpreted in a way that leads to incorrect behavior? If the answer is yes (and it almost always is), add precision — through examples, edge cases, invariants, or even pseudocode.

Treat English as a high-level, lossy compilation target rather than the final executable specification.

Because in the end, the computer doesn't care about your opinions, your intent, or what "everyone knows" you meant. It executes precisely what you told it — in a real programming language.

And humans, despite our intelligence, are not much better than computers when the specification is written in the worst programming language of all: English.

We just hide our bugs better, and argue about them longer.

Coderive v0.6.0 - Powered Up Language

Thu, 22 Jan 2026 07:51:04 +0000

How we transformed a prototype parser into enterprise-grade infrastructure with immutable state management

Introduction

Coderive v0.6.0, codenamed "Powered Up," marks our transition from experimental language to professional-grade compiler infrastructure. This release fundamentally rearchitects the parsing system, introducing concepts that will support Coderive's growth for years to come.

The Core Problem: Parser Spaghetti

Our previous parser suffered from what we called "parser spaghetti" - tangled state management, inconsistent token consumption, and error-prone backtracking. The MainParser class had grown to over 2,000 lines, mixing program detection, statement parsing, and error handling in ways that made enhancements difficult.

The Solution: Immutable Parser State

Key Innovation: ParserContext & ParserState

We introduced two core classes that changed everything:

// Immutable state representation
public final class ParserState {
    private final List<Token> tokens;
    private final int position;
    private final int line;
    private final int column;
    // All operations return NEW instances
    public ParserState advance() { ... }
}

Why Immutability Matters:

· Predictable backtracking with zero side effects
· Thread-safe parsing for future parallel compilation
· Clean separation between parsing logic and state management
· Debuggability: every parsing step leaves a clear trail

The Expectation Pattern Revolution

Gone are the days of "forgot to consume" bugs. We standardized on an expect() pattern:

// OLD: Fragile manual checking
if (currentToken().type == KEYWORD && currentToken().text.equals("if")) {
    consume();
    // ... parse condition ...
}

// NEW: Consistent expectation-based parsing
Token ifToken = expect(IF);
ExprNode condition = expressionParser.parseExpression();

This pattern eliminates entire categories of parsing bugs and makes the code dramatically more readable.

Professional Package Structure

We've organized the parser into logical packages:

· cod.parser.context - Core state management
· cod.parser.program - Program type detection
· Dedicated StatementParser, ExpressionParser, and DeclarationParser

Performance Wins

Despite adding abstraction layers, parsing is now 30% faster due to:

· Eliminated redundant token validations
· Optimized lookahead with state caching
· Predictable memory access patterns

Real-World Impact

For users, this means:

· More accurate error messages with precise line/column positions
· Faster compilation of large codebases
· Reliable incremental parsing (coming in v0.7.0)
· Better IDE support with our upcoming Language Server Protocol

Code Sample: Before vs After

Before (v0.5.0):

public StmtNode parseIfStatement() {
    if (currentToken == null) return null;
    if (!currentToken.text.equals("if")) return null;
    consume();
    // ... 100 lines of mixed state management and parsing ...
}

After (v0.6.0):

public StmtNode parseIfStatement() {
    Token ifToken = expect(IF);
    ExprNode condition = expressionParser.parseExpression();
    StmtIfNode ifNode = ASTFactory.createIfStatement(condition, ifToken);
    // ... clean, focused parsing logic ...
}

The Bigger Picture

This parser refactoring isn't just about cleaner code. It's about enabling:

Syntax highlighting in VS Code/IntelliJ
Real-time error checking as you type
Refactoring tools (rename, extract method, etc.)
Multi-file analysis across your entire project

Call to Action

Try it now:

git clone https://github.com/DanexCodr/Coderive
cd Coderive
# Check out the new parser architecture

We're building Coderive not just as another language, but as a professional-grade toolchain. This release lays the foundation for everything to come.

Repo link: Click here

Backtick - A Concise Programming Language

Tue, 30 Dec 2025 22:29:47 +0000

Hi there! I made Backtick - it's a very concise programming language written in Python.

I made it because I wanted to make a programming language that you can use, but is very unique. Also, I wanted to be able to use it in future projects.

To install Backtick, run this in your terminal:

pip install backtick

It's got a simple syntax:

command\arg\arg\arg

It has three data types:

> # strings
< # numbers
\ # variables

An example would be:

+\v>Hello, >World!

This would set the variable "v" to "Hello, " and "World!" put together.

You can find all the commands and other details here, and you can find the main page here.

Thanks!

Actual Run of Coderive Language for Lazy Array and Loop

Fri, 26 Dec 2025 11:56:28 +0000

Real Run of Coderive

Real Code of Coderive

Coderive Language - 50ms for 1 Quintillion Elements in a Loop

Mon, 22 Dec 2025 03:54:21 +0000

Author: Danison Nuñez
Project: Coderive
Project Type: Programming Language
Highlight: Formula-based Execution

Coderive - Iterating Through 1 Quintillion in a Loop

Subtitle: How a phone interpreter achieves what supercomputers cannot

The Impossible Loop:

// In any other language, this would be computational suicide
for i in [0 to 1Qi] {  // 1,000,000,000,000,000,000 iterations
    arr[i] = i * i
}

Traditional Reality:

· Python: MemoryError at array creation
· Java/C++: Theoretical 31 years (with 8 exabytes of RAM)
· NumPy/TensorFlow: Immediate crash
· GPU Computing: 80GB VRAM limit exceeded

Coderive's Reality: 50 milliseconds.

The Magic Behind It:

NaturalArray: Virtual arrays that store formulas, not data
Runtime Pattern Detection: Transforms loops to mathematical expressions
Lazy Evaluation: Computes only what's accessed
Formula Storage: LoopFormula, ConditionalFormula, MultiBranchFormula

Technical Deep Dive:

// What you write:
for i in [0 to 1Qi] {
    if i % 2 == 0 {
        arr[i] = i * i
    } elif i % 3 == 0 {
        arr[i] = i * i * i
    } else {
        arr[i] = i
    }
}

// What Coderive creates internally:
arr.addMultiBranchFormula(
    conditions: [i%2==0, i%3==0],
    expressions: [i*i, i*i*i],
    elseExpr: i,
    range: [0, 1Qi]
)

The Optimization Pipeline:

User Code → Pattern Detection → Formula Creation → Lazy Evaluation
     ↓           ↓                ↓                  ↓
   O(n)        O(1)             O(1)              O(1) per access

Complete Pattern Coverage:

· ✅ Simple Transformations: arr[i] = f(i) → LoopFormula
· ✅ Binary Decisions: if-else → ConditionalFormula
· ✅ Multi-way Branches: if-elif-else → MultiBranchFormula
· ✅ Partial Updates: if-only with implicit else preservation

Real-World Impact:

// Process every pixel in 8K video (≈33 million frames)
for frame in [0 to 33M] {
    for pixel in [0 to 7680*4320] {  // 33 million frames × 33 million pixels
        if brightness > 128 {
            pixels[pixel] = 255
        } elif brightness > 64 {
            pixels[pixel] = 128
        } else {
            pixels[pixel] = 0
        }
    }
}
// Traditional: Impossible
// Coderive: Seconds, not centuries

The Secret Sauce:

· No data movement (arrays stay virtual)
· No parallel programming (formulas are inherently parallel)
· No memory management (O(1) memory complexity)
· No specialized hardware (runs on Java 7)

Conclusion: Coderive doesn't just make loops faster—it redefines what's computationally possible on commodity hardware.

Check Coderive now at:

[http://github.com/DanexCodr/Coderive][1]

Coderive - A New Programming Language of 2025

Sun, 21 Dec 2025 05:02:05 +0000

Author: DanexCodr
Project: Coderive
Project Type: Programming Language

While AI takes the spotlight, Coderive solves computational impossibility

In a landscape dominated by AI integrations and web frameworks,Coderive emerges as a fundamentally different kind of programming language for 2025. Instead of chasing the latest AI trend, Coderive addresses a more profound problem: breaking computational complexity barriers that have limited programmers for decades.

The Core Innovation:
Coderive introduces"Formula-Based Computing" - a runtime optimization system that transforms traditional O(n) operations into O(1) mathematical formulas. Where other languages iterate, Coderive calculates.

Syntax That Speaks for Itself:

// Traditional languages would crash or take millennia
arr := [0 to 1Qi]  // 1 quintillion elements - virtual, not allocated

// This runs in 50ms, not 31 years
for i in [0 to 1Qi] {
    if i % 2 == 0 {
        arr[i] = i * i          // "even" squares
    } elif i % 3 == 0 {
        arr[i] = i * i * i      // "multiple of 3" cubes  
    } else {
        arr[i] = i              // everything else
    }
}

Why 2025 Needs Coderive:
· Big Data Without Big Infrastructure: Process trillion-row datasets on phone hardware
· Mathematical Clarity: any[] and all[] replace confusing &&/|| operators
· Runtime Intelligence: Pattern detection happens as code executes, no pre-compilation needed
· Three World System: Scripts, Methods, and Modules for different abstraction levels

The Quantifier-First Design Philosophy:
Abandoning traditional boolean operators,Coderive embraces a more expressive syntax:

// Crystal clear intent vs traditional &&/|| confusion
if all[scores >= 60, !isFailed, attempts < 3] { proceed() }
if any[isReady, hasBackup, forceMode] { execute() }

Performance That Defies Convention:
Operation Coderive Python/Java/C++
Process 1 quintillion elements 50ms Never completes
Memory for 1 quintillion array O(1) 8EB (impossible)
Conditional classification O(1) O(n)

Available Now:
Coderive v0.4.0 runs on Android/Java 7+, proving that revolutionary computation doesn't require cutting-edge hardware. It's a language for the algorithmic future, available today.

Check it out now at: https:// github.com/DanexCodr/Coderive

Coderive v0.3.0: The Design Leap - A Realized Vision

Mon, 15 Dec 2025 06:54:32 +0000

Author: DanexCodr
Date: December 15, 2025
Repository: https://github.com/DanexCodr/Coderive

The Three-World System: Scripting, Functional, and OOP in Harmony

A Language for Every Task

Coderive v0.3.0 introduces a revolutionary approach: three distinct program types that share a common syntax but optimize for different development paradigms.

World 1: Scripts - Direct and Immediate

Scripts are the simplest form of Coderive programs—perfect for automation, quick calculations, and learning:

// Simple script - executes top-down
output "=== Temperature Converter ==="
fahrenheit: float = (float) input "Enter °F: "
celsius: float = (fahrenheit - 32) * 5 / 9
output fahrenheit + "°F = " + celsius + "°C"

Characteristics:

· No classes or methods required
· Direct statement execution
· Perfect for one-off tasks
· Implicit Script type wrapper

World 2: Method Scripts - Functional Focus

Method Scripts bridge scripting and modular programming, focusing on reusable functions:

// Method script - only functions, no classes
local calculateBMI(weight: float, height: float) :: bmi: float {
    bmi = weight / (height * height) ::
}

local categorizeBMI(bmi: float) :: category: text {
    if bmi < 18.5 {
        category = "Underweight" ::
    } else if bmi < 25 {
        category = "Normal" ::
    } else if bmi < 30 {
        category = "Overweight" ::
    } else {
        category = "Obese" ::
    }
}

share main() {
    output "BMI Calculator"
    weight := (float) input "Weight (kg): "
    height := (float) input "Height (m): "
    
    bmi := calculateBMI(weight, height)
    category := categorizeBMI(bmi)
    
    output "BMI: " + bmi + " (" + category + ")"
}

Characteristics:

· Only functions allowed
· main() method as entry point
· Encourages pure functions
· Implicit MethodScript container

World 3: Modules - Full Object-Oriented Programming

Modules represent Coderive's most powerful form, supporting classes, inheritance, and complex systems:

unit BankingSystem

use {
    lang.Sys,
    math.Finance
}

share BankAccount {
    // Fields
    owner: text
    balance: float
    accountNumber: int
    
    // Constructor
    share this(ownerName: text, initialDeposit: float) {
        owner = ownerName
        balance = initialDeposit
        accountNumber = generateAccountNumber()
    }
    
    // Methods
    local deposit(amount: float) :: newBalance: float {
        balance = balance + amount
        ~> newBalance: balance
    }
    
    local withdraw(amount: float) :: success: bool, newBalance: float {
        if amount <= balance {
            balance = balance - amount
            ~> success: true, newBalance: balance
        } else {
            ~> success: false, newBalance: balance
        }
    }
    
    // Private helper
    private generateAccountNumber() :: number: int {
        // Implementation details...
    }
}

    share main() {
    account := BankAccount("Alice", 1000.0)
         result := account.withdraw(500)
    
         if result.success {
            output "Withdrawal successful. New balance: " + result.newBalance
     }
}

Characteristics:

· Full class support with PascalCase naming
· Constructors with this keyword
· Public and private methods
· Multiple return values via slots
· Explicit unit declarations

The Interpreter's Role

The Coderive interpreter intelligently handles all three world types:

// In Interpreter.java
private void runModule(ProgramNode program) {
    // Find and execute main() in a class
    // Full OOP support
}

private void runScript(ProgramNode program) {
    // Execute statements directly
    // No method/class overhead
}

private void runMethodScript(ProgramNode program) {
    // Find main() method in synthetic type
    // Function-focused execution
}

Design Philosophy

The Three-World System addresses fundamental programming needs:

Beginner-Friendly: Scripts lower the barrier to entry
Functional Elegance: Method Scripts encourage clean, testable code
Enterprise-Ready: Modules support large-scale development

Practical Benefits

For Education:

· Students start with scripts, progress to functions, then learn OOP
· Gradual complexity increase matches learning curves

For Development:

· Quick prototypes as scripts
· Utility libraries as method scripts
· Production systems as modules

For Maintenance:

· Clear boundaries between different abstraction levels
· Easy migration between paradigms as needs change

The Vision Realized

This tri-modal approach represents a bold vision: one language that adapts to the programmer's needs, rather than forcing the programmer to adapt to the language. It acknowledges that different tasks require different tools, and provides all three in a cohesive, consistent syntax.

Coderive - A mobile-first programming language created entirely on a phone

Fri, 14 Nov 2025 03:15:57 +0000

Coderive - A Mobile-First Programming Language Created Entirely on a Phone

In the world of compiler development and programming language design, we often imagine teams of engineers working in high-tech offices with powerful workstations. But what if I told you that a fully-featured programming language with a sophisticated compiler pipeline was built entirely on a mobile phone? Meet Coderive - a groundbreaking project that challenges our assumptions about where and how serious software development can happen.

The Vision Behind Coderive

Coderive represents a bold vision: "To have the very first Filipino-made mobile-first production-ready self-hosting programming language." This isn't just another programming language - it's a statement about accessibility, innovation, and breaking down barriers in software development.

Development Against All Odds

The developer, DanexCodr, created Coderive using only a smartphone and a carefully curated set of mobile development tools:

· Java NIDE - A fast Java 7 compiler for Android
· Quickedit - For code editing
· Termux - Providing a Linux environment
· AI Assistants - DeepSeek and Gemini for debugging and problem-solving

This constrained environment forced creative solutions and optimized the entire development process for mobile-first workflows.

Technical Architecture: Sophisticated Under the Hood

Despite its mobile origins, Coderive boasts a surprisingly sophisticated technical architecture:

Dual-Parser System

Coderive features not one, but two independent parsing systems:

· ANTLR-based parser for robust, grammar-driven parsing
· Manual recursive backtracking parser for flexibility and mobile optimization

This dual approach ensures parsing reliability while maintaining performance on mobile devices.

Advanced Compilation Pipeline

The compilation system demonstrates remarkable technical depth:

// From CompilationEngine.java
public void compileFullPipeline(ProgramNode ast, String outputFilename, boolean disassemble) {
    BytecodeProgram bytecode = compileToBytecode(ast, disassemble);
    compileToNative(bytecode, outputFilename);
}

The pipeline compiles through multiple stages: source → AST → bytecode → native assembly, supporting both interpretation and native compilation.

Innovative Register Allocation

One of Coderive's most impressive features is its "future-cost predictive register spilling" system. The register allocator doesn't just use simple LRU - it predicts which registers will be needed soon and makes intelligent spilling decisions:

// From RegisterSpiller.java - Advanced spill heuristic
private int estimateNextUseDistance(String register, int currentPc, List<BytecodeInstruction> bytecode) {
    // Complex lookahead analysis to predict register usage patterns
    // This goes far beyond typical academic register allocators
}

Language Features That Shine

Coderive isn't just technically impressive - it introduces several innovative language features:

Multi-Return Slots

share interactiveDemo {
    ~| formula, operation  // Declare return slots
    local calculate(int a, int b, string op) {
        if op == "+" {
            ~ formula a + b      // Return multiple values
            ~ operation "addition"
        }
    }
}

Expressive Smart For-Loops

The language supports complex loop patterns that would be verbose in other languages:

// Various supported step patterns
for i by 2 in 1 to 10          // Simple step
for i by *2 in 1 to 100        // Multiplicative step  
for i by i-=5 in 100 to 1       // Compound assignment step
for i by *+2 in 1 to 1000      // Combined operator step

Clean, Modern Syntax

Coderive reduces boilerplate while maintaining readability:

unit sample.program get {
    cod.Math  // Clean import system
}

share main() {
    output "Welcome to Coderive!"
    // Implicit class and method structure
}

The Compilation Output: Professional Grade

Despite being built on a phone, Coderive generates professional-quality assembly code:

    .text
    .global calculate
calculate:
    stp x29, x30, [sp, #-16]!
    mov x29, sp
    sub sp, sp, #64
    // Advanced register allocation in action
    stp x19, x20, [x29, #-16]
    stp x21, x22, [x29, #-32]
    // ... sophisticated ARM64 assembly
    mov x0, x21  // Return value
    ret

Why Coderive Matters

Democratizing Compiler Development

Coderive proves that you don't need expensive hardware or institutional backing to create sophisticated programming tools. A smartphone and determination are enough.

Filipino-Led Innovation

In a field dominated by Western institutions and large tech companies, Coderive represents important representation and demonstrates that innovation can come from anywhere.

Mobile-First Mindset

While others treat mobile as a secondary platform, Coderive embraces it as primary, leading to optimizations and approaches that desktop-focused tools might miss.

AI-Paired Development Methodology

The project showcases how AI assistants can accelerate complex development tasks, potentially changing how individual developers approach large projects.

Current Status and Future

Coderive is already remarkably functional:

· ✅ Full interpreter with complete language features
· ✅ Native code generation for ARM64 and x86_64
· ✅ Advanced register allocation with spill optimization
· ✅ Complex control flow and loop patterns
· Ongoing improvements to string handling and type system

The project welcomes community involvement and discussion through GitHub Discussions.

Conclusion: Redefining Possible

Coderive stands as a testament to what's possible when passion meets persistence. It challenges our assumptions about:

· Where serious development can happen (anywhere with a phone)
· Who can create programming languages (anyone with vision)
· How we approach tool development (mobile-first from day one)

In the words of the project's motto: "Built with passion and persistence on and for mobile devices — proving that innovation knows no hardware boundaries."

Coderive isn't just another programming language; it's a demonstration that the future of software development might be more mobile, more accessible, and more diverse than we ever imagined.

Happy coding to derive your visions!

Explore Coderive: (GitHub Repository)

DevLog 20250711: init.py

Fri, 11 Jul 2025 12:55:54 +0000

Revision: 01
Last Update: 2025-07-11

Python: `init.py`

In Python, any folder with an __init__.py file is treated as a package. Beyond merely signaling "this is a package," the body of __init__.py is executed once on the first import of that package:

# mypkg/__init__.py
print("Initializing mypkg…")

from .submodule import foo
foo()

Package marker: without it, legacy Python (pre-3.3) wouldn't recognize the folder as importable.
Init code: import-time logic, re-exports (via __all__), lazy-loading, package-level constants, or registration hooks.

JavaScript / Node.js: `index.js` (or `main` entry)

A folder containing an index.js becomes the "default" module when you require('./dir') or import … from './dir'. Any top-level code in index.js runs on first load:

// mylib/index.js
console.log('Bootstrapping mylib…');
module.exports = {
  foo: require('./foo')
};

Entrypoint marker: Node looks for index.js (or whatever "main" says in package.json).
Init code: startup logic, polyfills, shared configuration, or wiring of sub-modules.

Go: `func init()`

Every Go file may define one or more init() functions. They run once per package, before main() or any other package-scope references:

// pkg/foo/foo.go
package foo

import "fmt"

func init() {
    fmt.Println("Initializing package foo")
}

func Foo() { /* … */ }

Package discovery: any folder under $GOPATH (or a module) is a package if it contains Go files all declaring the same package name.
Init hooks: multiple init() funcs across files get sequenced by the compiler; use sparingly for registration or side-effects.

Java / JVM languages: static initializers

Java packages are a purely naming convention - no file marks a folder as a package. To run code when classes load, you use static initializers in classes:

package com.example.mylib;

public class Bootstrap {
    static {
        System.out.println("Loading com.example.mylib");
        Config.registerAll();
    }
}

Package marker: the package declaration in each .java file plus folder layout.
Init code: any class with a static block (or a static field initializer) will execute when that class is first loaded by the JVM. You can force it by referencing the class in your app's entry point.

C# / .NET: static constructors

Like Java, namespaces in C# are declared in each file - folders are only convention. To perform per‐assembly or per‐class initialization:

namespace MyCompany.MyLibrary
{
    public static class Bootstrap
    {
        static Bootstrap()
        {
            Console.WriteLine("MyLibrary initializing");
            Registry.Setup();
        }
    }
}

Namespace marker: the namespace keyword in code; folder structure optional.
Init code: static constructors (static ClassName()) run once before any member of that type is accessed. For assembly-level hooks, you can place [ModuleInitializer] in .NET 5+.

Ruby (Gems): library root file

Ruby gems almost always have a single "root" file under lib/ named after the gem:

# lib/mygem.rb
puts "Initializing MyGem"
require_relative "mygem/version"
require_relative "mygem/core"

Package marker: the gemspec tells RubyGems that lib/mygem.rb is the entrypoint.
Init code: top-level code in that file runs on the first require 'mygem', used to set up autoloads, mixins, or configuration defaults.

PHP (Composer): bootstrap files

PHP's PSR-4 autoloader maps namespaces to directories, but you often supply a manual bootstrap:

<?php
// src/bootstrap.php
echo "Bootstrapping App…\n";
spl_autoload_register(…);
define('APP_STARTED', true);

Package marker: composer.json's "autoload" section.
Init code: any PHP file you include - often named bootstrap.php or init.php - and run before handling a request or CLI command.

Summary of Init-Code Patterns

Language	Package Marker	Init Hook Mechanism
Python	`__init__.py`	Top-level code in `__init__.py`
Node.js	`index.js` / `"main"`	Top-level code in entry file
Go	any folder of Go files	`func init()`
Java	`package …` + folders	`static { … }` blocks
C#/.NET	`namespace …`	`static ClassName()` constructor or `[ModuleInitializer]`
Ruby	gemspec → `lib/gem.rb`	Top-level code in gem root file
PHP	`composer.json` autoload	Included bootstrap file

In practice, most ecosystems decouple "marking" a module from "running init code," using either:

A special filename (like Python's __init__.py or Node's index.js), or
Language hooks (Go's init() or JVM/C# static initializers), or
Build-time metadata (Composer's JSON, Ruby's gemspec) combined with an explicit bootstrap include.

DevLog 20250711: Limitations of Scratch

Fri, 11 Jul 2025 12:55:09 +0000

Revision: 1
Last update: 2025-07-11
Tags: Reference

Scratch is top 20 most used programming language in TIOBE index. Understanding limitations of other programming systems is key to improving our own programming language (Divooka).

Scratch targets a different audience than we do, however, it's very well-designed, highly accessible and well adopted. Due to its visual paradigm similarity, we use it as a point of comparison for Divooka in terms of fidelity.

Scratch is designed for learning and small‐scale animations or games. It does this job really well.

Advantages

Here are some of the major advantages of using Scratch as a first programming environment:

Intuitive, Low-Barrier Visual Interface
Scratch's drag-and-drop block system eliminates syntax errors and lets learners focus on concepts rather than typing rules. Its colorful, tactile blocks and immediate feedback make it fun and engaging from the very first project.
Fosters Creativity and Engagement
With Scratch, users can build interactive stories, animations, games, music and art - mixing sprites, sound and backgrounds to realize their ideas. This "Imagine-Program-Share" cycle encourages open-ended exploration and artistic expression.
Promotes Computational Thinking & Problem-Solving
By snapping together blocks for loops, conditionals, variables and events, students naturally learn decomposition, algorithmic thinking and debugging strategies. Scratch even introduces parallelism - each sprite runs its own scripts - so beginners see concurrency concepts early on.
Vibrant, Collaborative Online Community
The Scratch website hosts millions of "Scratchers" who share, remix and comment on projects. Community-run studios and design challenges foster collaboration, peer feedback and iterative learning - building social-emotional as well as coding skills.
Highly Accessible & Inclusive
Scratch is completely free and runs in any modern web browser (or as an offline desktop app). It's translated into over 50 languages and its block-based format lowers barriers for learners with dyslexia, limited typing skills or other challenges.
Educationally Aligned & Cross-Disciplinary
Used in thousands of schools worldwide (from elementary through college), Scratch supports math, science, history and language arts lessons through interactive simulations and tutorials. Educators leverage it to visualize abstract concepts and design project-based assessments.
Strong Foundation for Future Coding
Concepts mastered in Scratch - sequencing, events, data structures - translate directly to text-based languages like Python and Java. Many curricula use Scratch as a stepping-stone to more advanced computer science topics and career pathways.
Builds Confidence & Persistence
The instant, visual nature of Scratch's feedback loop - see your sprite move as soon as you snap a block - encourages learners to experiment, iterate and persist through challenges, laying the groundwork for resilient problem-solving habits.

Limitations

It runs into trouble once you're trying to build "real" software. Below we enumerate some major pain points, and some ideas for how to overcome each.

1. Monolithic, Flat Project Structure

What happens in Scratch:
All your code lives in sprites and the Stage, with no real namespace or folder hierarchies. It's like having every chapter of your novel printed on Post-its stuck to one wall.
Why it's a problem at scale:
- Hard to organize hundreds of scripts
- Difficult to see "what calls what"
- Prone to name collisions when you start copying-and-pasting blocks
How to address it:
- Custom block libraries: Treat each custom block as a mini-module, and group them carefully by sprite (e.g. "Physics," "UI," "Data").
- Transpile to text code: Export your project to JavaScript or Python (via tools like TurboWarp or external transpilers) so you can organize into real files and folders.
- Adopt a hybrid editor: Use tools like MakeCode or Blockly that let you switch between blocks and text, and support hierarchical file structures.

2. No Real Version Control

What happens in Scratch:
You "Save" or "Remix," and history is opaque. There's no Git diff you can read or "branch" your experiments.
Why it's a problem at scale:
- Team collaboration stalls
- Risk of overwriting each other's work
- Hard to roll back a specific change (e.g. "Why did the scoring logic break on June 10?")
How to address it:
- Structured exports: Regularly export your project as SB3 and check those binary files into a Git repo with clear commit messages.
- Text-based backups: Leverage a transpiler to convert Scratch blocks into JavaScript or Python, then use Git on the resulting code.
- Use a visual-code platform with Git support: Divooka or alternatives (e.g. Node-RED, Blockly) that let you commit changes as text under the hood.

3. Limited Language Features

What happens in Scratch:
You get basic loops, conditionals and variables, but no classes, no modules, no first-class functions, no generics.
Why it's a problem at scale:
- You can't encapsulate complex behavior neatly
- Difficult to share sophisticated libraries (e.g. a math library or HTTP client)
How to address it:
- Extension mechanism: Build or use native extensions (ScratchX or TurboWarp extensions) to expose advanced APIs (file I/O, networking, data structures).
- Hybrid blocks + text: Offer a "power user" mode where blocks desugar into real functions and classes in a host language.
- Migrate critical components: For performance- or feature-critical parts (e.g. physics engine), write them in C# or Python and call them via an FFI-style bridge.

4. Performance & Resource Constraints

What happens in Scratch:
All scripts run in a single-threaded VM with modest optimization; large loops or many clones can slow everything to a crawl.
Why it's a problem at scale:
- Complex simulations or data processing become unbearably slow
- No easy way to leverage multiple CPU cores or GPU
How to address it:
- Chunk and yield: Break big tasks into small chunks and let the scheduler breathe (e.g. use wait 0 secs strategically).
- Native compute modules: Offload heavy work into native extensions written in C/C++/Rust.
- Parallelizable architecture: Move to a platform (like Divooka) that supports true multithreading or asynchronous tasks.

5. Debugging & Testing

What happens in Scratch:
You're limited to watching sprites move, sprinkling in say blocks or using the "block watcher." There's no unit-test framework or breakpoint debugger.
Why it's a problem at scale:
- Bugs hide in tangled event chains
- Hard to write repeatable regression tests
How to address it:
- Logging extension: Create blocks that log to an external console or file.
- Test harness in code: Transpile critical logic into plain code and write unit tests (e.g. using pytest or NUnit).
- Visual breakpoint system: Enhance your tool (or use TurboWarp) to allow pausing and inspecting variables at runtime.

6. Collaboration & Team Workflow

What happens in Scratch:
Mostly a single-user hobby environment with "Remix" as the only share option.
Why it's a problem at scale:
- No real task assignment or issue tracking
- Unstructured remixing leads to forks with no merge path
How to address it:
- Integrated project management: Embed issue-tracking metadata in your SBC file or alongside exports.
- Merge tooling: Use text-based diffs (after transpilation) and Git-based PR workflows.
- Role-based access: Adopt an environment where you can assign "developer," "reviewer," "tester" roles, with locking on code units.

Bottom Line

Scratch is an incredible gateway for learning programming fundamentals and building quick prototypes. But when you're talking hundreds of sprites, gigabytes of assets, dozens of collaborators, or millions of lines of logic… you need:

Modularity & namespaces (think packages)
Text-based exports for version control
Advanced language features & extensions
Performance optimizations via native code
Real debugging & testing frameworks
Team collaboration workflows

Many of these gaps can be addressed by extended platforms like Snap!, Blockly/MakeCode and TurboWarp.

Topic 20250618: Procedural Context is More Learning (and Syntax) to Users

Wed, 18 Jun 2025 17:44:27 +0000

Overview

When people first open Divooka, they see a network of interconnected nodes where connections represent data flow.

Even someone who has never seen visual programming or Divooka before can read the titles of the nodes and input parameters and have a pretty good guess at what the program does.

Thus, a key to using Divooka (in the dataflow context) efficiently is understanding the execution runtime - what nodes are active, what the dependency tree is, and how caching works.

As someone who has been using Unreal Engine Blueprint since 2014, the concept of "execution flow" appears natural to me - but when showing this to new users, it became evident that it takes time to tune in and learn to read the diagrams.

We'll take a look at what procedural context is, then briefly analyze why that's the case.

The Procedural Constructs

The procedural context in Divooka provides many constructs that may be familiar to those from traditional programming languages.

An example is shown below:

Common Constructs

Conditional logic is done using the Branch node.

Loops are implemented using the Repeat node.

Iteration is done using the For Each node.

Functions are handled using the Execute Event and Custom Event nodes.

A switch-case structure is implemented using the Switch node.

(Pending image)

Unique Constructs

In addition, Divooka also offers constructs that are unique to it:

Sequence nodes are used to define multiple sequential steps.

Events are entry points defined by the framework (procedural context base type).

Implementation Note

Certain constructs are currently missing:

Break: to exit a loop prematurely.

Caveats of States

What's more, in procedural context there is the possibility of manipulating state - for example, incrementing a number to be used next time.

Thus, to use the procedural context effectively, users need to learn a good amount of "syntax": control flow, state handling, and more.

The Two Contexts

Given that all of the top 10 most popular programming languages support imperative/procedural programming as the default mode, one might expect this to be the most straightforward paradigm. In reality, that's not the case.

Use the dataflow context for data-centric operations, such as data transformations.

Use the procedural context for logic-centric operations, such as branching and conditional executions.

Unlike procedural context, when using dataflow context, users need to learn only a single syntax: connections represent data flows, and everything (almost) always executes - depending on node activation status. To follow the flow of a program is simply to follow the connections - there's no concern about branches or alternate execution paths.

Conclusion

The procedural context is more complex for several reasons:

Connections now represent both data and execution flow
Some nodes can interrupt, diverge from, or selectively execute downstream connections - requiring users to understand exact behaviors to make accurate predictions
There are many types of flow control nodes, each requiring learning
State is involved

Part of the reason Divooka started with the dataflow context was exactly to reduce this complexity. However, as programs become more complicated and procedural logic becomes involved, it's not possible to avoid procedural context - in fact, having it is often more convenient than not.

Users must make informed decisions about what to put into procedural context and what to offload to dataflow context.

Coder Legion - Recent posts tagged language

Writing a Programming Language & Native x86-64 Compiler from Scratch in C: The Story of Yolish

1. Language Design: Ergonomics Meets Systems Control

Immutability by Default

Pattern Matching with Ranges & Guards

Structs and impl Blocks

2. Bridging Code to the Kernel: First-Class Capabilities

3. The Tri-Engine Architecture: Interpreter, Bytecode VM, and Native Compiler

4. No LLVM, No Bloat: Direct Multi-Platform Binary Emission

5. Runtime Architecture: Mark-and-Sweep Garbage Collection

6. A Tooling-First Philosophy

7. What Writing a Compiler in C Teaches You

Conclusion & Open Source

What Was Your First Programming Language?

Running a 56M-Parameter LLM on Just Three ESP32 Boards

The Problem

The Hardware

How the Model Is Split

Why ESP-NOW?

A 56 Million Parameter Model

Inspired by Previous Work

Current Limitations

Why This Matters

Final Thoughts

Whizz: Your Esoteric Language that's Short as BF, but Easier to Write

Why Language Schools Should Prioritize Cybersecurity: A Passwordless Approach

The Rising Threats to Language School Security

Why Passwords Aren’t Enough for Language Schools

What Is Passwordless Authentication and How Does It Work?

Endnote

English is The Worst Programming Language

Precision: The Foundation of Reliable Computation (and Communication)

The Many Ways English Fails as a Specification Language

Ambiguity at Every Level

Why We Put Up With It (And Why We Shouldn't)

A Humble Remark

Coderive v0.6.0 - Powered Up Language

Backtick - A Concise Programming Language

Actual Run of Coderive Language for Lazy Array and Loop

Coderive Language - 50ms for 1 Quintillion Elements in a Loop

Coderive - Iterating Through 1 Quintillion in a Loop

Coderive - A New Programming Language of 2025

While AI takes the spotlight, Coderive solves computational impossibility

Coderive v0.3.0: The Design Leap - A Realized Vision

The Three-World System: Scripting, Functional, and OOP in Harmony

Coderive - A mobile-first programming language created entirely on a phone

DevLog 20250711: __init__.py

Python: __init__.py

JavaScript / Node.js: index.js (or main entry)

Go: func init()

Java / JVM languages: static initializers

C# / .NET: static constructors

Ruby (Gems): library root file

PHP (Composer): bootstrap files

Summary of Init-Code Patterns

DevLog 20250711: Limitations of Scratch

Advantages

Limitations

1. Monolithic, Flat Project Structure

2. No Real Version Control

3. Limited Language Features

4. Performance & Resource Constraints

5. Debugging & Testing

6. Collaboration & Team Workflow

Bottom Line

Topic 20250618: Procedural Context is More Learning (and Syntax) to Users

Overview

The Procedural Constructs

Common Constructs

Unique Constructs

Implementation Note

Caveats of States

The Two Contexts

Conclusion

References

Structs and `impl` Blocks

DevLog 20250711: init.py

Python: `init.py`

JavaScript / Node.js: `index.js` (or `main` entry)

Go: `func init()`