Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Transity – Plain Text Accounting

feram.io

Post reply on HN
Print view View original

51–60 of 141 posts

Re: Show HN: Transity – Plain Text Accounting

#51

Post by grimgrin »

madhadron wrote: post #47
mikeyjk wrote: post #39

Earlier quoted context omitted.

I don't think it is fair to say that git users loathe it overall. I enjoy using git, is this not a common experience?

I regard the command line as a last resort if I can't do something in SourceTree. After spending time with a quality source control client, any command line interface feels like wading through quicksand.

This is likely an insult to git but it’s really similar to vim in that regard. After using ST2 or TextMate for so long, many people aren’t interested in learning (remembering?) how to use vim’s modals/commands.

A lot of people probably did start with SourceTree or a git plug-in in Visual Studio etc

My git workflow is very much tied to aliases. Customization is a hot thing for many people

(but really you should probably read the fugitive.vim docs in their entirety)

Re: Show HN: Transity – Plain Text Accounting

#52

Post by openfuture »

jeremymcanally wrote: post #31
lquist wrote: post #26

CLI tools also have the advantage that their developers don't have to waste their time building and maintaining a useless GUI, but can instead use the time to improve the tool itself Maybe it's just me, but I stopped reading here b/c this language struck me as unnecessarily antagonistic. Just some feedback.

Well, it's also non-sensical. A CLI "interface" needs a lot of thought and work behind it, too, unless you want to end up loathed by your users as something like git is.

I think pijul is a counterexample to this claim. Category theory was used to find the mathematically optimal semantic (i.e. interface) for the category of files and patches (i.e. version control) and so the need to plan the command line interface has been minimized. A GUI would still require a substantial amount of work. I wouldn't go so far as to defend the somewhat exaggerated claim in the original article but I still think CLIs are easier than GUIs.

Re: Show HN: Transity – Plain Text Accounting

#53

Post by wrycoder »

ams6110 wrote: post #22
hannibalhorn wrote: post #10

Earlier quoted context omitted.

I can't speak to Transity, but I use HLedger for my entity (nothing fancy, just a single member LLC.) I can keep my ledger in git, I don't need to pay for or even learn to use QuickBooks, I can quickly write a script to import data from basically anywhere, and I can use all the standard tools in my toolbox (grep, diff, python) to visualize and work with the data. I'm sure mainstream accounting programs add value as t…

I used ledger to keep the books as treasurer for a small non-profit for a few years. It worked really well for me but the problem came with handing it off to the next person or thinking about involving an accountant to do the annual reports. Very few are going to be able to deal with a text file of journal entries. QuickBooks is the standard for all small business accounting, like it or not.

I have the same issue. In addition, for a medium-sized operation, it becomes necessary at some point for more than one person to be updating the system at the same time. That’s when I switched from GNUCash to QuickBooks Online.

Re: Show HN: Transity – Plain Text Accounting

#54

Post by madhadron »

grimgrin wrote: post #51
madhadron wrote: post #47

Earlier quoted context omitted.

I regard the command line as a last resort if I can't do something in SourceTree. After spending time with a quality source control client, any command line interface feels like wading through quicksand.

This is likely an insult to git but it’s really similar to vim in that regard. After using ST2 or TextMate for so long, many people aren’t interested in learning (remembering?) how to use vim’s modals/commands. A lot of people probably did start with SourceTree or a git plug-in in Visual Studio etc My git workflow is very much tied to aliases. Customization is a hot thing for many people (but really you should probab…

I go the other way. After twenty years of unix, the first few without X11, I have become very clear on what is cruft and history and what is actually making my life better.

SourceTree didn't exist when I started using git, but it makes the day to day operations of source control much easier and more precise than the command line. I spent enough years in a command line debugger that I am thrilled to have good debugger integration in my IDE.

It's easy to get into a machismo thing where you regard the shell and a teletype emulator as the "natural" interface to the computer, but it's really an incredibly abstracted interface already, and if you spend some time thinking about what you're actually doing, there's usually a GUI or library for an actual language that is what you really want. It just may not exist.

Re: Show HN: Transity – Plain Text Accounting

#55

Post by billfruit »

After trying to use GNU cash for some time, I got the feeling that a personal accounting app needs to be a web based service, to enable it to be used while on the move/travelling, because I found myself building up a huge backlog of entries to be made in to the system in these situations. After about a month of use, I gave up, since the overhead of jotting down transactions and later entering into the system. I doubt GnuCash or any accounting system like that could possibly have integrated apis for pulling in transaction details from every bank, in every country of the world, atleast presently.

Now a days I use a smartphone app called walnut, which mines your SMSes for transaction data and builds up a ledger by itself, without the need for interfacing with banks directly, because in my country atleast all banks provide SMS trails for transactions.

Re: Show HN: Transity – Plain Text Accounting

#56

Post by andrewflnr »

openfuture wrote: post #52
jeremymcanally wrote: post #31

Earlier quoted context omitted.

Well, it's also non-sensical. A CLI "interface" needs a lot of thought and work behind it, too, unless you want to end up loathed by your users as something like git is.

I think pijul is a counterexample to this claim. Category theory was used to find the mathematically optimal semantic (i.e. interface) for the category of files and patches (i.e. version control) and so the need to plan the command line interface has been minimized. A GUI would still require a substantial amount of work. I wouldn't go so far as to defend the somewhat exaggerated claim in the original article but I st…

That doesn't really change the equation. You've just front-loaded the work into the categorical analysis of version control (and the implied "learn category theory" phase).

PS: I'm cheering for Pijul from the sidelines. :)

Re: Show HN: Transity – Plain Text Accounting

#57

Post by athrun »

I can only speak for me, but modeling financial flows in terms of transactions and not accounts is much more intuitive than the classical alternative.

I'm a long time Buxfer user, which also works like this. It's not that I don't understand double entry bookkeeping, I've used GNUCash for a long time before moving away. It is indeed very powerful and flexible, but it always was too much of a chore to maintain and next to impossible to get other family members to contribute.

I'm not sure this "transaction model" would be appropriate for business accounting, but IMHO it works very well for Personal Finance.

Re: Show HN: Transity – Plain Text Accounting

#58

Post by hosh »

adrianratnapala wrote: post #27
hosh wrote: post #19

Earlier quoted context omitted.

Some mathematicians had constructed a group (Pacioli Group) to analyze the characteristics of using such a system. One thing a double-entry system can do that a single-entry cannot is to quickly verify the consistency of the transactions. The specific names of "debit", "credit", etc. are jargon. The properties that allow for quick verification works on more complex transactions. I might use a single-entry ledger for…

This is going far beyond my own knowledge. I only use double-entry. Or at least I use a style where everything is a transaction that adds up to zero -- there can be more than two accounts in a transaction. I don't even understand single-entry. [UPDATE: I am now pretty sure there is a serious misunderstanding my paragraph above, but think it is more constructive to note it, than to delete it.] My main objection was to…

I see. Thst makes more sense.

I took an intro accounting class in a community college as well as microeconomics in high school, so I have an inkling where this stuff comes from. I look askance at stuff like "contra assets" too.

But yes: boiled down, those are legacy words indicating positive or negative.

Re: Show HN: Transity – Plain Text Accounting

#59

Post by [deleted] »

madhadron wrote: post #49

There are several things wrong here: 1. The author doesn't understand bookkeeping. 2. The author doesn't somehow believes that emulated teletypes are a good substrate for building user interfaces. 3. The author has spent significant time writing a bookkeeping tool for his business instead of doing something that will move the business forward. If you're thinking about writing an open source accounting program, spend…

[deleted]

Re: Show HN: Transity – Plain Text Accounting

#60

Post by jessedhillon »

billfruit wrote: post #55

After trying to use GNU cash for some time, I got the feeling that a personal accounting app needs to be a web based service, to enable it to be used while on the move/travelling, because I found myself building up a huge backlog of entries to be made in to the system in these situations. After about a month of use, I gave up, since the overhead of jotting down transactions and later entering into the system. I doubt…

I work for Plaid. You can sign up and get a dev token that has sufficient permission to access your own bank accounts. Then you can download your transactions and format them for GNU Ledger or whichever other format you prefer.
Post reply on HN