ledger vs hledger vs beancount or how to choose the right cli client

[Gour]

Hello,

I'm strongly considering to switch to some cli-based repo for my
accounting needs, but would like to get some help which one would suit
my needs best...

At the moment I use Gnucash and my personal.gnucash (uncompressed) is
~5M (few years of transactions).

My main usage of Gnucash consists of entering transactions and doing
reconcile for several accounts monthly.

I must say that I'm not running GC's reports so often and do not use
budgeting, quotes/stocks, online banking, loan repayments etc.

Besides personal finances I also use GC for my own small (counselling)
company, but for creating quotes/invoices I use separate
(fusioninvoice.com) web app written in PHP which now works with Sqlite3
database since GC is not suitable for handling quotes/invoices since not
every quote results in invoice which means there should be two separate
counters - one for each.

I tried to use scheduled transactions in GC, but few times had need to
postpone some of it and then I experienced corruption, had to revert
(all my *.gnucash files are kept under DVCS - Fossil), but had to give
up scheduled transactions and instead just use 'duplicate transaction'
option.

Of course, for my transactions I regularly have need for 'split' ones.

Besides that, I need to handle and keep, at least, two currencies -
native one and € and occasionally had need to convert one into another.

My chart of account is, I believe, of medium size - e.g. ~100
(sub)accounts under Expenses.

As far as busines side is concerned and considering that GC is not
really suitable for it, I envision that I could use (h)ledger/beancount
and then export data for quotes/invoices and import them into my web app
where the appropriate docs are generated...

Now I see that there are several forks of original ledger and wonder
which one would be suitable for my needs described-above?

I like cli tools and e.g. Taskwarrior (http://taskwarrior.org/) is my
beloved tool for handling tasks and I now I settled on Vim as my editor.

That's pretty much everything and I wonder if ledger
- which I consider is the richest feature-wise can handle all the tasks?

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. 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?)

Any advice is helpful in regard!


Sincerely,
Gour

--
Never was there a time when I did not exist,
nor you, nor all these kings; nor in the future
shall any of us cease to be.

--
Abandoning all attachment to the results of his activities,
ever satisfied and independent, he performs no fruitive action,
although engaged in all kinds of undertakings.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

[Craig Earls]

I think the first place to start is to ask what method you want to use to maintain your ledger data.  emacs ledger-mode only works with ledger, I haven't attempted to run hledger and know little about beancount.

--

---
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 ledger-cli+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Craig, Corona De Tucson, AZ
enderw88.wordpress.com

[Gour]

On Fri, 5 Sep 2014 07:28:38 -0700
Craig Earls <ende...@gmail.com> wrote:

> I think the first place to start is to ask what method you want to use
> to maintain your ledger data.

I do not mind using vim for it, but, afaik, hledger does not have
anything against using editor to maintain data.


Sincerely,
Gour

--
Whenever and wherever there is a decline in religious practice,
O descendant of Bharata, and a predominant rise of irreligion —
at that time I descend Myself.

[Craig Earls]

the accounting programs are editor agnostic, the emacs major mode does
a lot of heavy lifting for preparing the input file. I don't use vi
so can't comment.

[Martin Blais]

On Fri, Sep 5, 2014 at 3:57 AM, Gour <go...@atmarama.net> 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

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.

[John Wiegley]

>>>>> Martin Blais <bl...@furius.ca> writes:

> Ledger had been around since at least 2004 (at its original location):
> http://web.archive.org/web/*/http://www.newartisans.com/ledger/

Pretty accurate, it began in Aug 2003, with the Git history beginning almost
two months later.

John

[Gour]

On Sat, 6 Sep 2014 10:59:53 -0400
Martin Blais <bl...@furius.ca> wrote:

> What exactly do you mean by a "split transaction"?

It's Gnucash terminology for having transaction with more then two
postings, e.g. when money flows from one asset account into two or more
expenses accounts and I see there is no problem with it.

> 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?

I must say that I was/am not very familiar with Beancount, but assumed
that since Ledger is the original and other are clones running behind
that it is the most complete.

> The reason: command-line double-entry accounting.

That's clear, but the question was/is why another cli when there are
already few ones existing?

> 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?

I read that prior to asking the question, but it does not provide
satisfying answer what Beancount provides over e.g. Ledger?

> I'll guess that what you meant is "why write Beancount when there is
> already Ledger, HLedger, Abandon, etc."

Right.

> 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.

Now it's much more clear. Thank you!

First of all, I was not at all aware it's not e.g. compatible with
Ledger (like e.g. hledger) which puts it into somewhat different
perspective when I evaluate option for doing cli accounting.

> 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.

Yes, I consider it would be worthwhile.

> 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.

That would be interesting. Hledger seems to have advantage here since
it's even encouraged to test *.ledger/journal files with both apps.

> 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

That's another thing I was completely ignorant of considering it being
just recent creation.

> 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.

At the moment I'm ignorant about some of those features on your TODO
list, but despite of that I'll seriously consider Beancount. ;)

Lastly, when looking at https://pypi.python.org/pypi/beancount/0.9
Beancount does not look good with last official release more than 5yrs
ago. Moreover, I do not like that docs are on Google, but that's just
my personal preference - when I was browsing it, soon I got email that
my request for change (some space) was rejected. :-)

However, one thing seems to be more clear and that is that we're
probably going to some cli app leaving Gnucash behind.

> 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.

One possible advantage of Haskell might be *less* bugs in the
implementation considering its strong type system and static compilation
which, afaict, can catch bugs at runtime for which one would have to
write unit tests when using dynamic language.

As far as Beancount is considered, Python is certainly more popular/easy
forend-users' scripting.

> 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.

Do you consider all the Ledger's ports satisfy it?


Sincerely,
Gour

--
Therefore, without being attached to the fruits of activities,
one should act as a matter of duty, for by working without
attachment one attains the Supreme.

[John Wiegley]

>>>>> Gour <go...@atmarama.net> writes:

> I must say that I was/am not very familiar with Beancount, but assumed that
> since Ledger is the original and other are clones running behind that it is
> the most complete.

I'm pretty sure this is true regarding the "core" CLI functionality, but the
other systems have branched into areas that C++Ledger does not support at all,
such as hledger's Web UI.

John

[Martin Blais]

On Sun, Sep 7, 2014 at 3:35 AM, Gour <go...@atmarama.net> wrote:

On Sat, 6 Sep 2014 10:59:53 -0400
Martin Blais <bl...@furius.ca> wrote:

> What exactly do you mean by a "split transaction"?

It's Gnucash terminology for having transaction with more then two
postings, e.g. when money flows from one asset account into two or more
expenses accounts and I see there is no problem with it.

This is commonplace in all CLI accounting systems.

Not a problem.

> 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?

I must say that I was/am not very familiar with Beancount, but assumed
that since Ledger is the original and other are clones running behind
that it is the most complete.

Again, what makes you think that the other softwares are "running behind"?

In some of the ways that it differs, I view some of the new features I implement in Beancount as new and pushing the envelope forward. 

 

> The reason: command-line double-entry accounting.

That's clear, but the question was/is why another cli when there are
already few ones existing?

I understand your desire for the open source world to produce a single "best" pristine software to solve any one particular problem, but this is just not how the world operates. The reality of solving problems is a messy discussion of differing ideas by different people with different needs at different points in time. The discussion takes the form of codes and incremental changes over time.

> 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?

I read that prior to asking the question, but it does not provide
satisfying answer what Beancount provides over e.g. Ledger?

Why does a motivation have to be framed in terms of Ledger?

> I'll guess that what you meant is "why write Beancount when there is
> already Ledger, HLedger, Abandon, etc."

Right.

> 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.

Now it's much more clear. Thank you!

First of all, I was not at all aware it's not e.g. compatible with
Ledger (like e.g. hledger) which puts it into somewhat different
perspective when I evaluate option for doing cli accounting.

No hope for syntax compatibility from Beancount at this point, the semantics are just too different. Conversion would be necessary.

> 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.

Yes, I consider it would be worthwhile.

It's coming. Need a bit of time.

> 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.

That would be interesting. Hledger seems to have advantage here since
it's even encouraged to test *.ledger/journal files with both apps.

Personally I think that syntax is a poor way to evaluate software. How the core calculations are carried out should be the more important criteria.

 

Lastly, when looking at https://pypi.python.org/pypi/beancount/0.9
Beancount does not look good with last official release more than 5yrs
ago.

I see 2.0beta:

https://pypi.python.org/pypi/beancount

I've just updated and called it 2.0beta2

(I'm not very good about updating indexes all around the web.)

 

Moreover, I do not like that docs are on Google, but that's just
my personal preference -

Aren't they nicely readable and beautifully formatted and available on all your devices and in many formats? Isn't this the goal of documentation? Why don't you like them?

when I was browsing it, soon I got email that
my request for change (some space) was rejected. :-)

When someone makes a recommendation, I get an email too and look to see if this is a genuine suggestion or just some accidental fat fingering. It happens a lot that readers insert characters by mistake and don't notice (that's the downside of making the doc open for everyone to comment). I just click on the "reject" button to remove those accidental suggestions when that happens. Also, I might accept the suggestion but reject the specific change and reword things manually to make it better; that would also show up as a rejected suggestion. Nothing personal.

> 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.

One possible advantage of Haskell might be *less* bugs in the
implementation considering its strong type system and static compilation
which, afaict, can catch bugs at runtime for which one would have to
write unit tests when using dynamic language.

Software quality is more a function of how much testing it has undergone than the benefits static typing can ever provide. Logical or conceptual errors can't be caught by static type checking. Beyond a very basic level, I wouldn't be concerned so much with the presence of spurious bugs, but instead concerned with how calculations are modeled and carried out. Bugs, if they do occur, will manifest as easily fixable failures with detailed stack information rather than subtler miscomputations. Simple tests that ensure the code is at least called once will catch the vast majority of these. The more subtler kind of error can occur equally in any language and that's the one you should be worried about IMO.

Furthermore, beyond their capabilities, languages nurture particular cultures. In many ways, these cultures subsume the particular technical advantages of computer languages. As examples relevant to the case in point, despite its inherent looseness in typing and glaring performance disadvantages, Python has succeeded in creating a uniquely vibrant culture of "making things simple and explicit," with great documentation and adherence to well-defined contracts (via conventions). This is counter-intuitive (I have observed many a developer simply unable to let go of the kind of worry that the absence of types in Python brings about.)  In contrast, idiomatic Haskell source code is often poorly documented or not documented at all, as there is an assumption by many in its community that its tighter type constraints provide all the context necessary to ensure it is understandable. It wants to look like math and the intentions can sometimes be difficult to understand. Code is meant to be consumed not just by computers, but equally and perhaps more importantly by humans having to maintain it, and expressing the intents beyond its specification is important if we are to update and change this code over time. There are no particularly good technical reasons why computer language cultures evolve in this or that way, but it is an unfortunate reality. I cannot myself still get over the fact that we're not all using at least some variant of LISP: it is superior to all the existing popular dynamic languages in many ways and its failure to conquer the world rests squarely on the humans involved.

Alright, this is getting seriously OT.

> 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.

Do you consider all the Ledger's ports satisfy it?

I think you misunderstood what I meant. I'm saying CLI accounting is easy to implement and should be equally doable in any language. So, yes. 

Ledger uses a rational number representation AFAIK. I had a quick look and I think it's here:

https://github.com/ledger/ledger/blob/master/src/amount.h#L83

I'm not so familiar with HLedger's source code, all I see is a Haskell Double, which surprises me:

https://github.com/simonmichael/hledger/blob/master/hledger-lib/Hledger/Data/Types.hs#L49

This is probably not what's used. Simon: what are you using to represent number types?

Beancount uses a decimal representation:

https://bitbucket.org/blais/beancount/src/d42ad7c9d63c2d46ea79602c85a0b3e9fc31baae/src/python/beancount/core/amount.py?at=default#cl-23

I've argued previously that all of these approaches (including mine) are incorrect. We should be replicating the rounding and truncation that occurs in the "real world" accounts, e.g., round in the same way and at the same places as your bank or broker does.

[Nathan Grigg]

On Sep 7, 2014, at 8:12 AM, Martin Blais <bl...@furius.ca> wrote:

I see 2.0beta:

https://pypi.python.org/pypi/beancount

Note that 'pip' disregards beta versions by default, which is why the 1.0 was installed. The same thing happens for me. Use 'pip --pre' when installing to allow prerelease versions. 

Nathan

[Martin Blais]

On Sun, Sep 7, 2014 at 11:12 AM, Martin Blais <bl...@furius.ca> wrote:

> 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.

Yes, I consider it would be worthwhile.

It's coming. Need a bit of time.

There you go:

http://furius.ca/beancount/doc/comparison

Open and welcome for comments, as usual.

[Gour]

On Sun, 7 Sep 2014 11:12:26 -0400
Martin Blais <bl...@furius.ca> wrote:

Hello Martin,

> Again, what makes you think that the other softwares are "running
> behind"? In some of the ways that it differs, I view some of the new
> features I implement in Beancount as new and pushing the envelope
> forward.

don't get me wrong...but I use Gnucash for several years and before that
I spent some time whether I should start taking care about my finances
and do bookkeeping. Even then, I was aware of the existance of both
ledger and hledger - it looks I had to go throuugh experience with GC
before considering cli - but never heard about Beancount until 10 days
ago or so.

Hledger clearly says it does not support all the ledger's features,
although it adds some of its own stuff like web ui, some reports etc.,
so, as John confirmed, my impression was that for the 'core' financial
stuff, ledger is the leader.

I apologize if it does not apply to Beancount.

> Personally I think that syntax is a poor way to evaluate software.

That's true, but it's pragmatic!

For instance, I've, more or less, settled to use Fossil
(http://fossil-scm.org/) as my primary DVCS. Although I like its
features/simplicity/power/security/etc. it's still awesome to know there
is way out to the most popular Git if something goes wrong.

Here are the steps to convert Fossil repo to git:

git init new-repo
cd new-repo
fossil export --git ../repo.fossil | git fast-import


Otoh, using Beancount with its incompatible syntax means, one is on
his/her own when wishing to go 'back' to Ledger which is certainly more
popular and with greater community behind.

Shortly, (ic)compatibility is not the metric to evaluate software, but
pragmatic concern.

> I see 2.0beta:
> https://pypi.python.org/pypi/beancount
>
> I've just updated and called it 2.0beta2
> (I'm not very good about updating indexes all around the web.)

I was Googling for Beancount and the link for 0.9 was higher. :-)

Moreover, I run Debian Sid and was able to install (h)ledger with
simple: apt-get install, while I do not see packages for Beancount?

> Aren't they nicely readable and beautifully formatted and available
> on all your devices and in many formats? Isn't this the goal of
> documentation? Why don't you like them?

I like that 'reading' is separate from 'editing'. There was a user in
#ledger yesterday who got the feeling that he needs to have Google
account to be able to read it and he wrote: "I give it up."

Why don't you simply use something like https://readthedocs.org/ which
seems to be popular for Python stuff?

> I just click on the "reject" button to remove those accidental
> suggestions when that happens. Also, I might accept the suggestion but
> reject the specific change and reword things manually to make it
> better; that would also show up as a rejected suggestion. Nothing
> personal.

Nothing personal, don't worry, but it was a bit strange. For me, it's
more natural to use my preferred editor, fix things and then 'pull
request', send a patch etc.

> Furthermore, beyond their capabilities, languages nurture particular
> cultures. In many ways, these cultures subsume the particular
> technical advantages of computer languages. As examples relevant to
> the case in point, despite its inherent looseness in typing and
> glaring performance disadvantages, Python has succeeded in creating a
> uniquely vibrant culture of "making things simple and explicit," with
> great documentation and adherence to well-defined contracts (via
> conventions).

Considering that Hledger is slower than Ledger, I wonder how does
Benacount perform in comparison?

> Alright, this is getting seriously OT.

:-)

> I think you misunderstood what I meant. I'm saying CLI accounting is
> easy to implement and should be equally doable in any language. So,
> yes.

OK. I had impression you're thinking about the way how the calc is
performed, iow. about representation of numbers.


Sincerely,
Gour

--
One must deliver himself with the help of his mind, and not
degrade himself. The mind is the friend of the conditioned soul,
and his enemy as well.

[Martin Blais]

On Mon, Sep 8, 2014 at 3:22 AM, Gour <go...@atmarama.net> wrote:

On Sun, 7 Sep 2014 11:12:26 -0400
Martin Blais <bl...@furius.ca> wrote:

Hello Martin,

> Again, what makes you think that the other softwares are "running
> behind"? In some of the ways that it differs, I view some of the new
> features I implement in Beancount as new and pushing the envelope
> forward.

don't get me wrong...but I use Gnucash for several years and before that
I spent some time whether I should start taking care about my finances
and do bookkeeping. Even then, I was aware of the existance of both
ledger and hledger - it looks I had to go throuugh experience with GC
before considering cli - but never heard about Beancount until 10 days
ago or so.

Hledger clearly says it does not support all the ledger's features,
although it adds some of its own stuff like web ui, some reports etc.,
so, as John confirmed, my impression was that for the 'core' financial
stuff, ledger is the leader.

On this list and in the documents I've shared with you I've argued and shown specific examples how the lack of inventory booking in Ledger's model offers little support for entering a correct replication of investment trades and calculate capital gains incorrectly. It makes it very difficult if not impossible to enter correct data about past trades--errors in data entry are very common in my experience (that is, the experience of creating a replication of 8 years worth of trades with a system that _does_ detect such errors, errors which would otherwise have gone undetected by the Ledger model). The "conversions" problem is also not solved--it is possible with Ledger to produce a trial balance with a residual value, which is impossible in Beancount--this provides an additional assurance of correctness.  For these reasons, in terms of "core financial" stuff, the current model Ledger implements falls short, and the model Beancount offers is better suited for replicating account history, especially when it comes to maintaining cost basis of investments.

 

> I see 2.0beta:
> https://pypi.python.org/pypi/beancount
>
> I've just updated and called it 2.0beta2
> (I'm not very good about updating indexes all around the web.)

I was Googling for Beancount and the link for 0.9 was higher. :-)

Moreover, I run Debian Sid and was able to install (h)ledger with
simple: apt-get install, while I do not see packages for Beancount?

That's just because nobody packaged it for Debian.

Clone the repo, "python3 setup.py install". Standard procedure.

I won't package for all distros myself, I have other things to do.

 

> Aren't they nicely readable and beautifully formatted and available
> on all your devices and in many formats? Isn't this the goal of
> documentation? Why don't you like them?

I like that 'reading' is separate from 'editing'. There was a user in
#ledger yesterday who got the feeling that he needs to have Google
account to be able to read it and he wrote: "I give it up."

Well he did not try very hard. I find it odd that some in the open source community balk at the use of my documentation tools. The point of documentation is that you're able to read it. If you can read it and contribute to it, the goal has been achieved. How conservative. 

 

Why don't you simply use something like https://readthedocs.org/ which
seems to be popular for Python stuff?

Because I think Google Docs is better. There is simply no parallel in how it allows you to make immediate corrections without having to patch source code and rebuild. I can even make changes on my phone while I'm on the go! Unless someone builds and maintains a similar "libre" service, there is simply no comparison when it comes to allowing you to contribute changes and fixes and comments. In the few months I've shared my Beancount documents, I've already received far more contributions and corrections than in 10 entire years of traditional rst-based documentation for all my other projects combined. Most often in the OSS community, people don't contribute to docs. So far the experiment is paying off handsomely and I have felt little to desire to retreat to my old tools. If anything, it has encouraged me to write more. I love Google Docs.

> I just click on the "reject" button to remove those accidental
> suggestions when that happens. Also, I might accept the suggestion but
> reject the specific change and reword things manually to make it
> better; that would also show up as a rejected suggestion. Nothing
> personal.


Nothing personal, don't worry, but it was a bit strange. For me, it's
more natural to use my preferred editor, fix things and then 'pull
request', send a patch etc.

Things change; adapt yourself. People are reluctant to change. Realize this. The world used to be desktops, then it was mostly all laptops, and by now it's mostly devices. You can highlight text, right-click and add a comment right there in your browser, and you automatically get an email notification later on. How unnatural can this possibly be? 

If what you have is an ideological problem with the software and the fact it's hosted at Google, I have no time for this. I'm interested in finding solutions to build accounting software via text files, I'm not on a mission to expand the GNU universe.

> Furthermore, beyond their capabilities, languages nurture particular
> cultures. In many ways, these cultures subsume the particular
> technical advantages of computer languages. As examples relevant to
> the case in point, despite its inherent looseness in typing and
> glaring performance disadvantages, Python has succeeded in creating a
> uniquely vibrant culture of "making things simple and explicit," with
> great documentation and adherence to well-defined contracts (via
> conventions).

Considering that Hledger is slower than Ledger, I wonder how does
Benacount perform in comparison?

I don't know about a specific comparison, but with the most hardcore checks I process my 8 years of data in about under 2 seconds on a 2008 macbook laptop running Linux. There are two specific spots for performance optimization, I think with a few simple optimizatins I will cut this down by half.  In any case, it's well within reasonable bounds for command-line interaction in my view. Note that the comparison is a bit unfair as well: Beancount applies a lot of verification tests that Ledger and HLedger do not have.

[Simon Michael]

On 9/7/14 8:12 AM, Martin Blais wrote:
> Ledger uses a rational number representation AFAIK. I had a quick look
> and I think it's here:
> https://github.com/ledger/ledger/blob/master/src/amount.h#L83
>
> I'm not so familiar with HLedger's source code, all I see is a Haskell
> Double, which surprises me:
> https://github.com/simonmichael/hledger/blob/master/hledger-lib/Hledger/Data/Types.hs#L49
> This is probably not what's used. Simon: what are you using to represent
> number types?

Yes Double with some extra smarts at present. Decimal soon probably, see
http://ircbrowse.net/browse/hledger?id=884&timestamp=1409941137#t1409941137
for more discussion.

[John Wiegley]

>>>>> 9/7/14 8:12 AM, Martin Blais wrote:

> Ledger uses a rational number representation AFAIK

Correct, it uses infinite precision rationals from the GMP library, and then
it uses the MPFR library to _render_ them to decimal strings in fixed
precision (MPFR is doing the binary->decimal conversion and making the
rounding decisions).

John

[Gour]

On Mon, 8 Sep 2014 11:37:16 -0400
Martin Blais <bl...@furius.ca> wrote:

> On this list and in the documents I've shared with you I've argued and
> shown specific examples how the lack of inventory booking in Ledger's
> model offers little support for entering a correct replication of
> investment trades and calculate capital gains incorrectly.

Fair-enough, although inventory booking is not something I'n personally
interested in.

> That's just because nobody packaged it for Debian.

OK.

Do you have any estimation about the size of Beancount user base?

> I've already received far more contributions and corrections than in
> 10 entire years of traditional rst-based documentation for all my
> other projects combined.

That's nice to hear and I'm glad about it.

> Most often in the OSS community, people don't contribute to docs. So
> far the experiment is paying off handsomely and I have felt little to
> desire to retreat to my old tools. If anything, it has encouraged me
> to write more. I love Google Docs.

Cool. ;)

> Things change; adapt yourself. People are reluctant to change. Realize
> this. The world used to be desktops, then it was mostly all laptops,
> and by now it's mostly devices.

I still believe that the point that e.g. majority of people today use
mobile devices does it mean it makes them more useful/convenient.

In another mailing list we discuss e.g. nntp vs mailing lists and web
forums, and although many consider web forums 'modern', I have many
doubts accepting them as better solution than old-fashioned nntp groups
and even for mailing lists I use Gmane and do not have intention for
'adapt'.

Finally, (many of) those 'modern users' want to see GUI and web all
around and here we're talking about cli stuff. :-)

> You can highlight text, right-click and add a comment right there in
> your browser, and you automatically get an email notification later
> on. How unnatural can this possibly be?

The point is that when I *read* I do not want to bother with *editing*
and when I *write* I want to use my preferred tools (editor) and not
suboptimal tools (like the one provided by Google docs).

> If what you have is an ideological problem with the software and the
> fact it's hosted at Google, I have no time for this. I'm interested
> in finding solutions to build accounting software via text files, I'm
> not on a mission to expand the GNU universe.

No ideology here in case for Google docs - e.g. I preferred old UI for
google groups, but I don't like the present one - but I simply prefer
having source document in some open markup (asciidoc, markdown, reST)
which is then automagically rendered to desired output(s).

> I don't know about a specific comparison, but with the most hardcore
> checks I process my 8 years of data in about under 2 seconds on a
> 2008 macbook laptop running Linux.

I must say that it makes me curious...running e.g.

$ ledger -M register -f personal.dat Expenses:Auto:Gorivo

to find out about car's expenses for fuel on the file imported from
Gnucash with the following stats:

$ ledger -f personal.dat stats
Time period: 10-Oct-31 to 14-Dec-15 (1506 days)

Files these postings came from:
/home/gour/tmp/ledger/personal.dat

Unique payees: 2159
Unique accounts: 144

Number of postings: 7240 (4.8 per day)
Uncleared postings: 0

Days since last post: -96
Posts in last 7 days: 44
Posts in last 30 days: 286
Posts seen this month: 50

(there are few scheduled transactions till the end of the year)
consumes:

2.65user 0.00system 0:02.84elapsed 93%CPU (0avgtext+0avgdata 12940maxresident)k
6600inputs+0outputs (4major+3952minor)pagefaults 0swaps

on my i7 860 @2.8GHz cpu on the desktop having 16G.



Sincerely,
Gour

--
As a strong wind sweeps away a boat on the water,
even one of the roaming senses on which the mind
focuses can carry away a man's intelligence.

[Gour]

On Sat, 6 Sep 2014 10:59:53 -0400
Martin Blais <bl...@furius.ca> wrote:

> While their syntaxes are incompatible, it would be very easy to write
> a script to convert from Beancount syntax to Ledger-compatible
> syntax.

There is also no way to import e.g. Gnucash file which means hard to
start with Beancount in order to migrate from Gnucash.


Sincerely,
Gour

--
In this endeavor there is no loss or diminution,
and a little advancement on this path can protect
one from the most dangerous type of fear.

[Martin Blais]

On Sep 10, 2014 5:11 AM, "Gour" <go...@atmarama.net> wrote:
>
> On Mon, 8 Sep 2014 11:37:16 -0400
> Martin Blais <bl...@furius.ca> wrote:
>
> > On this list and in the documents I've shared with you I've argued and
> > shown specific examples how the lack of inventory booking in Ledger's
> > model offers little support for entering a correct replication of
> > investment trades and calculate capital gains incorrectly.
>
> Fair-enough, although inventory booking is not something I'n personally
> interested in.

If you have any investments you do.

>
> > That's just because nobody packaged it for Debian.
>
> OK.
>
> Do you have any estimation about the size of Beancount user base?

No idea. At least 3.

>
> I must say that it makes me curious...running e.g.
>
> $ ledger -M register -f personal.dat Expenses:Auto:Gorivo
>
> to find out about car's expenses for fuel on the file imported from
> Gnucash with the following stats:
>
> $ ledger -f personal.dat stats
> Time period: 10-Oct-31 to 14-Dec-15 (1506 days)
>
>   Files these postings came from:
>     /home/gour/tmp/ledger/personal.dat
>
>   Unique payees:            2159
>   Unique accounts:           144
>
>   Number of postings:       7240 (4.8 per day)
>   Uncleared postings:          0
>
>   Days since last post:      -96
>   Posts in last 7 days:       44
>   Posts in last 30 days:     286
>   Posts seen this month:      50
>
> (there are few scheduled transactions till the end of the year)
> consumes:
>
> 2.65user 0.00system 0:02.84elapsed 93%CPU (0avgtext+0avgdata 12940maxresident)k
> 6600inputs+0outputs (4major+3952minor)pagefaults 0swaps
>
> on my i7 860 @2.8GHz cpu on the desktop having 16G.

That sounds unexpectedly high.

>
>
>
> Sincerely,
> Gour
>
> --
> As a strong wind sweeps away a boat on the water,
> even one of the roaming senses on which the mind
> focuses can carry away a man's intelligence.
>
>

[Martin Blais]

On Sep 10, 2014 6:58 AM, "Gour" <go...@atmarama.net> wrote:
>
> On Sat, 6 Sep 2014 10:59:53 -0400
> Martin Blais <bl...@furius.ca> wrote:
>
> > While their syntaxes are incompatible, it would be very easy to write
> > a script to convert from Beancount syntax to Ledger-compatible
> > syntax.
>
> There is also no way to import e.g. Gnucash file which means hard to
> start with Beancount in order to migrate from Gnucash.

Write one. Should take the better part of an hour or two to get something basic working using the code someone else just shared on this list.

[Gour]

On Wed, 10 Sep 2014 08:18:32 -0400
Martin Blais <bl...@furius.ca> wrote:

> No idea. At least 3.

Hmmm...

> That sounds unexpectedly high.

Don't know why, but now when I use:

ledger register -M -f personal.journal Expenses:Auto:Gorivo

it finishes in 0.14s.

Why such a difference or I did some mistake...confused...

Now I found out: the difference is that ledger requires 0.14s when used
with stripped out data version produced with:

ledger -f data.dat print > stripped.dat

but when used with the full version of data file (having commodity and
account top-level directives) it's ~20x slower.

Anyone can explain such big difference?


Sincerely,
Gour

--
You have a right to perform your prescribed duty, but you
are not entitled to the fruits of action. Never consider
yourself the cause of the results of your activities,
and never be attached to not doing your duty.

[Craig Earls]

What top level directives are you using?  

--

---
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 ledger-cli+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Gour]

On Wed, 10 Sep 2014 09:52:48 -0700
Craig Earls <ende...@gmail.com> wrote:

> What top level directives are you using?

commodity, account and have few P lines:

P 2011/12/31 23:00:00 EUR 7.6 HRK
P 2012/11/06 23:00:00 EUR 7.60456273764 HRK
P 2013/01/31 23:00:00 EUR 7.51 HRK
P 2014/02/09 23:00:00 EUR 7.40740740741 HRK


The rest is the same.


Sincerely,
Gour

--
One who restrains his senses, keeping them under full control,
and fixes his consciousness upon Me, is known as a man of
steady intelligence.

[Craig Earls]

Can you start a new thread about this? If possible give us the exact
command line that takes all the time and the exact directives you are
using.