atiedebee

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 imagine just ask would be enough for most usecases:

awk '{ freq[$0] += 1 } END { for (n in freq ){ print freq[n] " " n } }' < file.txt

bzip3 is not made by the same author as bzip2, that's why there is a licence disparity.

The article touches upon this:

> 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.

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.

They are not (knowingly) running a piece of software tasked to find cyber security exploits on their laptop.

"at the time of execution" could mean that your program never runs an interpreter and instead compiles the input code before running any of it, basically like the --run option in the tiny c compiler

Only getting the code right "roughly" is not enough in complex code. An example would be an (multi-symbol) arithmetic coder. They all look very similar at a first glance, but choices on the order of operations influence performance and compression characteristics, off-by-one errors are extremely easy to make.

I thought the difference was that a JIT is used alongside an interpreter? It wouldn't need to do optimization, just compile while interpreting?

Because the standard library of a programming language has a lot more eyes on it than one of the many small dependencies does.