Because the why can be completely unrelated to the code (odd business requirements etc). The code can be known to be non-optimal but it is still the correct way because the embedded system used in product XYZ has some dumb chip in it that needs it this weird way etc. Or the CEO loves this way of doing things and fires everyone who touches it. So many possibilities, most technical projects have a huge amount of politics and weird legacy behavior that someone depends on (including on internal stuff, private methods are not guaranteed to not be used by a client for example). And comments can guard against it, both for the dev and the reviewer. Hell we currently have clients depend on the exact internal layout of some PDF reports, and not even the rendered layout but that actual definitions.
Again, if it's a comment saying "we need this hack because the hardware doesn't support anything", I don't call it "literate programming".
Literate programming seems to be the idea that you should write prose next to the code, because code "is difficult to understand". I disagree with that. Most good code is simple to understand (doesn't mean it's easy to write good code).
And the comments here prove my point, I believe: whenever I ask for examples where a comment is needed, the answer is something very rare and specific (e.g. a hardware limitation). The answer to that is comments where those rare and specific situations arise. Not a whole concept of "literate programming".
Yes, I know, but thank you for the mention. The thing to look for is slow or fast response and maximum leakage current. In industrial settings those are used all the time for slow starting motors and other heavy consumers. The reason I didn't do it is because I only had to make a couple of welds and a triple breaker is 150,- euros or so, so I had to redo a bunch of welds and I didn't have to wait 24 hours to get it.
But if this was a regular thing then I would definitely replace the breaker.
No, they will point out that the way to make GCC better is not really in the code itself. It's in scientific paper writing and new approaches. Implementation is really not the most work.
The difference is visibility, with a van you can often see as close as 1,5 m in front of you due to the short hood. The problem is a lot of the newer trucks and SUVs are so tall that a full child (or 5) just disappear in front the car.
Wouldn't that intern just use an NLE (be it Premiere, Davinci Resole etc) anyway? If you need to style subtitles and edit shorts and video content, you'll need a proper editor anyway.
So this is a good thing even for coreutils itself, they will slowly find all of these untested bits and specify behaviour more clearly and add tests (hopefully).
There are some neat tricks to remove almost all the pack and unpack time. Apache Arrow can help a ton there (uses the same data format on both CPU and GPU or other accelerator). And on some unified memory systems even the send time can be very low.
oh absolutely reducing any of those spots can change the dynamics of the formula. 'zero copy memory' is another local item many drivers can use. It is just one of those things that also change as tech marches on. What used to be the gold standard on speed is suddenly rendered moot because one of those variables changes. Or suddenly something new will become possible. It is kinda cool but you need to keep an eye on it.
YC isn't that unknown and you can absolutely judge that org for funding stuff like this, you really don't need that much detail. And if you have interacted with a lot of the "founders" you know that statistically you're in the clear to judge them all too. It's a pretty weird world where a lot of dumb exists, like A LOT. The realities of their lives are frankly immaterial anyway, it's about the output (and input in case of VC money).
reply