Bthreads: A Simple and Easy Paradigm for Clojure
(thomascothran.tech)85 points by refset 8 days ago | 9 comments
refset 3 days ago | root | parent | next |
Agreed, I would love to see a large scale implementation and experience report. I also wonder about combining the Bthreads model with the notion of 'durable execution', as demonstrated by the folks at DBOS: https://www.dbos.dev/blog/what-is-lightweight-durable-execut...
regularfry 3 days ago | root | parent | prev |
"Append-only" was the original intent behind "closed for modification, open for extension": this exact idea goes as far back as Eiffel, at least, which used implementation inheritance for it.
thom 3 days ago | root | parent |
On the tactical level, absolutely. But the poster child at a more system-wide strategic level is the classic bogeyman of a Java codebase ruled by XML config and dependency injection of overly-abstract components. And many parts of our codebases remain rigidly hierarchical, like trees of UI components. What would it take for us to be able to deliver new features as a completely independent vertical slice? Micro frontends get some of the way there, perhaps?
refset 8 days ago | prev | next |
Context from the previous post in the series:
> Behavioral Programming is a relatively new programming paradigm that excels at isolating and composing behaviors in event driven system.
> Behavioral programming was invented by David Harel[0], who also invented statecharts in 1987. It uses independent units of behavior, called bthreads, which are coordinated in a pub-sub protocol.
[0] https://cacm.acm.org/research/behavioral-programming/ (2012)
compressedgas 4 days ago | root | parent |
So is Behavioral Programming equivalent to Synchronous Reactive Programming?
compressedgas 3 days ago | root | parent |
pron says "Behavioral programming is built on top of a paradigm called synchronous programming": https://news.ycombinator.com/item?id=19822463
refset 3 days ago | root | parent |
Interesting, thanks for digging that answer out. HN is a treasure trove!
elcritch 4 days ago | prev |
This seems like it could be promising for embedded and real time event handling. I dislike async programming.
Though it seems possibly similar to ECS systems? Can anyone comment on that aspect?
thom 3 days ago | next |
It's an interesting paradigm. I would be very intrigued to see this implemented at scale, with all sorts of cross cutting concerns (logging, persistence, multiplayer and auth, displaying an error message when you try an illegal move or confirming when you win etc). Feels like a lot of COMEFROM-style code if you're not careful. That said, I am fascinated by the idea of append-only codebases - what would it look like if we performed less surgery inside our codebases, and instead merely added to them or overrode bits of them as time passed? I think most people would recoil in horror at the thought, but in a way a lot of long-term architectural decisions are made to support that kind of change in a system. How could we make that more natural? The behavioural programming approach certainly lends itself to more agility via extension rather than rewriting.