simonmic

G'day all.. checking in with my usual 2 (or 20..) cents. I'm loving this article, and discussion, I always learn lots from these.

Eventual consistency is a nice phrase to highlight. I feel (https://fosstodon.org/@simonmic/113444957161144239) the same way. For me it's about not feeling you're on a time-sensitive treadmill, where if (when) you fall behind, you might risk losing data or never catching up. (Though book-keeping regularly is still advantageous because it's less work.) I believe the "pure function" style of many PTA tools, where all inputs are known and the output is deterministic, combined with version control, are a big part of this.

For newcomers, I like to make clear there's multiple styles of doing plain text accounting, including:

1. Entering all your own data by hand (optionally assisted by data entry tools).

2. Downloading data periodically from banks (as CSV, OFX, PDF, or whatever you can get) and importing it once to your journal file.

3. Downloading data periodically from banks, keeping that as your master data, and frequently regenerating journal files from it.

Each of these has its pros and cons, and there are people successfully using each of them. hledger's own docs focus on methods 1 and 2. Several third-party workflows using method 3 have been built on top of hledger; Full-Fledged Hledger that OP is using is the best known.

1 requires nothing but hledger.

2 adds: either manual bank downloading, or setting up one or more bank download tools/APIs; plus maintenance of conversion rules/scripts.

The workflows implementing 3 add: a recommended file layout, a recommended process, and tools/scripts which depend on these. They bring some benefits (a well documented featureful workflow) and some costs (added complexity). This isn't justified for all users, so don't think you're required to use these workflows.

More details: https://hledger.org/workflows.html

Oil shell is the way forward for shell.

As a haskeller, and shell scripter, I find this a refreshing and exciting experiment. Much of the goodness of haskell, but with a much tighter focus and smaller scope. No imports, language pragmas, packages or build tools needed; all of the building blocks listed on one short page, https://chrisdone.github.io/hell/api. More platform independent, robust, and regular than shell. Potentially a nice learning language / stepping stone to haskell itself.

It's quite verbose right now, and I don't see much networking API yet, but it's just starting. I could see it easily growing into something very nice.

The first link takes you to the home page, which links to examples; probably a better starting point.

https://chrisdone.github.io/hell

Just thank you very much, Mike and the large team of maintainers you've organised!

I was reading here about GnuCash yesterday. That's an old, GUI, non-mac app, surely a bit too much hassle to try out quickly I guessed. But brew install gnucash got me running it in seconds.

Not to go off topic - this story did inspire me to install gnucash again and enjoy the GUI -

> parsing it in a structured way is a nightmare

Ah, well that’s the job of the PTA app - converting “just text” to something very structured and validated. Which can then be moved into SQLite, if one likes.

> and scripting edits to plain text is a mess.

I suppose it depends. There are a lot of very powerful and quick tools and techniques for automated or assisted text munging.

I do some things to try to separate and subtly prioritise bug reports and discourage excessively cluttering the tracker with ideas (some are useful to discuss there, but not all).

- Issue types, using labels: (Almost) every issue’s first label is A-BUG in weighty red or A-WISH in less substantial pink. The spellings keep these two first among labels and most visible. The word “wish” is carefully chosen. I attach one of these on first sight of a new issue.

- Shortcut urls that redirect to a view of one or the other of these, making it easy (for me at least) to focus: bugs.foo.org and wishes.foo.org showing just those, issues.foo.org showing both, prs.foo.org, regressions.foo.org, etc.

- New issue template that gives (short!) guidance and a hint that mail list and chat room are good for discussion and brainstorming. (GH Discussions would be pleasant now, but I’m not keen to fragment discussion more, or lock in even more on GH)..

Discourse. A hosted instance at $50/month with the FOSS discount. Not everyone moved but it's far more pleasant.

Thank you teitoklien. I found your list seriously inspiring, thanks for writing it up.

+1 from this long time make user. https://hledger.org/just.html has some PTA-related examples.

For most PTA users, 1 million transactions would be a large file; we usually split them up more.

On a macbook air m1, here's how hledger 1.40 from homebrew handles it (it used to be faster; perhaps this will improve again):

    $ hledger -f examples/1Mtxns-1kaccts.journal stats
    Main file           : .../1Mtxns-1kaccts.journal
    Included files      : 0
    Txns span           : 2000-01-01 to 4737-11-28 (1000000 days)
    Last txn            : 4737-11-27 (990974 days from now)
    Txns                : 1000000 (1.0 per day)
    Txns last 30 days   : 31 (1.0 per day)
    Txns last 7 days    : 8 (1.1 per day)
    Payees/descriptions : 1000000
    Accounts            : 1000 (depth 10)
    Commodities         : 26
    Market prices       : 1000000
    Runtime stats       : 80.23 s elapsed, 12465 txns/s, 2584 MB live, 7679 MB alloc

Ledger was traditionally faster on at least some reports, but I haven't been able to reproduce that on my machines for some time. Today, with the same file above, it ran for 40m before I killed it.

Tackler advertises 56k txns/s: https://tackler.e257.fi/docs/performance

In my experience about half the time is spent on parsing and half on report calculation. Long-running apps like hledger-ui and hledger-web do the parsing only once at startup, saving time compared to CLI commands.

To be precise, hledger-ui is not an editor, but it can open hledger add, hledger-iadd, or your $EDITOR[1] for data entry, all of which can complete account names. Web guis like hledger-web and Paisa tend to complete account names as well.

[1] https://plaintextaccounting.org/#editor-plugins

Bravo!

Understandable. Docs like https://plaintextaccounting.org/#comparisons and https://hledger.org/faq.html#why-was-hledger-created- try to help. (I'm hledger's lead developer.)

Don't be afraid to try them all a little; you can mostly-automatically convert between them.

Welcome again to PTA, HN friends!

I set up the plaintextaccounting.org site in 2016, to grow a more organised info hub and community around ledger (2003), hledger (2007), beancount (2008), and the many related apps and resources. I'm happy to answer questions; there's also a FAQ on the site.

I don't spend as much time as I'd like making the site and docs better. Feedback and help is always welcome. Stability, efficiency, and longevity are all important, which is one reason it remains fairly simple.

This style of tools and workflows for bookkeeping/accounting, which I named "plain text accounting" for convenience, but was first popularised by Ledger starting in 2003, has a number of aspects; it's not so easy to explain briefly. I think a key one is the use of textual domain specific languages for interacting with the accounting software's internal data model. I mean the various file formats of the PTA tools (describing data), and also the tools' command line interfaces and related scripts and idioms (describing reports or actions).

Textual languages are more expressive and flexible, version controllable, and modular/scriptable/glueable than GUIs, which tend to be more static in their capabilities. Note once you have one text DSL, it's relatively easy to add more, eg custom formats that better fit your needs. And such DSLs need not preclude GUIs; they can be an alternative (perhaps assisted by smart editors/IDEs), complementary, or a foundation.

-Simon

Not just that; the whole Cardano blockchain is running on Haskell, with 100% uptime and high trust. It’s a hugely impressive system, well worth studying.

And if you share stack transcripts I’ll look into those for you.

I’ve experienced this too, the tools can certainly be improved, but also a little more understanding of what they do and how to interpret their error messages could help you (I am guessing).

Not yet mentioned: https://leanpub.com/haskell-cookbook, a good intro from an experienced tech writer.

If you like videos: https://www.youtube.com/results?search_query=haskell

The haskell matrix room and (slightly less useful for beginners) IRC channel: https://www.haskell.org/community

Curated resources:

https://www.extrema.is/articles/haskell-books

https://www.haskell.org/documentation

https://haskell-links.org

Also nice, thanks!

Very nice, thank you!

Are Jujutsu users all using it from the command line ? Is there anything magit-like yet ? Or do you use magit with it ? Have you run into extra complexity and messes because of having two VCSes interacting in one working copy ?

Read the essays, they're excellent.

+1 for dtach. That plus mosh and emacs works extremely well with no fuss.

Fascinating, leads to so many informative rabbit holes. Thanks for sharing.

For anyone interested (though to compare you really need to work with them over a period of time):

Here's a fairly simple thousand line Makefile: https://github.com/simonmichael/hledger/blob/2d35b1051/Makef... (and https://github.com/simonmichael/hledger/blob/2d35b1051/Makef...)

that was converted to a Justfile: https://github.com/simonmichael/hledger/blob/43c93eb37/Justf...

And here's a more powerful kind of makefile using a full programming language: https://github.com/simonmichael/hledger/blob/43c93eb37/Shake...

And here are two multicommand shell scripts:

https://github.com/simonmichael/hledger/blob/43c93eb37/bin/f...

https://github.com/simonmichael/hledger/blob/43c93eb37/bin/t...

that were converted to a justfile: https://github.com/simonmichael/hledger/blob/43c93eb37/bin/j...

Hear hear. https://news.ycombinator.com/item?id=40350218

Appreciate you saying so mitjafelicijan. You're right, it's all about what is appropriate for the project at a given time.

Haskellers think I/O is an important effect and want to manage when it's allowed. It's allowed in the IO context, which happens to be the default:

    main = do
      putStrLn "hello world"
      more

    more = putStrLn "hello again, still in IO"

If you want to, you can break the rule and do I/O from non-IO functions, by using trace:

    import Debug.Trace
    
    add :: Int -> Int -> Int
    add a b =
      trace ("adding " ++ show a ++ " and " ++ show b)
      (a + b)

or unsafePerformIO:

    import System.IO.Unsafe
    
    add :: Int -> Int -> Int
    add a b = unsafePerformIO $ do
      appendFile "debug.log" ("adding " ++ show a ++ " and " ++ show b ++ "\n")
      return (a + b)

Not exactly white-hot hoops of fire ? :)

It's normal to hit some walls, usually from lack of/difficulty in finding the right kind of intro material. (For example, with all respect to my esteemed sibling poster, their advice is overcomplicated.) I encourage you to try again. Laziness can get in the way of I/O, especially in small interactive programs. And Haskell can be written incrementally, once you know a few tricks. We'll be happy to help with "useful program" tips in chat (http://matrix.to/#/#haskell:matrix.org).

I used make as a task runner for probably 30 years; using all the tricks to do most of the things you want in that use case (arguments, help, portability, reliability..). I worked around all the idiosyncracies continually. That's enough time sunk into wasteful friction for me. Now just is here, and the people pushing it are right. For this job (task/script manager for more than trivial commands) it's better enough and reduces cognitive load enough that it's very often worth the install requirement and new learning curve. In time it will be more installed-by-default and I'm certain it'll acquire some form of make-like dependent building as well.

[Apologies for contributing to the slightly off topic discussion. makext sounds great for people still using make for this and I totally would have used it in the past.]