There’s just one slot left for the Alloy Workshop! Use the code
YARLSNARTH for $1200 off.
Toxx clause is still in effect: if I don’t have a complete first draft by the end of this month I’m giving 1,000 USD to a random subscriber. Currently about 7k words in.
…I never said it had to be a good first draft.
No software lessons here, just me reminiscing about a weird thing I discovered.
NOTE: I included links to a community I’m being spicy about. Please don’t be jerks to them. That means, among other things, don’t post until you’ve spent time lurking and learning community norms. Thanks.1
So it was back in the utopian days of 2016, when our president could read and I worked as a back-end engineer at eSpark Learning. I was the maintainer of one of our complex legacy systems that had accidentally become a distributed system, leading to all sorts of chicanery. I had just fixed a critical issue by, and I swear this was the best engineering decision we could have made, adding a message queue that spun up an automated browser to click buttons on a vendor’s GUI. It saved our butts but really underscored to me that this system was bad and getting worse. It wasn’t enough to just apply familiar engineering practices, I had to treat it as a distributed system first and radically rethink how we were going to maintain it.
(The system did get worse, leading me to discover TLA+ and permanently changing my career. But that will all happen several months later.)
So I went to searching. I needed an approach to distributed system architecture that 1) would make things easier to reason about, 2) could be implemented with Rails, and 3) scratched my eternal love of extremely weird tech. I had also unrelatedly done horrible things with AWS Data Pipelines2 and favored the idea of seeing everything as a directed graph, of information flowing from nodes to other nodes. I envisioned something like a circuit, or an effectful ETL, or a network of firing synapses. I wanted asynchronous queues and pub-sub meshes.
Looking back, I probably “wanted” something like Smalltalk-style OOP or an actor model or Petri nets. But instead I discovered flow-based programming. According to the Wikipedia entry:
FBP is “a programming paradigm that defines applications as networks of “black box” processes, which exchange data across predefined connections by message passing, where the connections are specified externally to the processes. … FBP is a particular form of dataflow programming based on bounded buffers, information packets with defined lifetimes, named ports, and separate definition of connections.
I immediately latched onto it as a potential solution to all of our problems. This was a way of thinking about our product as a holistic system, not just a bunch of services stirred around in a big ol’ pot. It could work as well with Ruby as it did with Java or Erlang. If we just organized things in an FBP way, then I could easily debug everything we had and I would’t have to sleep in the office anymore!3
There was just one problem: all the examples of the time were way too abstract for me. There were sketches of toy examples that showed some diagrams and said that they worked but didn’t show what FBP looks like as a production system. There was nothing deeply comparing and contrasting the FBP way of doing things from the barbaric way. There was nothing talking about the patterns and where you’d start with implementing this in an actual system. So it was cool in theory but I needed something talking about practice to actually put it in practice.
Now there was a book for sale, but I completely ignored it for some reason and looked for free material instead. I started trawling online. The website is good now but wasn’t back then and had very little information. Nobody seemed to have heard of it in any of the programming circles I was in.4 I couldn’t even find any mentions on Hacker News or Reddit programming, which at the time I thought represented what “the broader community of tech” thought.
And then I found the Google Group. Wasn’t really linked anywhere, kind of hard to find if you’re not looking for it. But it was there, it was active, and the inventor of FBP was even answering questions! I could go here and read what the inventor himself had to say about things! I could finally learn FBP inside and out!
All that excitement went sour when I clicked on the very first topic and read this:
If I were of a suspicious frame of mind, I would think many of you are still thinking procedurally, not data flow! :-)
Now this might not seem like a lot to you, but it was a huge red flag to me. It’s one thing to say that FBP has a different mode of thought than imperative programming, but it’s quite another to accuse someone of not thinking right about this problem. It’s a bit tongue-in-cheek, sure, but as my introduction to this space? It put me in just the right suspicious frame of mind to notice the some other warning signs:
This isn’t a revolutionary paradigm that would reshape the world, it’s a cult!
Okay that’s a little bit harsh. And I’m sure they’re all nice people. But in aggregate, these things create an outside view that FBP is not nearly as powerful or important as these people believe and that their judgment on things isn’t necessarily trustworthy. If they say something like “mutable information packets is essential to FBP”, they haven’t been truly challenged on it in a way that would make me believe it can withstand such a challenge. And I don’t think these people have done the absolutely critical hybridization with other ideas that FBP would need to mature.
(Couple important tangents: just because the community is this way doesn’t mean that FBP can’t be useful to people: NoFlo and NiFi are both FBP systems, though the FBP community would argue that they’re just “FBP-inspired”. Also, FBP is very similar to the general principles of dataflow programming, which has been independently invented in a lot of places and is considerably more popular than FBP.)
Of course, at the time I wasn’t interested in what it meant for FBP to be “cult-like”, I was just looking to make better systems. This all spooked me enough that I dropped it and went onto other ideas, like property-based testing and (eventually) formal methods. When I started writing about formal methods, I thought again about FBP: what could I do to not make FM seem cultish? Some of the things I’ve tried:
I think I’ve been mostly successful with this. Of course it’s not just me, FM is a broad space with a lot of different people in it, most of whom have never heard of me. But I think I did a much better job by trying to avoid the failure modes I saw in FBP. I think these lessons might apply well to any community that’s trying to grow.
Okay I lied I guess there is a software lesson here!
I don’t expect this to be a problem, but I’d rather play it safe here. ↩
To be fair to eSpark this only happened once, and it was a few months after my brief affair with FBP. ↩
story of my life right there ↩
the von Neumann architecture is a surprisingly common scapegoat in a lot of communities. Here’s a good takedown of why blaming it is misleading. ↩