Considering that aging only happens later in life, it wouldn't have much of an effect on how efficient humans produce offspring, so it wouldn't be selected against. It is the same explanation for why Huntington's and Alzheimer's are still around.
I feel like this becomes less clear if you're talking about "one-time" events. "Our website loads 2x faster now" doesn't mean that they are sending more data per second, and the user won't be doing more website loads. The website load time going from 1 second to 0.5 seconds is "2x faster" and I think that that is a very common way of communicating such performance increases too.
Id say that it is a lot more likely for the in-house, at least half a decade old library to be correct and performant than 3000 lines of an LLMs mediocre regurgitation of that code.
I've been using kakoune for the past 2-3 years and it has been great. My main reason for switching from vim was the adherence to the Unix philosophy, but the editing model has been great. Seeing your selections change after each command + the clippy help text when entering a different "mode"^1 has made learning different editing patterns very easy. The only thing I really miss from vim is the number increment/decrement shortcut. There is a plugin for it, but I haven't tried it out yet (incrementing each selection by a different amount hasn't come up often enough for me).
> Unlike prose, where you usually read it linearly, with code you bounce around based on what connected elements you are exploring.
The moment you are jumping around a lot while reading, being able to understand the structure quickly becomes a major help. For example, dictionaries will have the words in a bold font while italicizing things like the plural etc.
The punctuation/indentation already give you structure, all the highlighting does is break up the flow of actually reading. It essentially forces a micro-reset every second or third word rather than allowing you to seamlessly scan to find what you're looking for. It looks unreadable on the blog post because they have an unreadable font that is way too spacey (nothing against pixel fonts, just their particular choice of one...), but it really is way easier to read code if you try no highlighting with a real font.
I will caveat this on the fact that I use Allman brackets, and have even stronger opinions about that. K&R brackets are cancer and completely destroy the structure of code, so maybe that's why some people feel highlighting is necessary for "structure". With allman brackets, the punctuation guides your eyes to the indentation forming a clean box around each level of code, while if you draw a line from the opening bracket to the closing bracket with K&R style, half the code will be inside it and half outside it, bisecting the natural structure.
It's pretty interesting that you are trying to find a reason for highlighting not working, while it's pretty obvious that many people are using highlighting and it is in fact helping them.
Just that it doesn't work for you, doesn't mean everyone is like you.
That would depend on the application. The convenience isn't just a smaller binary, but also being independent of the distros glibc version (being on an LTS distro and not updating often, I have experienced incompatible glibc versions often enough). The megabytes shaved off are significant if the final binary size is < 1MB, which is a completely different size class.
And not all applications are performance sensitive. Something like UNIX's bc command would benefit more from having easier compatibility and a faster startup than more optimized allocators and string functions.
In the end, it ~doesnt even matter~ is all trade-offs. The nice thing is that it is up to the developer to make the decision of which libc to use, so everyone gets what they want.
