Only a Linux user's answer to "how do I install software that's not packaged for my distro" would be "don't".

No because it doesn't remotely take that long.

One nice thing about XML is that there's an official way to link to the schema from within the document. If you do that you can easily automatically validate it, and even better you get fantastic IDE support via Red Hat's LSP server. Live validation, hover for keys, etc.

It's a really nice experience and JSON schema can't really match it.

That said, XML just has the wrong data model for 99% of use cases.

where FP seeks to make most things pure

I made this mistake for ages because Haskell is so popular and it's functional and pure, but it's not actually a requirement for functional languages to be pure. OCaml isn't.

When I read Rust code, I have to completely shift my thinking to something much more imperative.

I agree Rust code has a different feel to OCaml code but that's because it makes some things easier (e.g. mutation, vectors). You still could write Rust as if it was OCaml (except for the lack of currying), it's just that nobody does that because it sucks.

I think we're probably agreeing, it's just that "functional programming" is extremely poorly defined and we're interrupting it differently. You're thinking "a language where people write enormous nested expressions and over-use recursive functions and linked lists" and I'm thinking "a language that supports lots of features common in the FP paradigm: first class functions, pattern matching, expression based not statement based, iterators/map/filter/reduce, currying, tagged unions/sum types, etc."

Lol no. Please show me where he says that.

We should not be designing around singular implementations

Like Linux?

Yeah exactly that. Conceptually it's far superior to manyrepos. But it does have downsides:

• git will be slower, and it doesn't really have great support for this way of working. I mean it provides raw commands for partial checkouts... but you're kind of on your own.
• You can't realistically view a git log --graph any more since there will be just way too many commits. Though tbf you can get to that state without a monorepo if you have a big project and work with numskulls who make 50 commits for a small MR and don't squash.

Also it's not really a downside since you should be doing this anyway, but you need to use a build tool that sandboxes dependencies so it can guarantee there are no missing edges in your dependency graph (Bazel, Buck, Pants, Please, Landlock Make, etc.). Otherwise you will be constantly breaking master when things aren't checked in CI that should be.

Does that not happen with Mercurial? If not that seems like a point against it.

That's exactly the same in git. The old commits are still there, they just don't show up in git log because nothing points to them.

That depends on how readable you want the output to be. It's already pretty bad on that front. If you start supporting arbitrary features it's going to end up as a bytecode interpreter. Which would be pretty cool too tbf! Has anyone written a WASM runtime in bash? 😄

What are you talking about?

You can't win an argument by saying "you can argue about this enormous counterpoint all you want but I'm still right".