On Mon, Jan 4, 2016 at 2:15 PM, John Wiegley <[email protected]> wrote:
> >>>>> Martin Blais <[email protected]> writes: > > > Stay away from virtual postings, they break the accounting equation. You > > never need to use them, period. > > I disagree with this statement. I've used them to good effect in the past. > There are times when you need a bit of flexibility to get exactly the kind > of > reports you want. It's not all about accounting, or honoring the accounting > equation; it's about managing finances the way a Ledger user wants to. The fact that one can use them does not mean they're a good thing to have; they have a cost too, they are dangerous (they break the elegant balance property) and their availability must be weighed against this cost. All it means is that for solving these particular problems you haven't forced yourself to carry out the same operations within the constraints of the double-entry system. In specific instances, I've shown on this list how you can solve all the same problems within the constraints of balancing transactions, albeit sometimes requiring with minor twists and turns. The major problem with virtual postings is that they offer a way out of the DE method. Due to its nature, most command-line accounting users aren't accountants and are just learning the method, and as such, they inevitably reach out for the crutch way way earlier than they should, basically as soon as they don't know how to book some particular type of transaction. You may not use it that way, but for most users it's a cop-out. Breaking the rules to do things "the way a user wants to" instead of learning the DE system breaks a fundamental property of the dataset. That bit of flexibility you want is one with costly consequences. If one truly required virtual postings in order to solve a particular problem, one should wonder whether a spreadsheet would be a more appropriate tool to solve their particular problem. Otherwise they should try harder to frame their problem as a set of double-entry transactions. It's possible: Beancount does not even support virtual postings and I'm solving all the same problems other people do. I think > this pretty much sums up the core philosophical divide between beancount > and > Ledger. > That's oversimplifying it. The philosophical divide runs deeper than this, and I would describe it in three parts. First, Ledger is optimistic. It assumes it's easy to input correct data by a user. My experience with data entry of the kind we're doing is that it's impossible to do this right without many automated checks. Sign errors on unasserted accounts are very common, for instance. In contrast, Beancount is highly pessimistic. It assumes the user is unreliable. It imposes a number of constraints on the input. For instance, if you added a share of AAPL at $100 to an empty account it won't let you remove a share of AAPL at $101 from it; you just don't have one. It doesn't assume the user is able or should be relied upon to input transactions in the correct order (dated assertions instead of file-order assertions). It optionally checks that proceeds match sale price (sellgains plugin). And it allows you to place extra constraints on your chart of accounts, e.g. a plugin that refuses postings to non-leaf accounts, or that refuses more than one commodity per account, or that requires you declare all accounts with Open directives; choose your level of pedanticity a-la-carte. It adds more automated cross-checks than the double-entry method provides. After all, cross-checking is why we choose to use the DE method in the first place, why not go hardcore on checking for correctness? Beancount should appeal to s/he who does not trust themselves too much. And to the point: because of this, it does not provide support for unbalanced/virtual postings; it's not a shortcoming, it's on purpose. Secondly, there's a design ethos difference. As is evidenced in the user manual, Ledger provides a myriad of options. This surely will be appeal to many, but to me it seems it has grown into a very complicated monolithic tool. How these options interact and some of the semantic consequences of many of these options are confusing and very subtle. Beancount offers a minimalistic approach: while there are some small number of options ( https://bitbucket.org/blais/beancount/src/tip/src/python/beancount/parser/options.py?fileviewer=file-view-default#options.py-196), it tries really hard not to have them. And those options that do affect the semantics of transactions always appear in the input file (nothing on the command-line) and are distinct from the options of particular tools. Loading a file always results in the same stream of transactions, regardless of the reporting tool that will consume them. The only command-line options present are those which affect the particular behavior of the reporting tool invoked; those never change the semantics of the stream itself. Thirdly, Beancount embraces stream processing to a deeper extent. Its loader creates a single ordered list of directives, and all the directives share some common attributes (a name, a date, metadata). This is all the data. Directives that are considered "grammar" in Ledger are defined as ordinary directive objects, e.g. "Open" is nothing special in Beancount and does nothing by itself. It's simply used in some routines that apply constraints (an account appears, have an Open directive been witnessed prior?) or that might want to hang per-account metadata to them. Prices are also specified as directives and are embedded in the stream, and can be generated in this way. All internal operations are defined as processing and outputting a stream of directives. This make it possible to allow a user to insert their own code inside the processing pipeline to carry out arbitrary transformations on this stream of directives--anything is possible, unlimited by the particular semantics of an expression language. It's a mechanism that allows users to build new features by writing a short add-on in Python, which gets run at the core of Beancount, not an API to access its data at the edges. If anything, Beancount's own internal processing will evolve towards doing less and less and moving all the work to these plugins, perhaps even to the extent of allowing plugins to declare the directive types (with the exception of Transaction objects). It is evolving into a shallow driver that just puts together a processing pipeline to produce a stream of directives, with a handy library and functional operations. -- --- 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.
