4 ms·

I've been using ledger (the original one) for the last couple of months, and I'm loving it. I'm way into the whole plain text accounting thing. I guess it's th

by OskarS 7y ago

I've been using ledger (the original one) for the last couple of months, and I'm loving it. I'm way into the whole plain text accounting thing. 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?

PhilippGille 7y ago
This answer in their FAQ contains some differences: https://github.com/simonmichael/hledger/wiki/FAQ#features https://github.com/simonmichael/hledger/wiki/FAQ#features
smichael 7y ago
As hledger's proud parent, having preferred it for my needs since the early releases, I can talk about this for a long time. :) The https://hledger.org/FAQ https://hledger.org/FAQ addresses it, as PhilippGille mentioned. I still find it hard to answer concisely. Let me give it another shot: 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..
- benj111 7y ago
  "be robust and dependable, with few user-visible bugs" Not wanting to come across as too argumentative :). I'd prefer if there had to be bugs that they were user visible.
  - smichael 7y ago
    Good point. By "user-visible" I mean "any real problem a user could recognise if it was pointed out to them". Such as a wrong sign, wrong decimal digit, or behaviour not agreeing with the docs.

by OskarS 7y ago

PhilippGille 7y ago

This answer in their FAQ contains some differences: https://github.com/simonmichael/hledger/wiki/FAQ#features https://github.com/simonmichael/hledger/wiki/FAQ#features

smichael 7y ago

As hledger's proud parent, having preferred it for my needs since the early releases, I can talk about this for a long time. :) The https://hledger.org/FAQ https://hledger.org/FAQ addresses it, as PhilippGille mentioned. I still find it hard to answer concisely. Let me give it another shot: 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..

benj111 7y ago
"be robust and dependable, with few user-visible bugs" Not wanting to come across as too argumentative :). I'd prefer if there had to be bugs that they were user visible.
- smichael 7y ago
  Good point. By "user-visible" I mean "any real problem a user could recognise if it was pointed out to them". Such as a wrong sign, wrong decimal digit, or behaviour not agreeing with the docs.