That site is also worth checking out for more hledger materials, such as comparisons, talks, slideshows, and blog posts. Eg Andreas Pauley's quick intro slides (https://pauley.org.za/functional-finance-hledger) or my slow "Hands-on with hedger" talk and FLOSS Weekly appearance.
I guess it's the most obvious question in the world, but: what are the big reasons I should switch to hledger? What do you see as the primary advantages of hledger over ledger?
Here are some things I've tried to do differently with hledger compared to Ledger. I feel we've had some success with all of these:
Project:
- be actively maintained and contributed to
- build out Ledger's concepts a bit more selectively/thoroughly/to a higher level of polish, taking advantage of hindsight, a fresh codebase, a well-suited language
Docs & design:
- all behaviour fully specified and documented
- all docs up to date and accurate
- practice documentation-first design and development
- more intuitive, learnable, consistent concepts and UX
- be usable for less-technical users as well as techies
- be easy to get started with as well as efficient for regular use
- explicitly try to model accounting concepts and help meet real world accounting needs
Software:
- be robust and dependable, with few user-visible bugs
- be easy to install and run well on all major platforms
- provide APIs/libs enabling more plain text accounting hacking among Haskellers
- be readable, clear, and a useful source of algorithm & architecture ideas for other implementors
- remain maintainable and cost effective over the long term
- achieve a long lifespan and provide a safe long term format for accounting data
Technology:
- clarify whether Haskell is good for real-world apps (yes!)
- learn more Haskell by building a real-world app (yes!)
- attract contributors by being a Haskell project (yes)
Out of time for now, I hope it's not too hand-wavy..
Not wanting to come across as too argumentative :). I'd prefer if there had to be bugs that they were user visible.
Our company uses a plethora of (mostly) ruby scripts to get data from banks and the billing system API and a few other sources like exchange rates websites and converts the output into ledger files. And then another bunch of scripts takes the output from ledger and sends it to the API for, for example, the government VAT payments. (Our company is by no means big, but multinational with business in 7 currencies).
There are a number of test and assert statements along the line to do sanity checks with a manual review since sending out incorrect values could potentially be expensive / illegal. It works great. The whole thing is stored in git so any changes are auditable. We need some of the power features of ledger though, so I doubt ledger will work for us, but I'll give it a spin.
I feel combined with machine learning and storing hledger records in some large databse, it can become a powerful automated accounting system which SAP and large vendors can just dream of.
Works quite well
Distant future is hard to predict but here I go: hledger or any good parts of its design are still around and still providing value. Any past data kept with hledger is still readable and easy to convert, with or without a working hledger. Highly polished and efficient UIs are available everywhere they're useful. Data import and multimachine syncing are routine and just work. Data hygiene/security and personal privacy are routine and just work. Performance is high, "big data" is no problem. Resource usage is low, these tools continue to work in the turbulent and resource-constrained future. There is a strong global community of financially literate, capable, empowered, prospering individuals and organisations using efficient high quality universally available accounting tools to promote, enforce and create widespread transparency and societal insight in finance, business, politics and every ecological issue.
1. What was the motivation to create this instead of extending ledger?
2. How to track time?
You can also fork and modify it to generate hledger format files directly.