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

^1: kakoune doesn't have multi character shortcuts. You create a "mode" which works basically like a namespace for keystrokes (https://igor-ramazanov.github.io/doc/pages/modes.html).

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.

I don't think cars gave back many hours for the majority of people, they just increased the distance people travel: https://en.wikipedia.org/wiki/Marchetti's_constant

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.

The biggest changes across generations in the last ~5 years were the introduction of specialized instructions for wider vectors (AVX512/AVX2, and even then you need specialized workloads to use them), [...]

AVX2 is actually 13 years (!) old already (first appearing in Intel's Haswell architecture).

AVX512 is also nearly 10 years old right now, but not many CPUs actually support it (none of the devices I own support it)

You can just not use an LSP? My understanding is that LSPs aren't made to be the fastest (code completion|syntax highlighter|code analysis), but easily integrated into all sorts of IDEs/text editors.

Do you maybe have an article on these data structures? It sounds really interesting.

I think "n" would be the grid size.

> Doubling the input roughly doubles the time, the signature of an n log n algorithm.

Excuse me? This entire paragraph reads like the author has made the assumptions about the time complexity of the algorithms and pretends to discover them by simply timing the functions:

> List append tells a different story: 200,000 appends complete in 0.0071 seconds total, about 4e-08 seconds per operation, which is O(1) amortized.

1. You can't say anything about the time complexity after running the algorithm on a single input. This same exact reasoning would lead us to believe that sorting is O(1) per element because sorting the 200.000 elements took 0.5 seconds, which is 0.5/200000 seconds per element.

2. Even if we assume that we correctly measure list-append to be O(1), you can't just put "amortized" behind it without explaining how you get to that conclusion! Pushing to the front of a linked list is O(1), but that isn't an amortized time complexity.

I couldn't continue reading the article after that paragraph.

I personally didn't notice any strong LLM tells in the writing. In fact, I enjoyed the writing style quite a bit. Especially the following sentence near the beginning of the article:

> At that point I had neither a server nor a phone

I don't know why I like it, I just do. Perhaps it is the slightly humorous tone. Anyways, nice article!

Ive actually toyed with the idea of having @ as a pointer dereference. It seems to make sense: you want to know what is at the address stored in p.

I thought C++ was designed to fit all sorts of applications. There is many GUI libraries for C++ for example, and the language has all the capabilities to add abstractions for making these sorts of libraries easy to work with. I think you could argue that C was made for low level code, since the working group seems to be focussing on making the core of the language more usable instead of allowing for abstractions that make libraries easier to work with (I think we can all agree that the C interface of gtk is not that great to work with, though I do commend their efforts).

Sorry for rambling so much, I hope I got my point across.

> The concise help text should only include:

> - A description of what your program does.

> - One or two example invocations.

> - Descriptions of flags, unless there are lots of them.

> - An instruction to pass the --help flag for more information.

I disagree with this. The first 3 points should all unconditionally be in the man page of the program. In my ideal scenario, the jq short help message would omit everything after the "Usage" section except for the message to run the command with --help.

What is the `tlul` part? Just a typo? I don't see it in your expansions.

But the goal isn't to catalogue all human knowledge. Having an article for every living person would be "cataloguing all human knowledge" but it would also be a meaningless endeavour. Some knowledge is worth preserving in an encyclopedia, other knowledge isn't. That is why they have their notability guidelines.

Right before the statement in Wikipedia being an ideological playground:

> Our best hypothesis is quite simple: some of the mods just don't like Odin as a language and don't want it on Wikipedia as any form of "advertisement".

It doesn't directly say "political bias", but it certainly is implied (not as in national politics, more like ideological)

> But the tech giant says it kept operational carbon emissions down by continuing to purchase massive amounts of clean energy.

I never got this line of reasoning. If you are using 37% energy and you buy it from providers of clean energy, doesn't that mean that someone else won't be able to use that energy and will have to use fossil fuels anyways? It's the equivalent of "reducing" a country's emissions by forcing companies to move to a country where they ARE allowed to pollute and just importing the produce from there.

They have hardware decoders for JPEG? I have never heard of this and it seems overkill considering how simple it is to decode.