3 ms·

This is basically the old EMACS/Vim vs Sublime/Atom debate that developers have battled for years, moved across to the accounting world, isn't it? Having been

This is basically the old EMACS/Vim vs Sublime/Atom debate that developers have battled for years, moved across to the accounting world, isn't it? Having been involved in accounting system implementation for > 30 years, I understand that people are usually used to doing things one way and find it hard to adapt to change, but even after all my years in the industry, command line accounting fills me with unease - and this is coming from someone who still loves working in the DOS prompt! I am sure for a simple expense/budget ledger it will work OK, but when it comes to recurring journals, multiple reconciliation accounts, inter company transfers, control account tracing etc., give me a nice GUI any day...

jasonm23 10y ago
Honestly, I really don't mean to be rude, but if you're literally referring to the command line as the DOS prompt, you're reference point is one of the worst surviving command line interfaces. UNIX/Linux command line shells are actually made to be productive and your investment in using them is paid off almost everyday. It's a common misapprehension that all CLIs are the same, but to be honest, that's from the perspective of the GUI user. Perhaps you simply missignalled in your comment, and you're a *nix shell power user, in which case I'm preaching to the choir, and accept my apologies. If you didn't misspeak, give Bash, Zsh or FiSh a serious try (Windows 10, MacOs and Linux all support these shells now.)
- cyberferret 10y ago
  I use them all, but started on CP/M then MS-DOS back in the early 80's (plus a little bit of Vax PDP-8). Currently use OS X terminal or the various Unix flavours on our virtual servers. I mentioned 'DOS prompt' by default because I guess that is the one I've used the longest.
db48x 10y ago
Storing the data in a simple text format doesn't stop you from using graphics to understand it. What it does do is let you use tools you already know (your favorite text editor, version-control system, command shell, etc) for editing, queries, backups, graphs, and so on. These are all tools that you've already learned how to use, and which you use every day for other tasks involving text. Whereas with some slick GUI you're probably trapped in that vendor's proprietary file format. On the other hand, it's pretty obvious that plain-text files don't scale to a multinational, with hundreds of accountants of various types all trying to work with the same files. Even with proper use of Git I bet that would get old fast. You would instead want a real database, with a schema, and some data validation and some programs/webpages to smooth out the data entry and querying and whatnot. All of that can be done without any kind of lock-in to one data format, or one particular vendor's tools, but it's way too much overhead for a small business, let alone a single person.
- cyberferret 10y ago
  I understand the speed of the command line when it comes to entering data, and honestly, I've never even considered using something like Git to handle accounting data, but I think it sounds like a neat concept (after all, who of us wishes we could completely undo a set of journals that were accidentally entered into the wrong period). But my experience is mainly in medium to large businesses with multiple users working on the information in real time, and with strict audit policies around them. I would imagine that would be a nightmare to try and handle using a distributed version control repository, let alone having situations such as one user uncommit their nefarious journals funnelling payments into their own bank account etc. I can imagine the face of the auditors having to run commands like `git compare` on the ledgers to trace transaction history... :)
  - adrianratnapala 10y ago
    I imagine the biggest difficulty in these situations is dealing with other people: just like LaTeX might be better for certain kinds of documents, but the world still wants MS Word. But if we look narrowly at functionality, it seems that plain-text and git might be better for strict audit situations. In a Git history every thing you do has to has a "paper trail" in the form of a hash chain (admittedly using an outdated hash function). People can only "uncommit their nefarious <anything>" is along as those transactions never found their way to someone else' hard disk.

jasonm23 10y ago

Honestly, I really don't mean to be rude, but if you're literally referring to the command line as the DOS prompt, you're reference point is one of the worst surviving command line interfaces. UNIX/Linux command line shells are actually made to be productive and your investment in using them is paid off almost everyday. It's a common misapprehension that all CLIs are the same, but to be honest, that's from the perspective of the GUI user. Perhaps you simply missignalled in your comment, and you're a *nix shell power user, in which case I'm preaching to the choir, and accept my apologies. If you didn't misspeak, give Bash, Zsh or FiSh a serious try (Windows 10, MacOs and Linux all support these shells now.)

cyberferret 10y ago
I use them all, but started on CP/M then MS-DOS back in the early 80's (plus a little bit of Vax PDP-8). Currently use OS X terminal or the various Unix flavours on our virtual servers. I mentioned 'DOS prompt' by default because I guess that is the one I've used the longest.

db48x 10y ago

Storing the data in a simple text format doesn't stop you from using graphics to understand it. What it does do is let you use tools you already know (your favorite text editor, version-control system, command shell, etc) for editing, queries, backups, graphs, and so on. These are all tools that you've already learned how to use, and which you use every day for other tasks involving text. Whereas with some slick GUI you're probably trapped in that vendor's proprietary file format. On the other hand, it's pretty obvious that plain-text files don't scale to a multinational, with hundreds of accountants of various types all trying to work with the same files. Even with proper use of Git I bet that would get old fast. You would instead want a real database, with a schema, and some data validation and some programs/webpages to smooth out the data entry and querying and whatnot. All of that can be done without any kind of lock-in to one data format, or one particular vendor's tools, but it's way too much overhead for a small business, let alone a single person.

cyberferret 10y ago
I understand the speed of the command line when it comes to entering data, and honestly, I've never even considered using something like Git to handle accounting data, but I think it sounds like a neat concept (after all, who of us wishes we could completely undo a set of journals that were accidentally entered into the wrong period). But my experience is mainly in medium to large businesses with multiple users working on the information in real time, and with strict audit policies around them. I would imagine that would be a nightmare to try and handle using a distributed version control repository, let alone having situations such as one user uncommit their nefarious journals funnelling payments into their own bank account etc. I can imagine the face of the auditors having to run commands like `git compare` on the ledgers to trace transaction history... :)
- adrianratnapala 10y ago
  I imagine the biggest difficulty in these situations is dealing with other people: just like LaTeX might be better for certain kinds of documents, but the world still wants MS Word. But if we look narrowly at functionality, it seems that plain-text and git might be better for strict audit situations. In a Git history every thing you do has to has a "paper trail" in the form of a hash chain (admittedly using an outdated hash function). People can only "uncommit their nefarious <anything>" is along as those transactions never found their way to someone else' hard disk.