On Sun, Sep 14, 2014 at 12:34 PM, Simon Michael <[email protected]> wrote:
> On 9/14/14 1:17 AM, Gour wrote: > >> - something has gone wrong with ledger register, it's abnormally slow >>> >> >> Or hledger has become quicker? >> > > Gour, since you see opposite results with your personal data (ledger > register much quicker than hledger) it would be interesting to see what you > get with the data I used. > > Finally, I believe/hope that hledger & ledger will join forces in the >> future and produce one outstanding full-featured application with enough >> flexibility to be suitable for both hledger & ledger's current users. >> > I don't think the *Ledgers need more features; on the contrary: less features and another iteration on their design would be more beneficial IMO. The current calculation model is insufficient for many simple uses, e.g. listing stock trades and deriving meaningful numbers from them, e.g., answering simple questions like "what's the annual return on my self-directed portfolio?", and the way many of the options Ledger provides interact with each other is unclear (at least unclear to several users, based on the answers to simple clarifications I've asked for on this list). What we should be looking at is not so much a list of features, but the list of financial problems that one is able to solve with a particular model and templates and examples for solving these problems. I'm happy folks are thinking this way. > > A single project isn't always big enough to accommodate different > technology experiments, design ideas, project management styles and > end-product needs. But I can imagine this happening. It's mostly a matter > of work. As always, if people step up, things happen faster. The most important thing we could agree on is a common design for the semantics of operations entries cause on positions and inventories, i.e., how we perform calculations. In terms of collaborations and portability, or even coming up with a single design, everything else is of secondary importance. Implementation matter relatively little once the semantics are well defined. I do think there is a single "best" design for these semantics, and that is what I'm iterating towards bit by bit; with the right model, one system could solve all the problems. What we're building really isn't rocket science... anybody could reimplement it in a few months. The value lies in finding clever ways to solve accounting and financial problems with a stream of suitably represented transaction objects and operation semantics on their basic objects (number, amount, position, lot, inventory, account). -- --- 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.
