This looks nicely aligned with Bret Victor’s ideas around tight feedback loops. One thing I’m curious about is how you’re thinking about debugging and state visibility as programs grow beyond small examples.
In reactive systems, we’ve found the learning experience improves a lot when users can inspect how a value changed over time, not just its current output. Do you see Weft moving toward any kind of execution history or state timeline, or are you intentionally keeping it minimal for teaching?
Thanks for the feedback. You're right, it's part of the long term goals.
I'd like to keep the center of the screen clutter free and add side-bars later on with tooling. Among them, an inspector just like what PyCharm has when opening a notebook. For globals it's quite simple to add, however to inspect the content of a single compound statement it might be a bit tricky (if you've got ideas I'd love to learn more).
Some of the next "urgent" features are improving the code state management (history), having multiple sessions, being able to save them, etc. Maybe adding a way to bring the data online somehow.
We ran into the same gap after MacUpdater started drifting. What worked reasonably well for us was splitting the problem instead of trying to replace it 1:1.
Homebrew (plus brew outdated) covered CLI tools and a subset of apps. For GUI apps, we relied on Sparkle-based self-updaters where available and a small script that checks bundle versions against a curated list for the rest.
It’s more manual than MacUpdater, but the upside is you control what’s checked and when. In practice, most actively maintained apps do self-update now, so the remaining pain tends to be niche or enterprise software rather than mainstream apps.
This pattern shows up a lot once content filtering becomes part of the delivery path instead of a pre-check. Failures feel “network-y” but are really policy decisions leaking into transport. In systems we’ve worked on, the hardest part wasn’t blocking content, it was making the failure mode explicit so retries and debugging didn’t spiral.
I’ve seen similar issues once hooks start doing more than fast checks. The moment they become stateful or depend on external context, they stop being guardrails and start being a source of friction. In practice, keeping them boring and deterministic seems to matter more than catching everything early.
This lines up with what we’ve seen too. The moment execution becomes non-deterministic, retries stop being a safety net and start compounding failures. Treating decisions as explicit inputs and keeping execution dumb made long-running workflows far easier to reason about.
One distinction that’s mattered for us is keeping the “reasoning” layer separate from the execution layer. When tools blur those boundaries, small ambiguities turn into hard-to-debug behavior. Clear hooks and deterministic workflows made iteration much calmer as projects grew.
Visual explanations like this make it clearer why models struggle once context balloons. In practice, breaking problems into explicit stages helped us more than just increasing context length.
One thing that helped us as codebases grew was separating decision-making from execution. Let the model reason about intent and scope, but keep execution deterministic and constrained. It reduced drift and made failures much easier to debug once context got large.
I’ve noticed the same pattern. Most “rules” break down once systems get long-running or stateful. Separating decision-making from execution solved more issues for us than any single framework change.
This matches my experience too. Rust really shines once the app grows beyond simple flows. The upfront friction pays off later when debugging and concurrency issues would otherwise start piling up.
In reactive systems, we’ve found the learning experience improves a lot when users can inspect how a value changed over time, not just its current output. Do you see Weft moving toward any kind of execution history or state timeline, or are you intentionally keeping it minimal for teaching?