Fracture – SITREP

It's been a minute since my last post.....Regarding Fracture - It hasn’t been a massively productive stretch.

Work’s been heavy. Life’s been busy. Fracture has mostly existed as notes, ideas, and “I need to fix that” thoughts in the back of my head.

But this weekend and especially last night I finally got proper time with it. I’m not working on Fracture every day at the moment.

But when I do sit down uninterrupted, the progress is sharp. This weekend alone:

- Expanded automated testing coverage
- Tightened parts of the runtime
- Strengthened destructuring behaviour
- Improved object handling
- Cleaned up edge cases that were bothering me
- Pushed Fracture FPM forward

None of that is headline material.

But it’s the kind of work that compounds.

Fracture feels sturdier after this weekend.

The Syntax Still Feels Right

The core style remains exactly how I designed it.

Arguments go on the left:

["Hello World"] print;

Chaining stays clean:

["   fracture   "] trim >> uppercase >> print;

It still reads like a pipeline.
It still feels intentional.

Every time I write real scripts in it, I’m reassured that the left-argument model was the right decision.

Arrays and Structure

Arrays now behave predictably — including mutation and structured access.

let data = [1, 2, 3];
data[0] = 42;
[data] print;

Destructuring is stable:

let [a, b] = [10, 20];
[a, b] = [b, a];
[[a, b]] print;

Nested destructuring works too:

let [[x, y], z] = [[1, 2], 3];
[[x, y, z]] print;

It’s expressive, but not clever for the sake of being clever.

That balance matters.

Objects Are Becoming Practical

Object literals and property access are behaving consistently now.

let user = { name: "Colin", score: 100 };
[user.name] print;

user.score = user.score + 50;
[user.score] print;

Nothing magical. Nothing hidden.

Just predictable behaviour.

And that’s what I want Fracture to be built on.

Fracture FPM

This is probably the most important direction recently.

Fracture FPM allows Fracture to run in a request/response style model, making it usable for web execution.

I’m deliberately not over-engineering this. The goal isn’t to clone another ecosystem.

It’s simply this:

Fracture should be able to run somewhere real.

That changes how I think about the language.
It stops being theoretical.

Development Process

I also migrated my development workflow to a cleaner setup recently.

Not because the old one was broken.

But because friction kills momentum — especially when you only get nights and weekends.

The goal wasn’t speed.

It was flow.

Faster iteration. Cleaner builds. Easier testing.

When time is limited, that matters more than anything.

Timing & Benchmarks

The timing module is still part of regular development:

import time;

time::start;

let total = 0;

for [i in 1..100000] do {
    total = total + i;
}

time::end;
[total] print;

I’m not trying to chase numbers.

I’m trying to make sure Fracture feels responsive.

There’s a difference.

Where It Stands

Right now Fracture supports:
- let declarations
- destructuring (declaration + assignment)
- arrays and mutation
- object literals
- range loops
- foreach loops
- module imports
- timing
- random
- automated testing
- web execution via FPM
And most importantly — it feels coherent.

Even if progress comes in bursts, the direction is steady.

Looking Ahead

Hopefully more nights like last night.

More weekends where I can sit down and just build without interruption.

Fracture doesn’t need to move fast.

It just needs to keep moving — properly.

And when I get time, it does.

/ Signing off