The idea that humans can't solve a specific problem more efficiently than a generalised algorithm that has to work for all code ever written in the language is a lie that JS script kiddies tell themselves to justify remaining ignorant without feeling bad about it.
Sometimes, but measure the number of people like that against the massive number of people who blow their whole leg off by trying to second-guess the compiler. If I had a nickel for every “performance critical” (which it never is) weird bullshit thing I’ve seen people do to “defeat” (really: totally misunderstand) a compiler behavior, which instead resulted in severe bugs, I’d have a lot of nickels.
The overlap of situations where compiler-second-guessing truly being necessary and the programmers present are capable enough to implement it is narrow enough that I’m fine with most languages’ escape hatches being similarly narrow.
I mean, using Rust or Zig rather than typescript, go, Java or C# is often a premature optimization, depending on use case. Plenty of games where majority of code is C# or unrealscript. Most people I talk to are surprised that Java has monomorphisation at runtime.
Oh, humans can definitely do that, in some capacity, if they're attentive, slept enough, aren't hungry, or in emotional distress, for a limited amount of time.
A generalised algorithm can do this consistently, billions of times, which happens to be the amount of problems involved in building an application.
Which is why we don't write entire programs in raw assembly, but that doesn't mean it's actually difficult to do better than a compiler. You focus your efforts on where benchmarking and profiling tell you your bottlenecks are in your hot paths. If you actually engage in this in a regular basis, you will recognise that despite the myth-building and fear around writing low-level code, compilers do "stupid" inefficient stuff all the time, and it's not hard to do better than them with the specific context of your project in mind.
Comments
The idea that humans can't solve a specific problem more efficiently than a generalised algorithm that has to work for all code ever written in the language is a lie that JS script kiddies tell themselves to justify remaining ignorant without feeling bad about it.
Sometimes, but measure the number of people like that against the massive number of people who blow their whole leg off by trying to second-guess the compiler. If I had a nickel for every “performance critical” (which it never is) weird bullshit thing I’ve seen people do to “defeat” (really: totally misunderstand) a compiler behavior, which instead resulted in severe bugs, I’d have a lot of nickels.
The overlap of situations where compiler-second-guessing truly being necessary and the programmers present are capable enough to implement it is narrow enough that I’m fine with most languages’ escape hatches being similarly narrow.
I mean, using Rust or Zig rather than typescript, go, Java or C# is often a premature optimization, depending on use case. Plenty of games where majority of code is C# or unrealscript. Most people I talk to are surprised that Java has monomorphisation at runtime.
Of course I’d rather be writing the engine. =)
Oh, humans can definitely do that, in some capacity, if they're attentive, slept enough, aren't hungry, or in emotional distress, for a limited amount of time.
A generalised algorithm can do this consistently, billions of times, which happens to be the amount of problems involved in building an application.
Which is why we don't write entire programs in raw assembly, but that doesn't mean it's actually difficult to do better than a compiler. You focus your efforts on where benchmarking and profiling tell you your bottlenecks are in your hot paths. If you actually engage in this in a regular basis, you will recognise that despite the myth-building and fear around writing low-level code, compilers do "stupid" inefficient stuff all the time, and it's not hard to do better than them with the specific context of your project in mind.