B-threads: programming in a way that allows for easier changes

The problems with this approach seem solvable to me, albeit with more experimental magic that could explode:

- The resulting big ball of mud (and subsequent performance problems of a long pipeline of relations) could be compiled away, resulting in a single artifact. That is, you'd develop in append-only style, but when you "commit" your release, you'd end up with a single, optimized artifact for deployment, which would also be readable. This seems really nice to me, since your changes, while being based on the behavior of the system, would create a diff in the implementation of the system, potentially reaching way back into upstream events (in the example, the behaviors that block hot water and substitute cold water would just completely eliminate the first pane and simplify to adding cold water). This would let you see your changes from multiple perspectives. This approach also seems really friendly to fuzz-testing, which would give you a third look into the behavior of the system, and you could write tests based on the final state of the system after a number of given events.

- Migrating data structures actually seems easier to me for an event sourced approach, since you'd just re-project your domain models based on the new flow of events. b-threads would allow you to re-compile your event stream just like you re-compiled the source artifact (having parameterized events remains a problem, since your historical data could end up being incomplete and invalid based on new policy, you'd have to adopt a permissive schema to keep stuff that validation would otherwise reject).

I'll agree that b-trees don't really solve anything, but they do bring up some interesting questions that I think are worth asking. Datomic and Darklang I think are much more practical, and seem to dabble in the same sort of areas.

>As a system grows in complexity we don’t necessarily care about how old b-threads have been written, hence we don’t care about maintaining them.

This post is essentially formalizing the process of creating a Big Ball of Mud[0] that is so complex and convoluted that it is impossible to understand. The motivation for formalizing this process seems sane and with good intentions: to add functionality quickly to code you don't really understand. Normally, doing something like is considered cutting corners and incurring explicit technical debt, and must be used sparingly and responsibly. However, the process of "append-only development" is embracing the corner cutting and technical debt as a legitimate development process. I can't get on board with this.

To be more specific, with an example (and maybe I am wrong in understanding the post, this would be the time to point that out to me), let's suppose you have a massive complex software system that was built over the years with this "append-only" style of development. One day you find a nasty bug in one of the lower layers, and to correct it, you have to change some functionality, which moves/removes some events that subsequent layers are depending on for their own functionality. Suddenly, you are faced with rewriting all of those layers in order to adapt to your bugfix. What you're left with is a nightmare of changes that disturb many layers of functionality, because they're all based on this append-only diffing concept: the next layer is dependent on the functionality of the previous layer.

This is what programming APIs are for: to change functionality in lower layers with minimal influence subsequent layers. This post and process seems to be imagining a world without APIs.

0. http://www.laputan.org/mud/

1. One commit per PR (so the commit history wasn't polluted with rough drafts and debug logs and such) 2. Every PR links to a bug 3. Design discussions happen in bugs

Then when you see some weird code, you can "blame" back to the commit, and from there look at the bug to see why the commit was needed. We also really encouraged people to separate refactoring from new features (refactor first, in a descriptive PR, then add the feature), so that you avoided the problem of seeing a complex refactoring in a PR called "add foo"

I agree with other commenters that encoding the design history of your project in its operation doesn't seem helpful, and in my opinion that's because it's solving the wrong problem. Finding the places in a complicated project that need to change is only hard because knowing, to a fairly complete degree, how the system already works is hard, and knowing how a system already works is mostly the product of understanding the problem that it solves deeply. Experienced engineers on a project usually have no problem figuring out which parts of a system need to be changed, because they already know the system well, and they don't know they system well by virtue of having all the code memorized, which would be impossible, but by having participated in all of the design discussions.

Therefore, the problem that needs to be solved is making the learning process as fast and easy as possible—thus the strict process around documenting changes and their motivation. Allowing people to quickly discover the existing code's motivation gives them the information that will actually need be committed to memory.

I'm reminded of the golden hammer fascination with event sourcing, and I continue to see event sourcing applied inappropriately. Is it useful for some specialized applications? Yes, and it's a great tool there! But should it be the default tool you reach for to solve most problems over a relational DB and your most trusted, high level, stable programming language with a mature library ecosystem?

No to that question, and no to this.

(I still program all my side projects in this way.)

My thoughts on this are: append only programming is less effectual than having an over all append only system, where many programs take input (including the original source "message"), then hand off the out put to the next program in line. Which programs get run depends entirely on that run context's configuration. When you have disparate programs working towards a final goal, and these programs are defined in a readable configuration it gives you quite a few benefits. Good clean logging structures, easy to reason about, easy to change (feature toggling, data migration points, etc), and easy to clean up when required.

I call it unix'ing your systems.

There's a lot of comments calling this silly but please attempt to give it a few read overs and apply it to systems you've worked with. Hopefully they've been large enough to draw similarities to what he's talking about in a very clean, academic manner.

But the chart in graph 1 still applies, often when adding new functionality you realize you need to add or remove modularity and extensions.

1. You can’t see the blocking in the event stream behaviour so your change might mysteriously fail to work. I wasn’t super clear on what the semantics were but I think the last change to not show ads to enterprise customers accidentally breaks the normal case and causes the program to lock up once it hits isValid. Normal program changes also suffer from accidentally breaking existing behaviour. Especially eg a change to a superclass breaking subclasses or accidentally mutating some global state or throwing an exception in the wrong place.

2. There are lots of possible event streams and it is hard to predict how well your change will behave under all of them. This is also a problem for any sufficiently large and modified program.

3. You can’t block a block, so it is hard to undo modified behaviour in some cases (this is what causes the atm to lock up after the last change (if I’m right in thinking it does))

However I don’t think this means that this is a pointless area of research. It may be that good ways of dealing with these things are eventually devised. And the idea of lots of small processes doing simple things coming together to make something which holistically behaves in a smart reliable and resilient way seems popular and reasonable (eg see copycat).

One good thing about this method would be testability. A test can be just another bthread (or more) running in the system followed by printing a trace of the events. That way one might easily know if some existing behaviour is broken because the printed trace would change.

Another similar idea (without necessarily requiring append-only programming) is one from eve and a talk I don’t remember the name of where one writes prolog-like rules to manipulate a set of known facts over time. This also suffers from difficulties with negation.

I suppose a general idea is that with these “bag of interacting rules” systems (which seem a good start for building complex systems which can be modified and tweaked reliably and resiliently) it is hard to have negatives (thus blocking) and in particular very hard to have reliable double negatives (blocking a block).

So what is the solution? Well I don’t know and it seems that any answer could be unsatisfactory. One possibility could be to allow for more probabilistic or otherwise weighted behaviour but this seems bad for reliability of results. Another idea is to disallow negation but this seems to make everything hard. Another idea might be to somehow make synchronisation points better.

If your program is constructed this way at every layer of logic, not only will your program be amenable to append only styles of programming. But it will be amenable to decomposition. Often you find that your primitives are too big and you need to split your primitives... well if your primitives are itself made out of the compositions of lower level primitives then breaking apart that function is trivial.

There is only one primitive in all of programming that follows this composition rule. Procedures cannot compose, Objects cannot compose. What's left?

Difficulty in updating software isn't a new problem - but we already have much, much better solutions than this. I don't think there's anything wrong with changing existing code - and if changing existing code is causing you so much pain that you're led down this route, then you probably have bigger issues.

Maybe this methodology just isn't for me - but I really don't see how this improves anything from a development perspective. I only care about the current state of the code - and if I need to care about the previous state of the code, then I just check the history. The idea of having to understand the entire history of a codebase just to grok the current state seems insane.

For one, its not clear how this aids easier development - hasn't it just shifted understanding of a complex program to understanding a complex overlapping sequence of b threads instead?

Secondly, and I think the nail in the coffin, the compiler would have to be brilliant at optimisation to make the final program performant. The idea of 'show ads' later being disabled by another overlapping b thread - does this mean the network request is never performed? Or is it performed and the result thrown away, wasting resources. How would an 'offline mode' requirement be appended as a b thread in such a case?

Just today, I had to write a simple navigation menu. Suppose that I have pages to navigate to that have /a/ through /n/. I abstracted away the button, but I didn't write a loop to loop over each route entirely. Why? Well, based on user interactions I might want to have the buttons change shape or color and I don't want to have to go back and unwind that abstraction.

Some people will look at that code and say its not DRY. Well, I like to make code WET - write everything twice. There is some ideal amount of boilerplate as well just so someone can read and understand the darn thing - if they have a few examples to play with it'll be much easier for them to understand. Also, it amuses me how much stake people put in nonsense acronyms, as if some sort of borrowed linguistic authority will cover ineptitude and not thinking for oneself.

Ultimately this looks like an over engineered technical fix for what amounts to a social problem. Coding is ultimately a social issue (unless you're out there grinding out 1s and 0s on cuneiform tablets) and requires social solutions.

You don't know if anything will work or continue to work due to being randomly blocked or otherwise interfered with by code that either already exists or will be added tomorrow.

Basically this is just flow-based programming (FBP) in a new form.

https://en.wikipedia.org/wiki/Flow-based_programming

Every new generation of coders reaches a puberty characterized by uncontrollable excitement with multiple threads of control doing little things independently.

For example, if I had to add a widget to a form, I could copy the implementation of an existing, similar widget and then make the necessary changes to it.

Similarly, I had to change the datatype of a field from string to integer all the way from the UI back to the database. This was fairly easy because I could make the change at one level, and then run the compiler to see what my change broke one level up. Fix, rinse, and repeat.

If I had to do any of this without access to the existing code, it would've been 100x harder.

In the end, our code is complex because what we want to achieve is complex. Sure sometimes programmers add some extra complexity on top for no good reason, but there's a certain level you just can't get away from.

Moving the complexity to understanding event streams does not seem to be any improvement at all, at least as far as explained in the article. The toy examples were entirely too simple to give any real sense of how this could work in practice.

All of regular programming methodologies apply with b-threads. And most of the time changing requirements would require one to change the b-threads involved in that requirement. The append-only analogy was really more to showcase the feature of incrementality.

Technically one can develop a complicated system just via append-only but again you'll likely better off having clean b-threads that deal with specific behavior organized in specific and clean ways the same way we organize any other software.

From the comments it seems I wasn't successful at highlighting the key insights of this paradigm. One read that I suggested in this article that does a much better job at explaining these concepts is "The quest for runware: on compositional, executable and intuitive models" [1] where the authors essentially describe the need for something like Behavioral Programming (authors are the creators of BP). Some quotes from the paper:

> As mentioned earlier, it will be possible to represent new requirements, or changes thereof, in a new behavioral component or module, with minimal change to the previously specified parts of the model, and without sacrificing executability and manageability. Such modules will be simply added to the existing model, virtually ‘piled-atop’ it, with no component specific interface, connectivity, or ordering requirements.

> In our vision, the units of the specification and models are not assembled in detail like resistors or chips on a computer board, or methods and fields in an OO-programming object class. The interweaving of behavioral modules will be facilitated by their reference to common aspects of system behavior described using shared vocabularies (for example, common events), and not via mutual awareness and direct communication between components. From the point of view of such a module, the other modules could be transparently replaced by new ones. In fact, the implementation of any part of the specification or a model should be replaceable by some kind of ‘invisible box’, whose implementation remains a mystery, and the effectiveness of the remaining modules and the integrity of the overall system behavior will be preserved.

And from the conclusion:

> What will happen if and when the human way of expressing requirements for systems will become almost indistinguishable from the way this is done with computer programs? And what will be the result of a level of compositionality that would allow humans to add capabilities to a system with much less dependence on that system than is possible today?

> When a collection of specification units grows over time, accumulating an unmanageable collection of patches, exceptions, and enhancements, it is likely developers will call for merging or refactoring them into much more concise artifacts. The new modules will replace the existing collection in all its uses (final executing system, official record of the specification, and means for communication between humans) without changing other parts of the specification. Such refactoring will be acceptable, even if it ends up being done manually, as it will focus on capturing the human’s revised perception of the affected behavior.

1. http://www.wisdom.weizmann.ac.il/~harel/papers/Runware.pdf

Maybe I'm missing some key insight, but this process seems like madness to me.

> Then we wouldn’t have to read and understand where to squeeze our changes. We’d simply add stuff based on the new requirements and things would somehow magically work.

But, at some point, someone has to understand if those requirements clash with the old ones that are currently implemented. The hot/cold water example is, I think, telling. At no point in the article does the author actually state what the requirements (new or old) are. You have some program that, whenever the water level gets low, adds three hot waters. I guess that was some original requirement.

Then another b-thread is added that also adds three cold waters. Now whenever the water gets low, twice as much total water is added. Presumably that's OK? When the second b-thread was added, was the requirement to fill the container with cold water instead of hot, or was it to fill the container with twice as much lukewarm water?

Finally, the third b-thread is added that interacts with the two previous ones to cause the hot and cold water adds to be interleaved. What requirement does that meet? The stated purpose of all of this is that you don't need to understand the original program to modify it, but the entire purpose of this third thread is to interact with the previous two. You have to know there are already two b-threads going, which events they listen to, and what they yield in order to create the third thread that blocks them. So I don't see how this is any better than needing to read the code in a normal program.

I feel like I'm taking crazy pills.