On Sun, Sep 7, 2014 at 3:35 AM, Gour <[email protected]> wrote: > On Sat, 6 Sep 2014 10:59:53 -0400 > Martin Blais <[email protected]> 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. -- --- 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.
