On Fri, Sep 5, 2014 at 3:57 AM, Gour <[email protected]> wrote: > Hello, > > I'm strongly considering to switch to some cli-based repo for my > accounting needs, > [...]
> Of course, for my transactions I regularly have need for 'split' ones. > What exactly do you mean by a "split transaction"? That's pretty much everything and I wonder if ledger > - which I consider is the richest feature-wise can handle all the tasks? > Out of curiosity, what gives you that impression? It seems that hledger which is created in order to be 'little more > simple, usable, installable, documented' might not handle everything - > 'historical price records' if that's is required for having record of > exchange rate when conversion between currencies or 'automated > transactions' if that refers to scheduled transactions. I'd also like to > be able to use different (native) display formats, iow. not only > yyyy-mm-dd. > > Yesterday I was also reading some docs about Beancount, but must admit > it was not 100% clear to me what is the main reason behind it. The reason: command-line double-entry accounting. I though I waxed about the topic of "why CLI DE accounting" in the following doc than anyone would ever have time for... does this doc provide a sufficient explanation? *http://furius.ca/beancount/doc/motivation <http://furius.ca/beancount/doc/motivation>* I'll guess that what you meant is "why write Beancount when there is already Ledger, HLedger, Abandon, etc." Beancount is substantially different in many ways, not only in its design and syntax, but even in its most basic operations, i.e., how it treats the booking of lots in inventories against each other, how it treats cost basis, its rule for balancing of transactions, how it handles currency conversions (not at cost), the fact that it enforces accounts to be in one of five types and explicitly lacks support virtual/unbalancing postings, a guarantee of order independence of its declarations, and in the mechanisms it provides for extensibility (via Python instead of its own language). It's not just an incompatible syntax, it's a very different beast. I'll write a more detailed comparison doc and share it on this thread later, there is a lot of detail on previous discussions from this list, but it's probably worth gathering all of it in one place with examples. While their syntaxes are incompatible, it would be very easy to write a script to convert from Beancount syntax to Ledger-compatible syntax. I intend to build such a thing eventually, so you could use both. I'm not sure I will be able to match the semantics, this will be an interesting little project in any case. On a historical note, probably few know this, but I started Beancount in 2008, it's not a recent project: http://web.archive.org/web/*/furius.ca/beancount Ledger had been around since at least 2004 (at its original location): http://web.archive.org/web/*/http://www.newartisans.com/ledger/ The main ideas for Beancount originally came from Ledger, more specifically: the original syntax and using a single text file for all ledger contents as input, doing away with credits & debits, allowing the user to elide one posting's amounts, and likely some more. I originally meant to implement a compatible syntax but quickly started diverging because I wanted to add some other features, like balance assertions and explicitly declaring accounts to be open. I only recently got interested in participating on the mailing-list--I had been happily tinkering away in my private corner for many years, never was too interested in spreading the word beyond putting my website out there. The version I'm about to release is a complete rewrite, which is why I have a renewed interest, because I want to tackle new problems, like computing investment returns correctly, precise and correct booking for retirement accounts (at average cost), handling wash sales, improving tracking of payables & receivables, and more. > For > hledger, implementation in Haskell also has its justification especially > that there is now work going on ledger-4 in the same language. (Will the > two merge in future?) > Beyond generic strengths and weaknesses specific to its language, Haskell does not confer any particular advantage to the task of solving the simple problems of command-line accounting. In fact, a strong case could be made that dynamic languages are best suited and in wide usage for such text processing tasks, of which this is just a particular case. I think the choice of specific implementation tools and languages reflects more on the taste of its authors and the choice of what toy we like to tinker with at the time. The only real requirement any language needs to solve the problems we're solving is to have handy a speedy and trustable decimal or rational number representation; little else. -- --- You received this message because you are subscribed to the Google Groups "Ledger" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
