487 karma · joined September 30, 2021
My best guess is this: they are not optimizing for good vs great matches, and they are probably not even building a model of what that would even mean, not even trying to represent the concept in their algorithms.
Most likely they are optimizing for one or more metrics that are easy to measure and hence optimize, and these metrics have the side effect of producing an excitement for the user without actually pairing them up.
Example metrics: - time spent on the site
- times they “swipe right” or whatever
- messages sent
- money spent
It’s great if you can quickly stand up a tool that scratches an itch for you, but there is minimal value in it for other people, and it probably doesn’t make sense to share it in a repo.
Other people could just quickly vibe-code something of equal quality.
- Is the work easier to do? I feel like the work is harder.
- Is the work faster? It sounds like it’s not faster.
- Is the resulting code more reliable? This seems plausible given the extensive testing, but it’s unclear if that testing is actually making the code more reliable than human-written code, or simply ruling out bugs an LLM makes but a human would never make.
I feel like this does not look like a viable path forward. I’m not saying LLMs can’t be used for coding, but I suspect that either they will get better, to the point that this extensive harness is unnecessary, or they will not be commonly used in this way.
If I can make one widget per hour, and some new tool lets me make 10 widgets per hour?
Conventional economic theory suggests the gain will be split between the widget-maker and the widget-consumer, in proportions determined by the relative slopes of the supply-demand curves, but definitely the product will become somewhat cheaper.
At my work we have a jit compiler that requires type hints under some conditions.
Aside from that, I avoid them as much as possible. The reason is that they are not really a part of the language, they violate the spirit of the language, and in high-usage parts of code they quickly become a complete mess.
For example a common failure mode in my work’s codebase is that some function will take something that is indexable by ints. The type could be anything, it could be List, Tuple, Dict[int, Any], torch.Size, torch.Tensor, nn.Sequential, np.ndarray, or a huge host of custom types! And you better believe that every single admissible type will eventually be fed to this function. Sometimes people will try to keep up, annotating it with a Union of the (growing) list of admissible types, but eventually the list will become silly and the function will earn a # pyre-ignore annotation. This defeats the whole point of the pointless exercise.
So, if the jit compiler needs the annotation I am happy to provide it, but otherwise I will proactively not provide any, and I will sometimes even delete existing annotations when they are devolving into silliness.
My current employer has a little nub on my laptop that I touch, but my previous employer was big on making me check my smartphone.
I tried caffeine pills in my misguided youth. They feel different, and one time I forgot I had already taken it and took a second—the resulting heart palpitations were some seriously scary stuff.
Trying to castle through check is one that occasionally happens to me (I am rated 1800 on lichess).
I used to take 24-hour allergy medicine with pseudoephedrine, and it took me years to realize it was the thing that was giving me insomnia during allergy season—for years I thought I just had periodic bouts of intense insomnia.
I agree with a sibling comment, also heavily downvoted, that the real blackboard notation is linear algebra notation. Either that, or pseudocode. Python and Haskell look like pseudocode. This doesn’t, and it doesn’t matter what the developer was targeting, he didn’t hit the target.
After looking at the code, I find this claim questionable.