simonmic

It's not just you. There are a ton of resources of different kinds and freshness, and they're hard for a newcomer to find and evaluate quickly, so luck enters into it. Please also try: https://joyful.com/Haskell+minimap

The tools are a bit complex due to the long history and the design choices of other tools, beginning with GHC. Often they are understood only partially, or they are too hard to write about clearly and teach/learn quickly, or they have failure modes that haskellers navigate instinctively but newcomers without support get stuck on.

Like shae I recommend keeping a haskell chat room handy for quick tips, but don't get too sidetracked. The IRC channel has a greater tendency toward intricate language discussions than the matrix room.

ghcup is a good tools manager; stack can also install tools, and has better support for Windows.

I don't question your experience but I think this is not a great example of that. That was a random HN commenter, not Haskell's community (which is quite large and diverse).

Haskell → High-assurance applications and prototyping/research.

A nice writeup.

Here's a simple hack in this direction. In an issue tracker like github's, add "bug" or "wish" labels to all issues (except the few which turn out to be neither, eg support requests). "Bugs" are accepted defects (facts), "wishes" are enhancement requests/proposals (plans, or less than plans).

Actually I use A-BUG and A-WISH, and colour code them, to make them stand out and always be clearly visible at the start of the labels.

(I get about 60% bugs, 40% wishes).

If those multiple people are updating the files via VCS, or via UIs that enforce append-only updates, it's still reasonably fine.

Great work and writeup!

The fact that the "coins" bounce when you "catch" them creates the most dissonance for me. (At the start.)

What is the roguelite (roguelike ?) / vampire / survivor element ? I don't see it.

Do any of these guard against an empty value on either side ?

"export PATH=$DIR:$PATH - That particular pattern is way too common, and is very dangerous if you consider the case when [$DIR or] $PATH (or whatever your variable is, like $LD_LIBRARY_PATH) isn’t set. Then, the value will be :/path/to/dir, which usually means both /path/to/dir and the current directory, which is usually both unexpected behaviour and a security concern."

Sounds bad. Is that reproducible today I wonder.

You may be right, and I think jujutsu or a fork of it is the most likely contender.

At a certain point darcs was fixed to make the exponential merge case much more rare, though it has never been entirely removed. At least from that point on, it has always been possible to use darcs productively just by avoiding or working around those very conflict-heavy merge scenarios. Regular darcs users internalise those working habits and so rarely encounter the problem in practice.

If you do encounter a slow merge with darcs, the normal practice is to treat that as a mistake, step back and re-do your commits to be less conflicting - not to waste time waiting, ending up with a very slow merge in your history.

The original exponential merge corner case, and subsequent lack of a clear prevention mechanism or even clear description of the issue, has had a big anti-marketing impact, and has probably kept darcs out of the limelight ever since the departure of the original lead developer, despite a small heroic band of maintainers working on it to this day.

- Easy and robust undo.

- Intuitive, simpler (but still general and powerful) UI.

It's great, but I switched to watchexec for its easier CLI. (But mac users, watch out for https://github.com/watchexec/watchexec/issues/864, hopefully fixed soon.)

A very useful list, thanks! I hope you'll keep updating it.

I guessed the date(s) indicated the tool's approximate period of active development, but apparently not ? Eg watchexec says "2016-2019" but had a major release a few days ago.

[Ah. Because this post is from 2019, and wasn't flagged as such on HN, and the list needs updating.]

“atrocious” ? I don’t think that’s any Haskeller’s experience. We can point to a few things we’d like to be different for modern Haskell dev, which are slow to improve because of legacy etc, and a certain fragmentation across different packages, but relatively speaking, base and other core libs provide a wealth of high quality, well documented, principled utilities.

That wiki page is very old. But yes, some such list is still needed for now, because people keep wondering about it.

That got fixed the other day.

https://implicitcad.org

Here you go :)

https://joyful.com/Haskell#What+Haskell+apps+are+out+there+%...

Loved this old-school site. Click around the buttons to find more, like https://www.usdebtclock.org/energy.html and https://www.usdebtclock.org/money-history/money-timeline1100... .

As a geek, I wonder how accurate are the amounts currently.

In case these don't get fixed soon, here are a few glitches found:

- mousing over HEALTHCARE COST NOW shows help for US DOLLAR TO OIL RATIO NOW instead

- at https://www.usdebtclock.org/world-debt-clock.html it seems like the USA's PUBLIC DEBT TO GDP RATIO 101.50% should be more like 123.81%

The features/goals sound great, thank you!

These stood out for me as possibly limiting/offputting for wide general use:

- Not being able to generate files in the same directories as input files, or in multiple output directories

- Not being able to provide command line arguments to tasks, as in just

- The mandatory curly braces syntax (and to a lesser extent, smaller verbosities like mandatory `let` keyword). These seem like conveniences for the implementor rather than ideal UX.

The doc for `build` didn't seem quite complete about what can go in there (one of the examples uses a build keyword inside a build recipe ?)

There are people experimenting; eg https://github.com/a-t-0/hledger-preprocessor

PTA does give you a lot of flexibility, sometimes too much. More guidance/opinion on this is probably needed. https://plaintextaccounting.org/Organising-files talks about it a little. Also if you make it to any of the support fora/chat rooms, you'll usually get help on this.

PSA for those interested in trying jujutsu, but not ready to have it auto-track all files in working copy: you can disable that in ~/.jjconfig.toml:

    [snapshot]
    auto-track = "none()"

Money is credited from an income account, I think you meant.

Congrats on the app and release, OP!

> Can a rule expeess such calculated fields like "set virtual date at 3 month before transaction date"?

hledger's CSV rules can't do this, no. You'd need to either do that manually, or write a custom conversion script (or a custom preprocessor that modifies the CSV before hledger sees it).

> That's good for forecasting, but I don't see how to write automatic rules that ensure the accrued amount = billed amount.

Similar answer, if you wanted to generate those verbose entries from a single CSV record, it would need some manual entry or a custom preprocessor script. hledger's CSV rules will only generate 0 or 1 transactions per CSV record.

What about the --average option ?

4. Downloading CSV (TSV, SSV, *SV) data periodically from banks, and using it directly as hledger's data files, without converting to journal format at all. (Optionally adding a journal file just for configuration directives.)

5. Generating one of hledger's input formats from somewhere and piping it into hledger's stdin, running it without saving any data files.

It's great, and uniquely works with Ledger, hledger or beancount. But probably best if you're starting from scratch; making it work with existing data is harder.

Fava is also very good (for Beancount; hledger can export to it).

hledger-web is much simpler than these and can be good for less technical users.

More UIs: starting at https://plaintextaccounting.org/#ui-console

> My major gripe with hledger and other plaintext accounting systems: setting up the correct rules (regex for your expenses) takes too much time as it involves: > a) defining the regexes/categories) for dozens to hundreds of expense descriptions (e.g. walmart, gas station xyz)

We don't usually do it all up front; it's easier to build up your rules over time, improving them a little each time you download.

> b) "recompiling" your hledger journals after every rule change

It's not required (see my other comment).

> c) checking for negative and positive errors (expense description was not matched OR too many different expenses were matched)

For the not matched case: hledger's fallback category is "expenses:unknown" (and inflows are "income:unknown"). I usually watch for those, with something like

  watchexec -- 'hledger import *.csv --dry-run | tail +2 | hledger -f- -I print unknown'

and tweak rules until there are no unknowns, before importing.

For the other - I guess I have a similar answer - if you're not certain of your rules, preview the conversion and tweak them, before finalising it.

> This process is much faster in a spreadsheet application. IMHO the journal format of hledger and other plaintext accounts apps is too verbose.

You can keep your data in CSV/TSV instead of journal. This could be better for spreadsheet interop.

I think a more compact, but still readable journal format would be interesting (something between CSV and current journal format).

I agree some things are much easier in a spreadsheet (and also, vice versa).

> it would be a great relief if someone started a Github repository with expense texts used when you e.g. pay at Carrefour in Italy or Walmart in the USA with your debit card. People could submit those descriptions from the CSV exports of their bank accounts.

Please do, I would love to see it! However, wouldn't it be a really huge list of text patterns/regexps, with 0.1% of them useful to any one person ? Perhaps region-specific collections could work.

https://github.com/simonmichael/hledger/tree/master/examples... is hledger's collection of CSV rules; these cover the basics of CSV conversion, but not the expense categorising.

> Another annoyance in Europe is that there is no API connection for open source apps to bank account statements, you always rely on manual CSV exports.

Ha! It's not better in the US at least (except, by giving up your bank credentials to third parties). We are usually envying your APIs over there.

I don't think it's terribly wrong. It will generate the desired entries (internally) and proper reports, if you add the appropriate option (--forecast=... for hledger, something else for Ledger). Or you could use it once to generate permanent journal entries, in your main journal or a forecast journal:

  hledger print --forecast='2024-11-01..+3 months' >>$LEDGER_FILE

Effective dates are another solution, but IMHO a misfeature, I mention this for newcomers: https://hledger.org/hledger.html#secondary-dates

And here's that (approximately) in h/ledger-ese:

  2025-05-01 Pre-booking May usage
      Expenses:Utilities                           100.00
      Liabilities:Accrued (utility) expenses      -100.00
  
  2025-06-01 Pre-booking June usage
      Expenses:Utilities                           100.00
      Liabilities:Accrued (utility) expenses      -100.00
  
  2025-06-30 Received the invoice for May/Jun 2025
      Liabilities:Accrued (utility) expenses       200.00
      Liabilities:Accounts payable                -200.00
  
  2025-07-06 Paying off the invoice by deducting cash from the bank account and removing the payable liability
      Liabilities:Accounts payable                 200.00
      Assets:Cash                                 -200.00

Another answer:

> 1. Entries in one month's CSV file may be repeated in the previous or following ... Is your system robust against it?

People use various strategies for this. You can treat the data as partitioned (eg in months), or as a continuous stream. In general you can't rely on unique ids, including ones generated from the data (because identical transaction records are common).

hledger has a simple built in method, which works pretty well for most people: it remembers the latest transaction date processed (for each input source). https://hledger.org/hledger.html#date-skipping

> 2. Credit card: the total amount for a month is one single entry in the bank's CSV file, while a separate CSV file contains all the details. Do you rely on accounts to handle this indirect flow, e.g. one transaction of 1000$ from checking to cc, based on the single entry of the bank's CSV, then several transactions from cc to the various expense categories, based on the details CSV, and checking that the cc account has a zero balance?

Yes, purchases made with a credit card and paying off the credit card balance are all separate transactions, so the most standard way is record them as such - either manually, or by downloading/converting/importing the data from both accounts. And for extra assurance, assert that the credit card's balance is zero after payoff.

When downloading from both accounts, you get the payoff transaction in both downloads; one of them can be ignored by rule or manually, or both can be recorded with a dummy transfer account keeping things balanced.

If you don't care enough about the detailed credit card purchases, you'd just record the checking data.

> 3. Some utility companies bill every 2 or 3 months. This makes monthly stats meaningless...

One workaround is to split the expense posting into several expense postings, each with its own date (still keeping them within the one journal entry). A more strictly correct one is to add transactions and accounts like in evrimoztamur's answer. Most often I'll just use hledger's -MA flags (--monthly --average).