Notices by Wolf480pl (wolf480pl@niu.moe)

When implementing a standard, should we also implement workarounds for compatibility with those who don't comply the standard? Or should we refuse to do so, and tell our users to complain to non-compliant vendors instead?

@emacsen
Sorry if it appeared like it's just my personal gripe with one project, but from my perspective, it's a whole new trend that's spreading throughout FOSS, and IMO leads us to a very grim future.

From my experience, there's a dichotomy between developing software as a product/experience or as a tool.

Whenever someone treats a piece of software as a product, tries to make things out of the box, etc. they end up hiding complexity - oftentimes inherent complexity of the problem the software tries to solve - under the carpet. That leads to all kinds of issues when the user wants to do something nonstandard, or encounters an edge case.

It also often correlates with the developer thinking they're smarter than the user, and trying to force their decisions onto users.

OTOH, when developing a tool, the developer exposes how it works to the user, and passes the decisions - and responsibility for them - onto the user. This often means the UX isn't as nice, because the user is forced to face the real complexity of the problem at hand.

I see those two approaches as mutually exclusive. I hope one day I'll be proven wrong.

@nihl why not Elizabethian English, one which Shakespear written in?
https://en.wikipedia.org/wiki/Early_Modern_English#Elizabethan_English

@epicmorphism the thing is, in assembly you care about stuff that the CPU doesn't care about.
For example, 64-bit multiply has an implicit argument which is always EDX, so sometimes you need to move things around between registers, so that EDX is what you need to be. But to the CPU, a mov between registers is a no-op. You spend effort caring about stuff that doesn't matter anyway.

OTOH, in LLVM IR, you just name the results you care about, and use them later where you need them. It's like you have an infinite number of write-once registers.

If it's easier to write in LLVM IR than in assembly (I used both and I think it is), and it is easier for the CPU to execute LLVM IR than assembly, then I don't see how assembly is an adequate abstraction layer.

@epicmorphism the question is: what is a low-level language for our modern CPUs?
Or what would be one?

x86 assembly is probably a bad match for what happens inside the CPU. Is LLVM IR a better one?