Technical analysis tells you that a stock is in its upwards trend. You invest all your money on it without thinking twice. The price goes down and you lose thousands of dollars. Is it a tool problem?
LLMs spit out a sequence of tokens that is the most probable continuation of the input. LLMs don't lie any more than technical analysis does when it predicts the most likely trend of stock prices. It's up to you how to use this information.
Mmm... so when looking for a non-existent key you have to go through the whole table. Hardly O(1)!
A better strategy would be to first search the given range for the first empty slot, and exclude everything after that point. Then proceed looking for tophash in the thus-limited interval. The return value has 3 possible values: 1) key found, 2) reached end of interval without finding but it might be in the other half, 3) found an empty slot so the key is not present, not even in the second half.
If I understood this comment correctly, this approach wouldn't work with a single possible tombstone value.
If the table has, for instance, a tophashes array that looks something like VVVVVVdVVVV, where "V" is any value, and "d" is a deleted item, you can't stop looking after the "d" value -- as your item might be there.
And for those commands that do not deserve a physical button and are only accessible via touch, please adhere to a few simple rules.
1. Put them always in the same place. Especially the "back" or "exit" button!
2. Each button should do one thing, not switch between 3 or more modes that you should look to understand which one you've just activated. Negative example: one button to cycle from cuise control, to drive assist, to speed limit, and back to off.
3. The area where a tap is interpreted as a button press should not also be where a swipe is recognized. In moving vehicles it is too easy for your finger to swing just an inch before touching the screen.
4. The active area of a virtual button must be large, larger than the icon it displays, so large that you shouldn't be distracted from driving just to aim at it!
Also - move the tech forwards! Buttons can be cool. Software controlled detents for rotary encoder knobs, back lit stream deck style buttons, cool knobs that combine twisting and pulling in/out.
1. Drives me crazy on iPhone. On Android there is one button to go back. Very simple. On iPhone sometimes it's top left, some times it's called 'done'. Sometimes the app doesn't have it at all and I have to use a menu instead.
Those are fairly indistinguishable. It's when they start removing letters from words to save... debug symbol bytes or something? That's when c-style naming annoys me.
This is also my pet peeve with a lot of code as well as commands like
npm -g i package-name
Like why would you teach people to do this? I understand people needed to save precious bytes in the sixties so we have cat and ls but saving 192 bytes or whatever with shorter variable names is not a worthwhile tradeoff anymore.
TL;DR the author developed an algorithm to solve this specific problem:
> The popular Roaring Bitmap format uses arrays of 16-bit integers of size ranging from 1 to 4096. We sometimes have to check whether a value is present.
There's no claim that this algorithm is universal and performs equally well for other problems.
In fact, note how the compare operation on the data types involved (16-bit integers) is quite cheap for modern CPUs. A similar problem with strings instead of integers would get no benefits from the author's ideas and would actually fare worse, due to useless comparisons per cycle.
To be fair, vi has got its dose of "modal editing is difficult to learn" criticism for years. Why shouldn't zed receive the same treatment if configuring LSP is a pain point for many newcomers?
Because the bar is low and part of the craftsman's job is to learn their tools. If everyone who wanted to use a computer needed to learn how language servers work, that would be a problem.
A programmer having to learn how language servers work isn't a pain point, it's their job. It takes a couple hours to learn. A couple hours to learn how to do part of your job isn't notable. Complaining about learning how to do one's job makes one unqualified.
> There are going to be skilless vibecoders and then there are going to be experienced devs (like OP) who figured out their AI workflow to multiply their productivity 2-5x.
Are you sure OP belongs in the second group? He explicitly said he doesn't read all the code generated by his AI:
> I have not read most of the code, and instead focused on results, so you might say this was “vibe-coded.”
It might surprise you to know that most (senior) engineers who review don't read every line of code. They have visual pattern-matching from years of experience and depend on that. A good question is, is that enough? I don't know, but the point is that this is already a established practice.
Also, I will not doubt OP's experience. He has published a good set of Emacs packages that are very capable for the niches they occupy. Certain packages are even foundational dependencies in the Emacs ecosystem.
If OP "vibecoded" a critical package, I'm sure he would take it upon himself to ensure it high quality.
reply