[7h3kk1d]

""Make illegal states unrepresentable" is way too expensive to implement."

This has not been my experience. The speed increase in development not having to worry about the unrepresentable cases have been very valuable. In addition as requirements change migrating old data hasn't been a huge concern. For code changes refactoring the types helps address new cases as well.

[ffsm8]

The difficulty of Making illegal state unrepresentable depends entirely on the domain you're working on. And whether discarding the occasional invalid transaction is viable.

If you're writing a CMS/wiki software, it's gonna be pretty straightforward to do.

If you're working with transactions, trades, contracts etc, it's not.

[fuzztester]

>If you're writing a CMS/wiki software, it's gonna be pretty straightforward to do.

>If you're working with transactions, trades, contracts etc, it's not.

why not?

what's the difference between those two categories, mentioned in your last two sentences, as far as this argument about illegal states is concerned? not clear to me.

in fact, just a few weeks ago, I saw a video by yaron minsky of jane street about ocaml. the title of it might have been "why ocaml". I know he has a video by that name. just not sure whether that was the one I saw or another one by him.

it can easily be googled.

in that video, he talks a fair amount about how jane street uses ocaml, including on how they use it (including defining types for kinds of business domain data, iirc) to make "invalid states unrepresentable" - in fact, iirc, that was the title of one of the slides of his talk.

i remember that very well because i was kind of impressed by the idea, although i have not checked it out practically myself yet.

but I don't know much about this area, so I'm not saying that either he or you are wrong. just asking for clarification / explanation.

also, trades and transactions seems to be the main area that jane street works in.

edited for spelling/wrong autocorrect:

s/one I show/one I saw/

[ffsm8]

> why not? what's the difference between those two categories, mentioned in your last two sentences, as far as this argument about illegal states is concerned? not clear to me.

I kinda began my comment with that reason: The difficulty entirely depends on whether discarding the occasional invalid write is possible. If you can simply return an error and ignore the write/transaction, you're golden.

If you can't, it becomes incredibly complicated

[namaria]

Shouldn't an unrepresentable bad state not even have been proposed as a write tho? I mean the way I understand it, if something is trying to write a bad state somewhere, it is being represented somehow isn't it?

[ffsm8]

No, because you almost never have full data autonomy in corporate contexts. And the microservice arichtecures don't make this more robust either.

I.e. a transaction will have a matching transaction in another corporations/banks system, even if you don't have a distributed monolith unlike everyone else.

[namaria]

I see, well, that is a good point. What is the point of any architectural consideration when you are forced to ingest garbage because others have not made any effort to properly architect their systems. Maybe a strong reason why worse is better in practice.

[FridgeSeal]

> If you're working with transactions, trades, contracts etc, it's not.

I don’t mean to rain on your parade here, but there’s quite a few high powered orgs in the finance world that are well known for making extensive use of functional languages.

Jane St is the most famous example but it’s not the only one. Standard Chartered Bank uses a lot of Haskell, as does Barclays and Bank of America.

[ffsm8]

Nobody in this thread talked about functional languages until you showed up.