So long a thread. I appreciate the flowers but let's not forget the original idea is a John Wiegley creation, I merely copied and then iterated and recreated a few times. Simon Michael also accumulated a following with his Haskell work. Credit where credit is due.
Re. BDFL indeed I don't have time. I'm giving all my cycles to someone else at the moment. (Thankfully doing lots of agentic stuff so it's not like I have FOMO.) I think the idea of having unified tests is a great one but it's unlikely to happen, people enjoy the 0 to 1 feeling mostly and this won't change with agents. Maybe you can extract all the tests from my source code and find a way to them across equivalent systems (see how I assert some things in the beancount syntax itself, you don't necessarily need code, you can create a syntax). The main challenge to new implementors is going to be completeness. With the AIs zero-to-0.8 is almost instant; your enemy will be 0.8 to 1.0. Lots of little details to care for. On Fri, Feb 27, 2026 at 9:51 PM Justus Pendleton <[email protected]> wrote: > I think it is a great idea to encourage experimentation and evolution of > the fileformat/featureset. > > My feeling is that Martin probably doesn't have the bandwidth to play any > significant BDFL-type role commenting on various proposals or shepherding > towards consensus. So the beancount family is probably better served with > something a bit more free-form. I could see value in a centralised > repository where alt-beancounts could post "hey, here's what I'm trying > out", a bit like we've seen with the various flavours of markdown over the > years which also don't have a BDFL but have evolved in a bit more chaotic > fashion. > > I think the biggest value-add at the moment would simply be some kind of > unique number for each change from vanilla-beancount so people could talk > about "change #12 in limabean is easier to use but less powerful than the > similar change #26 in prolog-bean" and provide a focus for discussions like > RFCs do. I can't imagine trying to enforce too much structure on either the > document or the process would be very useful, simply because I imagine most > people writing alt-beancounts aren't terribly invested in writing long > documents in prescribed formats for what is still largely a personal > project. > > But if you have more lightweight examples from smaller projects (i.e. not > rust or python which understandably have rigorous processes) it might help > generate more ideas. > > On Thursday, February 26, 2026 at 11:25:49 AM UTC+10:30 Simon Guest wrote: > >> The Beancount developer landscape seems to be thriving at the moment with >> several recent announcements about new implementations. This is certainly >> exciting, and it's great to see such creativity. >> >> Martin has made a huge contribution to the plain text accounting >> community, both with the very well designed original Beancount system which >> we all love, and also the extensive documentation and test suite. Thank >> you indeed! These were certainly enablers for my own limabean >> <https://github.com/tesujimath/limabean>. >> >> And so now times are changing, and Beancount is in some ways being >> liberated from its Python origins. We are seeing work in Rust, Zig, >> Clojure, and who knows what to come. Exciting times indeed! But how will >> we avoid fragmentation? >> >> It is clear that in future we will have multiple implementations of >> Beancount-like systems. That is not what I am concerned about. My >> concerns are: >> >> 1. Preserving a common file format >> >> 2. Preserving common core behaviour >> >> I expect and celebrate a varied approach to user interface (Beancount >> Query Language, Fava, or Fava-like GUI, Clojure, whatever else). This is a >> fruitful area for exploration. So too, the plugin ecosystem will surely >> diverge. I agree with Moritz, the author of TurboBean >> <https://github.com/themoritz/turbobean> (cool project!) that you >> wouldn't want to embed a Python interpreter just for plugins if you don't >> already need it. And with limabean I am exploring the idea of not needing >> plugins at all. >> >> It should be easy for users to try out different implementations, which >> requires (1) and (2) above, and perhaps more. >> >> The vNext document <https://beancount.github.io/docs/beancount_v3.html> >> has some interesting ideas, which explains TurboBean diverging with a new >> approach to inventory. Is this the future? I would like to know, as I >> would then have to follow along with limabean! >> >> What I would really like to see is some kind of RFC process, like which >> is used for evolution of the Rust language and ecosystem. I hope that >> Martin would like to be the BDFL for some kind of RFC-like process which >> unifies all these parallel developments, in terms of defining core >> behaviour, *especially where this differs from OG Beancount* (in fact, >> probably only where it differs). >> >> In summary, I think we should embrace and celebrate the current >> divergence of implementation work in the Beancount ecosystem, but take some >> steps to mitigate the otherwise inevitable fragmentation. >> >> All comments welcome! >> > -- > You received this message because you are subscribed to the Google Groups > "Beancount" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/beancount/3a441c4c-5e54-4ef0-bc6d-39f7bb683923n%40googlegroups.com > <https://groups.google.com/d/msgid/beancount/3a441c4c-5e54-4ef0-bc6d-39f7bb683923n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Beancount" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/beancount/CAK21%2BhPGzU%2BFjuKh_oxXsQ7eQMcigTUVygPv%3DQPQ8Do%3DqO-iEg%40mail.gmail.com.
