Ruby Tumbler: preserving dynamic behavior without unnecessary work
I've gotten further than expected, and learned some fascinating things about dynamic languages.
Lynn Cole / Laboratory
Experiments, research notes, mad science, and things in progress.
I've gotten further than expected, and learned some fascinating things about dynamic languages.
I'm spending the weekend performing brain surgery on a digital fruit fly.
A digital fly already has memory circuitry. I am connecting that machinery to synthetic storage to explore what it remembers and how it learns.
The idea is that you start with a hand painted image or collage, but that you design it in such a way as that it messes up the classification and denoising systems in a diffusion model.
An experiment proposal separating activation injection, transcript conditioning, and what a model can infer after the intervention ends.
If people stop reading generated code, what should a language for the machine look like? A deliberately obnoxious compiler proposal.
Preparing a third recursive-training corpus means separating conflicting objectives and testing the order in which the student learns them.
Ruby's not my favorite language, but I find it offensive that anyone would replace a perfectly good Rails application with an app written in Rust.
Changing one activation-steering corpus turns a pain-language experiment into a useful counterexample—with a much less solemn condition.
A mentor improved the training signals but weakened Qwen’s self-assessment. The next corpus starts with code reasoning and software estimation.
Building a gesture-driven painting instrument means learning how to paint with it at the same time.
Recursive training improved correctness while weakening engineering taste. A controlled learning-rate ablation and a failed promotion gate changed the next experiment.