I've decided to break off the current Jumbo sprint. I wrote a more detailed tech report on the "faux milestone" which you can download in the technical reports area, but I ended up feeling some qualms about how definitive that milestone really is. Does the completion of half a system rise to the momentous nature of a tech report? Probably not.

But a blog post? Sure—and I do want to explain what it is I completed, why it's interesting, and why I stopped at that point.

At the risk of repeating myself (again), this is a halfway point in the Jumbo project, which is of course why I called it "Jum". The Jumbo project is the redevelopment of Doug Hofstadter's 1982 Jumbo project that was the first implementation of the core architecture of all FARG work, the parallel terraced scan. My overall goal in this thread of my shadow doctoral work is a general recapitulation of FARG systems on the basis of a unified architectural infrastructure, and I started with Jumbo because Hofstadter started with Jumbo.

My first stab at it was in March of 2024, and came to an end with the solar eclipse—because I went to Dallas to see it, and the travel forced a very real breaking point. On coming back, I tallied up a solid list of technical debt and I had some ideas about how to do it right, but in the end it turned out the best way for me to tackle it was to split the basic terraced-scan functionality out of the project. That let me test it more thoroughly before getting down to the business of designing more involved codelet ecosystems. I finished that up in October of last year, and so this new Jumbo sprint started in early November.

The early stages were very similar to the NaiveSort domain I'd implemented for testing in October, but with more levels of complexity and thus more need for detailed test scenarios. While working on those, I started to abstract out and consolidate the various actions against the Workspace that each codelet could take. I ended up thinking about those actions as bundled "Workspace moves," and to test those right would really need another round in the terraced scan project.

Then in December, I realized that my original strategy of modeling sparks (proposed bonds) as units in the Workspace causes a lot of churn in the Workspace that could be avoided by thinking of proposals as framelets. That approach occurred to me after I found the original 1983 text of Hofstadter's paper The Architecture of Jumbo, but it had been building for a while, arguably since the night in May of 2024 when I coined the term "framelet."

Jumbo breaks down into two or possibly three categories of codelet, which Hofstadter calls entropy-reducing, entropy-preserving, and entropy-increasing codelets. I waffle on calling the entropy-increasing codelets a full category, because they're just the breaker codelets—and how much domain-specific thinking do you need to break things? They're vital, because otherwise your scan gets stuck with structure that won't work, but they're very simple.

So in real terms, Jumbo is easily divided into the entropy-reducing codelets that assemble letters up to the point where they're all in a single word-like string, and the entropy-preserving codelets that shuffle parts of already-built syllables and words around to find variants that might work better.

When I originally launched into development, I thought that sparks should be units in the Workspace because I wanted to draw the spark as part of the animated picture of the process, and I'd gotten stuck on that conceptualization by the time I started thinking about the shuffling codelets. But what corresponds to the spark in a proposed shuffle? How would you draw it? Possibly a dotted jumper line from one place to another in the string—but as I started thinking about how those shufflers would work, it seemed to me that that the shuffle proposal just wasn't the same kind of thing.

At some point it dawned on me that I had no intention at all of implementing a shuffle proposal as a Workspace change. I was already thinking of them as framelets. Since I was just about done with the entropy-reducing ladder of word assembly, I decided it was time to pull back to the support module to implement and test both moves and proposal framelets, then return to Jumbo with new tools. At first I thought to call the first half JumboLite, but fortunately I realized at the last moment a far more Hofstadterian nomenclature, and called it Jum. (The shuffling codelets will perforce be called Bo).

The code for Jum is already available on Codeberg, although I should warn you it's still a bit raw. I implemented some of the codelets using formal moves in order to make it easier to write test scripts, but I didn't follow through consistently. I'll revisit Jum once I have moves properly implemented in the Workspace itself, and properly tested in NaiveSort.

More soon!