Live data from Hacker News

GnuCash 5.9

gnucash.org

161–170 of 179 posts

Re: GnuCash 5.9

#161

Earlier quoted context omitted.

I was going to say what GP said, but, yeah, XSLT is just no fun to write by comparison to SQL.

Hardly anybody was using XSLT even when XML was all the rage. Python scripts work just fine.

XSLT 1 was very limited. XSLT 2 was too late. That's my take. I actually like XSLT 2, but it's so verbose... -- it's horrible.

Once in a while I dream of adding proper XML support to jq just to be able to use jq as a pithy alternative to XSLT.

Re: GnuCash 5.9

#162

I looked carefully at GnuCash before settling on Beancount (or plain-text accounting in general) for personal finance software. The deal breaker for me was the underlying XML or SQLite formats of GnuCash. These are not terribly amenable to scripting, either for ingesting raw data or reporting. Whereas this is basically the point of plain-text tools like Beancount or HLedger. GnuCash feels too much like a walled-garde…

To each their own I guess: my experience is the exact opposite. Plain text looks simple to human eyes but parsing it in a structured way is a nightmare and scripting edits to plain text is a mess. Databases on the other hand are built for this. After years of dissatisfaction with plain text accounting and many hours spent trying to improve it, I now use SQLite and it has been an enormous improvement.

Part of the reason I settled on beancount over h/ledger was the ease of writing python plugins to handle mutations and rules, and reuse the official parse/output as a library.

Plaintext is nice for git but I only feel that when fixup-ing a single or small number of transactions. It does feel nice to be have all the details of a transaction in one place in a visually useful way. For one-off hacking and such it definitely feels easier to write O(n^4) python looping over trying to describe things with SQL and working at a scale where it doesn’t matter.

Plaintext as a UI into a SQL store seems an interesting project. I would love a git integration for committing changes after diff review and being able to stage individual txns or parts. Many years ago I was frustrated with ledger’s more loosey goosey syntax and trying these things and eventually gave up whatever the idea was at the time. I like the idea of a constant bidrectional sqlplaintext that provides a requirement for reproducible parsing and serializing

Re: GnuCash 5.9

#163

I looked carefully at GnuCash before settling on Beancount (or plain-text accounting in general) for personal finance software. The deal breaker for me was the underlying XML or SQLite formats of GnuCash. These are not terribly amenable to scripting, either for ingesting raw data or reporting. Whereas this is basically the point of plain-text tools like Beancount or HLedger. GnuCash feels too much like a walled-garde…

Beancount + Fava looks like a pretty slick combo. Can anyone describe experience with it ?

Re: GnuCash 5.9

#164

GnuCash is solid. One thing that I love: I have full control over my data, and its stored as a simple xml (also supports SQLite, but why use more complex when simpler works just as well?) I have a few (comparatively minor) complaints about GnuCash, but they're around UI. Things like: it would be nice to assign all matching (eg Regen) transactions to a selected account, and stuff like that. But overall, having somethi…

I would argue xml is more complex, but to each his own. :)

It might be easier to use, but it's not a simpler technology.

Re: GnuCash 5.9

#165
post #105

Earlier quoted context omitted.

It's great for personal or very small businesses but god help you if you are building a real startup with GNUCash. I am speaking from experience here, GNUCash zealotry is a plague. I honestly wish this project basically did not exist, because the business world despises GNUCash, ONLY cares about QuickBooks, and using anything else is a giant waste of everyone's time. Believe me, I have been fighting this fight in non…

> Your bank will hate you Why? Surely all US banks use open, standardized data formats to export financial statements and to execute transactions in bulk? Or are you thinking of another reason? US banking is a shitshow which is decades European banking, addressing that would benefit everyone. > Your investors will hate you Why? Surely your investors are interested in accurate accounting? Can gnucash not generate some…

> US banking is a shitshow which is decades European banking, addressing that would benefit everyone.

The problem that I (and many business owners) are solving for right now is not one of federal policy, but rather an economic one: I like to have food on the table to eat. I care very little about whether or not I'm doing that in a way that satisfies open source zealots.

If there's an open source option that lets me do what I need to do in an equal or better way, then sure: happy to go that route. But I'm not doing something in a clunky, nonstandard way just for the lulz.

Re: GnuCash 5.9

#166

I looked carefully at GnuCash before settling on Beancount (or plain-text accounting in general) for personal finance software. The deal breaker for me was the underlying XML or SQLite formats of GnuCash. These are not terribly amenable to scripting, either for ingesting raw data or reporting. Whereas this is basically the point of plain-text tools like Beancount or HLedger. GnuCash feels too much like a walled-garde…

To each their own I guess: my experience is the exact opposite. Plain text looks simple to human eyes but parsing it in a structured way is a nightmare and scripting edits to plain text is a mess. Databases on the other hand are built for this. After years of dissatisfaction with plain text accounting and many hours spent trying to improve it, I now use SQLite and it has been an enormous improvement.

Not to go off topic - this story did inspire me to install gnucash again and enjoy the GUI -

> parsing it in a structured way is a nightmare

Ah, well that’s the job of the PTA app - converting “just text” to something very structured and validated. Which can then be moved into SQLite, if one likes.

> and scripting edits to plain text is a mess.

I suppose it depends. There are a lot of very powerful and quick tools and techniques for automated or assisted text munging.

Re: GnuCash 5.9

#167
post #137

Earlier quoted context omitted.

Can you share a link to the docs for the scripting engine? I've seen conflicting information over the years and I'm not sure what the latest really is.

Internally, it uses Guile. I'm afraid there might not be a good user interface to edit the Guile source files, but at least Guile is much more pleasant to work with than C and offers way less paper cuts. I think it's mostly used for reports. You might have to create a plugin to expose your own scripts in the UI.

I feel like it could do with some tutorials and guides on Guile. I would have liked to be able to do reporting and invoicing with more control through scripts, but last time I looked at it I just gave up due to lack of docs.

Re: GnuCash 5.9

#168
post #83
post #77

Earlier quoted context omitted.

Why is it inexcusable? And what standards? This is for serious finance, not for swiping yolo stonks on Robin Hood.

Well, the applicable standard in this case would be “Web Development” writ large. Responsiveness is a start, but consistency is one of the most important design principles, and this site seems to disrespect user expectations about layout, menus, and interactable elements, from a glance. Responsiveness in particular is “inexcusable” to miss because it’s so easy that it’s practically boilerplate these days, and the lac…

I don't know what you mean by "responsiveness". Html/Css/Javascript is dogshit when it comes to latency. I assume you're talking about fluid layouts, which can be accomplished just as well with native GUI libraries like Qt. Note that Qt runs like a champ in embedded devices; I don't think it can possibly get more responsive than that.

> and this site seems to disrespect user expectations about layout, menus, and interactable elements, from a glance.

Why does this matter? GNUCash is a desktop application. The website is not all that relevant. And I have a different opinion about expectations anyway. The website is functional and easy to navigate, unlike the column-style, white space wasteland that "mobile-friendly" websites typically are.

Re: GnuCash 5.9

#169

Earlier quoted context omitted.

Come on, of course Hacker News is a local Bay Area forum, nothing happens beyond Bay Area ever. /s And even this post only lists English-speaking countries, as the Babylonian barrier is impenetrable. Who knows what happens in these strange places where people communicate in unknowable sigils?

India had / has a bunch of indie vendors of small financial accounting packages (that's what it is called here), some years back and for quite a while before that. When a new Indian software product company starts up, this is often the field they enter first, partly because the domain knowledge is widely available via chartered accountants and is fairly standardized, I think. Not an expert in the field myself. I don'…

> When a new Indian software product company starts up, this is often the field they enter first

This doesn't ring true to me. It's almost impossible for a new accounting suite to find traction because Tally is the defacto standard. The only successful newcomer I can think of is Zoho.

Re: GnuCash 5.9

#170

Earlier quoted context omitted.

It's great for personal or very small businesses but god help you if you are building a real startup with GNUCash. I am speaking from experience here, GNUCash zealotry is a plague. I honestly wish this project basically did not exist, because the business world despises GNUCash, ONLY cares about QuickBooks, and using anything else is a giant waste of everyone's time. Believe me, I have been fighting this fight in non…

We used GNUCash for a few years for small business accounting. After a while we migrated to Quickbooks Online as it has some features that GNUCash was missing, e.g., automatically pulling in PayPal and bank transactions and inventory management. This turned out to be a very frustrating experience. Due to the following: - The price increased every year. We started at about $60/month and after a few years it $80/month.…

> ERPNext is not perfect, but works quite well

This. ERPNext can be quirky and annoying at times. But it is still better than dealing with the ever-changing quriks and annoyances of an online suite that you have not control over.

Post reply on HN