(Sorry, forwarding, still having google groups mailing problems. I think this never made it.)
----- Original message ----- From: Martin Blais <[email protected]> To: [email protected], Mark Alexander <[email protected]> Subject: Re: Announcing: Abandon Date: Sat, 01 Jun 2013 09:35:09 -0400 On Sat, Jun 1, 2013, at 8:36, Harshad RJ wrote: > Martin, thanks for your response. Will definitely take a look at the new > input syntax and get back to you. > > Mark, do you have any plans to share the RoR app? > > About desktop app v/s web app, I guess I should explain why I find the > former easier to develop. > > I want to develop interactive reports where user can change parameters or > drill-down to more details, or show bar charts and pie-charts, etc. There Same here actually. I'll be using gviz probably, or some d3.js. > could be other forms of interaction which I haven't thought through fully > yet. For example, editing amounts right inside the app and propagating the > changes back to the ledger file. Now, *that*'s one of the more difficult challenges. I have thought about this a fair bit, and have given up on the idea. It's also a generic problem, not specific to the accounting problem we're solving. Let me explain why. I think there's a fundamental question here coming into play: "Is the ledger file a computer language or is it a file format?" I think arguments could be made for both, but what determines one or the other is whether humans most often have to _write_ into the file, or computer programs. My personal usage patterns with beancount have been squarely on the "computer language" side of this ledger so far, that is, I carefully edit and reorganize text in the file in a way that is convenient to me (using org-mode and emacs, mostly). For me, the input syntax is a computer language, we're designing a computer language that makes it easy to create records. It's not entirely unlike writing an SQL dump manually, in that sense, it's just a bit more specialized, and the more conveniences are afforded to humans, the farther away we move from the syntax being a file format. (Ledger's syntax goes even further in that direction IMO, trying to take advantage of context, many features to make it easy for humans to write the file). The new syntax I use, on the other hand, is more "regular" (i.e., every entry type starts with YYYY-MM-DD TYPE, like "2013-03-02 check") and hints heavily to the fact that this language is really just meant to create a simple data structure. Also related, my new importer library will spit out partially filled transaction objects and then at the final stage it'll render those into text... thus going in the other direction, from data structure back into text. But I think it doesn't change the basic idea, because at the end of the day, the purpose of this imported text is *still* to be reviewed by the user and massaged and reorganized manually. (R.Adams might disagree, he appears to have a fully automated process; I think that's impressive, but I can't imagine doing that for myself, because in my experience there are just too many cases where you want to review and manicure or fix the input, or add comments, or enter some data that just ins't available from downloadable records. It's possible, however, that it's just the way _I_ have tried to use it, or that I'm tracking things other people don't (e.g. I'm using it to track RSP contributions that can be carried forward between taxation year, or max 401k contributions, things that don't have downloadable files for them). In other words, does anyone think that the process of importing can be FULLY automated, with safe de-duping (de-duping is a problem in an of itself, OFX files for matching transactions from different institutions don't necessarily have the very same date; my importer *tries* to detect them BTW, and does a pretty good job, but again, I just mark the imported transactions with a comment "possibly dup'ed" and it's up to me, the human, to check, and usually merge the transaction with the other side of it that has already been imported)). So you'll face a few interesting problems about having an app write to the input file: - Given that the user may make comments in the input file, if you edit these entries through the GUI, will you able to maintain the comments? (I think this means that your comment syntax should be parsed into your data structures, e.g., the parser should not simply ignore comments, it has to have a structured way to store them and render them.) - You'll need to track carefully where the transactions are located in the input file if you want to maintain human-writabiity and modifications should be reflected near the original location. - Also, if the user edits the file while you've got the GUI up (or will you just disallow this?), you might need to resynchronize the file and the GUI state. - If you want the user to be able to make sense of the input file at all, you'll have to find some way to organize the transactions sensibly. That's not always obvious, because transactions have many legs; maybe you could define some sets of rules for where to best insert new transactions based on previous contents. (I don't know, this could get solved creatively I think.) IMHO to most easily allow a GUI to make changes, you'd have to more-or-less solve these problems, or otherwise give up on the idea that the user will be editing the file and commit squarely to the file just being data storage (I'd say don't bother with a parser then, use an SQL backend or XML or JSON or whatever). These are problems I'm personally not interested in solving BTW, but I'm excited to find out what you come up with. I ask myself.... Why are we designing a computer language in the first place? I think it is because having a few semantically meaningful constructs is simpler and often more powerful to build than a visual GUI metaphor. In my view, this is the power of language. I very much tend to view what I'm doing as *avoiding* having to build a GUI by designing a computer language. So for me, the interface is purely a reporting tool. My interface has no input, other than for searching or toggling visual elements on or off. Please keep me/us posted with what you come up with, this could be a new kind of thing. > Now, compared to a desktop app, a web app has the added complexity of a > separate runtime (Javascript) and an asynchronous channel (http) between UI > and backend. While there are frameworks to mitigate this complexity, and > the problems are surmountable, the overall complexity is still higher than > that of a desktop-app. > > This complexity is worth the trouble if several people are going to use the > same app + same input files *simultaneously*. However, I don't see that > happening often in the case of an accounting package for a small firm / > personal use. The collaboration if any, can still happen over version > control systems like Git or bazaar (since the input files are plain-text). > > -- > *Harshad RJ <http://lavadip.com>* > > -- > > --- > 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/groups/opt_out. > > -- --- 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/groups/opt_out.
