[asadjb]

Love this! I haven't used Beanhup, but was a user of text based accounting systems (beancount, hledger) for many years to track personal expenses. I stopped doing it when I realized I wasn't getting much out of it, but the knowledge of double-entry accounting still helps me to this day when I keep track of my business expenses in Xero.

One thing which I disagree with in this article is the focus on file based data storage:

> That makes it 10 times harder because you need to parse the text file, update it accordingly, and write it back. But I am glad I did. That guarantees all my accounting books are in the same open format.

This quote captures my issues with it. It just makes things so much more difficult; and it makes the whole process slower as the file grows. I remember that when I used hledger for tracking my expenses over 3 years, I had to "close books" once a year and consolidate all the transactions for the past year into 1 entry in a new ledger file to keep entry/query operations fast.

I get the sentiment; you want open data formats that remain even after your app is shutdown. But you can get the same by using open formats; maybe a sqlite DB is good enough for that?

The only thing that would be more complicated with a DB is versioning & reviewing commits like this app does; which does seem like a very exciting feature.

[packetlost]

I'm not at all familiar with text-based accounting tools, but I feel like the performance issues could be addressed by using multiple files instead of one big one.

[jimbokun]

Then you are slowly building a database engine.

When do you split the files? How do you track which data resides in which files? Does one file represent one kind of data (table)? Does it reflect data within a given time range? Do you sometimes need to retrieve data that crosses file boundaries?

You quickly lose the simplicity inherent in saving to just a single file.

Which is where Sqlite shines. It's a single file. But with a full, user defined schema. And can update it and query it incrementally, without having to read and write the entire thing frequently. It handles all of that complexity for you.

[fangpenlin]

Some people, myself included, prefer text-based files as a user interface. Like, some Vim users won't leave their Vim session forever and would like to do everything in it. While SQLite is immortal software and will probably be there forever, using it means changing the UI/UX from text files to SQL queries or other CLI/UI operations. I think it's a preference for UI/UX style instead of a technical decision. For that preference of UI/UX, we can push on the technical end to solve some challenges.

[packetlost]

> Then you are slowly building a database engine.

> When do you split the files? How do you track which data resides in which files? Does one file represent one kind of data (table)? Does it reflect data within a given time range? Do you sometimes need to retrieve data that crosses file boundaries?

Not really. Splitting anywhere from per-day to per-year is probably fine! Or split arbitrarily and merge the files at runtime. Make it configurable! Add tools to split or merge files, it's really not that hard, a far cry from a database engine.

> You quickly lose the simplicity inherent in saving to just a single file.

No, you really don't.

> Which is where Sqlite shines. It's a single file. But with a full, user defined schema. And can update it and query it incrementally, without having to read and write the entire thing frequently. It handles all of that complexity for you.

That you need a particular tool or library to interact with.

I'm not going to try and sell you on the benefits of using plaintext tools because you've already clearly made up your mind, but there are reasons even if you can't see them. SQLite has like 160k lines of code complexity that isn't necessary and is inherently less composable.

[fangpenlin]

Hi, the author here.

I get where you're coming from. My books are also growing big right now, and indeed, they have become slower to process. Some projects in the community, such as Beanpost [1], are actually trying to solve the problem, as you said, by using an RMDB instead of plaintext.

But I still like text file format more for many reasons. The first would be the hot topic, which is about LLM friendliness. While I am still thinking about using AI to make the process even easier, with text-based accounting books, it's much easier to let AI process them and generate data for you.

Another reason is accessibility. Text-based accounting only requires an editor plus the CLI command line. Surely, you can build a friendly UI for SQLite-based books, but then so can text-based accounting books.

Yet another reason is, as you said, Git or VCS (Version control system) friendliness. With text-based, you can easily track all the changes from commit to commit for free and see what's changed. So, if I make a mistake in the book and I want to know when I made the mistake and how many years I need to go back and revise my reports, I can easily do that with Git.

Performance is a solvable technical challenge. We can break down the textbooks into smaller files and have a smart cache system to avoid parsing the same file repeatedly. Currently, I don't have the bandwidth to dig this rabbit hole, but I already have many ideas about how to improve performance when the file grows really big.

[1]: https://github.com/gerdemb/beanpost

[asadjb]

Thanks for responding and your thoughts! Generally agreed with all you said.

However, I feel like maybe a different approach could be to store all the app state in the DB, and then export to this text only format when needed; like when interacting with LLMs or when someone wants an export of their data.

Breaking the file into smaller blocks would necessarily need a cache system I guess, and then maybe you're implementing your own DB engine in the cache because you still want all the same functions of being able to query older records.

There's no easy answer I guess, just different solutions with different tradeoffs.

But what you've built is very cool! If I was still doing text based accounting I would have loved this.