sfink (u/sfink) - Readit News

sfink commented on Google did not unilaterally decide to kill XSLT meyerweb.com/eric/thought... · Posted by u/bkardell

bawolff · a day ago

I think one of the major problems with open source development is its hard to ever remove anything because the vocal minority who likes it will hound you. But removing things is just as, if not more important to good software as adding features.

Obligatory: https://xkcd.com/1172/

sfink · a day ago

That's how it happens in OSS development. For proprietary development, it happens because one big account depends on some obscure feature, or because it is frowned upon to interfere with getting people to upgrade to the latest paid version. See also the fabled backwards compatibility hacks in Windows and graphics drivers. Whether OSS or proprietary software has it worse, I can't even guess.

But the argument is mostly irrelevant here. This is a web platform feature. One of the defining characteristics of the web platform is to be very conservative with backwards compatibility. This has nothing to do with it being OSS.

sfink commented on Sixteen bottles of wine riddle chriskw.xyz/2025/08/11/Wi... · Posted by u/chriskw

sfink · 2 days ago

I solved it on my dog walk as a recurrence.

But to move the spoiler down a little, my initial solution was to pour all the bottles out into a barrel, mix them together, and refill the bottles. Nothing explodes since you never measure anything, but you know the exact set of years in each bottle.

SPOILER:

T(n) is the number of measurements required for n bits.

If you measure the first bit (of n) of all the bottles, you'll never need to measure the last bottle. At that point, you have grouped the bottles into 2 groups, and need to figure out the remaining n-1 bits. So T(n) = (2^n)-1 + 2T(n-1).

    T(1) = 1 (if you have 2 bottles, you only need to measure one.)
    T(2) = 2^2-1 + 2*1 = 5
    T(3) = 2^3-1 + 2*5 = 17
    T(4) = 2^4-1 + 2*17 = 49

In practice, you'd require many fewer measurements. The maximum is only required when your measurements are in the order (01|10)*... and you can stop a bit position early anytime you have found all of the 0s or 1s.

I've no idea how to do better than 49 in the worst case, though. Hm... is it necessarily the case that 45 is possible? (log2(16!))? It seems like that is only true if each measurement can divide the total set of possibilities in half, and I'm not sure why that would be the case.

sfink commented on Code review can be better tigerbeetle.com/blog/2025... · Posted by u/sealeck

jrowen · 3 days ago

Part of the problem is that businesses treat reviewing as a second class citizen. It's not "actual work" so shouldn't be given preference, which excuses the LGTM style reviews.

I've been out of the industry for a while but I felt this way years ago. As long as everybody on the team has coding tasks, their review tasks will be deprioritized. I think the solution is to make Code Reviewer a job and hire and pay for it, and if it's that valuable the industry will catch on.

I would guess that testing/QA followed a similar trajectory where it had to be explicitly invested in and made into a job to compete for or it wouldn't happen.

sfink · 3 days ago

I don't see a lot of value in generic code reviewers. I want the reviewers to be actively engaged in writing somewhat related code themselves, otherwise the value of their opinions will decline over time.

As for prioritization... isn't it enough knowing that other people are blocked on your review? That's what incentivizes me to get to the reviews quickly.

I guess it's always going to depend a lot on your coworkers and your organization. If the culture is more about closing tickets than achieving some shared goal, I don't know what you could do to make things work.

sfink commented on Vibe coding creates a bus factor of zero mindflash.org/coding/ai/a... · Posted by u/AntwaneB

juancn · 3 days ago

I think the article underestimates how much intent can be grasped from code alone. Even without comments.

Humans (and I strongly suspect LLMs, since they're statistical synthesis of human production) are fairly predictable.

We tend to tackle the same problems the same way. So how something is solved, tells you a lot about why, who and when it was solved.

Still, it's a valid point that much of the knowledge is now obscured, but that could be said too of a high employee churn organization.

sfink · 3 days ago

> I think the article underestimates how much intent can be grasped from code alone. Even without comments.

I agree, the human thought process always ends up getting embedded in a which of several possible ways any one thing might be done. But it's still a process, and a vastly inferior one to having a knowledgeable person on hand. Reverse-engineering has up until now been reserved to times when it is necessary. (I mean, we all still do it, especially on legacy codebases, but it's not good for productivity at all.)

> Humans (and I strongly suspect LLMs, since they're statistical synthesis of human production) are fairly predictable.

I disagree with the parenthetical. That's what stands out to me the most about LLM code: there are definitely intentions embedded in the code, but they're a hodgepodge of different intentions all tangled up together. You can't infer much of anything from a small snippet, because the intention behind that snippet was likely relevant to a completely different origin codebase that was piled up into a compost heap to grow an LLM out of. It's actually harder to make sense of an LLM codebase because the intentions distract and confuse the reader -- just as with text, we implicitly assume that a generated artifact means the same thing as if a human wrote it, and it doesn't.

sfink commented on Vibe coding creates a bus factor of zero mindflash.org/coding/ai/a... · Posted by u/AntwaneB

lovich · 3 days ago

He’ll, have they never had to maintain applications where the source code was lost? I haven’t had to do it too often, and I wouldn’t claim I’m very good at it, but on more than a handful of occasions I have had to decompile binaries to figure out what the fuck it was doing before I could write a wrapper around it to try and mitigate its unfixeable issues

sfink · 3 days ago

The author was just saying that this will become the norm, not the exception. Ok, not this bad -- we can at least expect to have access to the AI-generated code for at least a little while longer. (I can imagine a future where AI programming gets just robust enough that some early adopter types will take their whiteboard sketches and prompts and prose test case descriptions, generate the code, compile it to a binary, then throw out the code. It's more agile! You can tweak the spec slightly and just turn the crank again!)

sfink commented on Copilot broke audit logs, but Microsoft won't tell customers pistachioapp.com/blog/cop... · Posted by u/Sayrus

adtac · 3 days ago

>That's basically your documents lossily encoded.

Vector embeddings are lossy encodings of documents roughly in the same way a SHA256 hash is a lossy encoding. It's virtually impossible to reverse the embedding vector to recover the original document.

Note: when vectors are combined with other components for search and retrieval, it's trivial to end up with a horribly insecure system, but just vector embeddings are useful by themselves and you said "all useful AI retrieval systems are insecure by design", so I felt it necessary to disagree with that part.

sfink · 3 days ago

> Vector embeddings are lossy encodings of documents roughly in the same way a SHA256 hash is a lossy encoding.

Incorrect. With a hash, I need to have the identical input to know whether it matches. If I'm one bit off, I get no information. Vector embeddings by design will react differently for similar inputs, so if you can reproduce the embedding algorithm then you can know how close you are to the input. It's like a combination lock that tells you how many numbers match so far (and for ones that don't, how close they are).

> It's virtually impossible to reverse the embedding vector to recover the original document.

If you can reproduce the embedding process, it is very possible (with a hot/cold type of search: "you're getting warmer!"). But also, you no longer even need to recover the exact original. You can recover something close enough (and spend more time to make it incrementally closer).

sfink commented on Show HN: I was curious about spherical helix, ended up making this visualization visualrambling.space/movi... · Posted by u/damarberlari

sfink · 3 days ago

Awesome visualizations.

The part that I was expecting to see but didn't: how can you move at a constant speed? For the original purpose of positioning objects along a path, it doesn't matter. But when moving, you can see it's moving much more slowly at the beginning and end (mostly determined by the radius). What if I want it to travel at a constant rate? Or even apply an easing function to the speed?

I'm sure there's some fancy mathematical trick that would just do it. If I were only more comfortable with math... my handwavy sketch would be to compute the speed function by differentiating the formulas to get dx, dy, and dz and passing them through the Pythagorean equation, then reparameterize on a t' variable using the inverse of the speed function? Maybe? I feel like I'm speaking using words I don't understand.

sfink commented on Why are there so many rationalist cults? asteriskmag.com/issues/11... · Posted by u/glenstein

ar-nelson · 11 days ago

I find Yudowsky-style rationalists morbidly fascinating in the same way as Scientologists and other cults. Probably because they seem to genuinely believe they're living in a sci-fi story. I read a lot of their stuff, probably too much, even though I find it mostly ridiculous.

The biggest nonsense axiom I see in the AI-cult rationalist world is recursive self-improvement. It's the classic reason superintelligence takeoff happens in sci-fi: once AI reaches some threshold of intelligence, it's supposed to figure out how to edit its own mind, do that better and faster than humans, and exponentially leap into superintelligence. The entire "AI 2027" scenario is built on this assumption; it assumes that soon LLMs will gain the capability of assisting humans on AI research, and AI capabilities will explode from there.

But AI being capable of researching or improving itself is not obvious; there's so many assumptions built into it!

- What if "increasing intelligence", which is a very vague goal, has diminishing returns, making recursive self-improvement incredibly slow?

- Speaking of which, LLMs already seem to have hit a wall of diminishing returns; it seems unlikely they'll be able to assist cutting-edge AI research with anything other than boilerplate coding speed improvements.

- What if there are several paths to different kinds of intelligence with their own local maxima, in which the AI can easily get stuck after optimizing itself into the wrong type of intelligence?

- Once AI realizes it can edit itself to be more intelligent, it can also edit its own goals. Why wouldn't it wirehead itself? (short-circuit its reward pathway so it always feels like it's accomplished its goal)

Knowing Yudowsky I'm sure there's a long blog post somewhere where all of these are addressed with several million rambling words of theory, but I don't think any amount of doing philosophy in a vacuum without concrete evidence could convince me that fast-takeoff superintelligence is possible.

sfink · 11 days ago

> What if "increasing intelligence", which is a very vague goal, has diminishing returns, making recursive self-improvement incredibly slow?

This is sort of what I subscribe to as the main limiting factor, though I'd describe it differently. It's sort of like Amdahl's Law (and I imagine there's some sort of Named law that captures it, I just don't know the name): the magic AI wand may be very good at improving some part of AGI capability, but the more you improve that part, the more the other parts come to dominate. Metaphorically, even if the juice is worth the squeeze initially, pretty soon you'll only be left with a dried-out fruit clutched in your voraciously energy-consuming fist.

I'm actually skeptical that there's much juice in the first place; I'm sure today's AIs could generate lots of harebrained schemes for improvement very quickly, but exploring those possibilities is mind-numbingly expensive. Not to mention that the evaluation functions are unreliable, unknown, and non-monotonic.

Then again, even the current AIs have convinced a large number of humans to put a lot of effort into improving them, and I do believe that there are a lot of improvements that humans are capable of making to AI. So the human-AI system does appear to have some juice left. Where we'll be when that fruit is squeezed down to a damp husk, I have no idea.

sfink commented on I wasted weeks hand optimizing assembly because I benchmarked on random data vidarholen.net/contents/b... · Posted by u/thunderbong

jasonthorsness · a month ago

Identifying a representative usage scenario to optimize towards and then implementing that scenario in a microbenchmark test driver are both massively difficult to get right, and a "failure" in this regard, as the author found, can be hard to detect before you sink a lot of time into it.

Even for seemingly trivial scenarios like searching an array, the contents and length of the array make a massive difference in results and how to optimize (as shown in the last section of this write-up where I tried to benchmark search algorithms correctly https://www.jasonthorsness.com/23).

I've not seen a perfect solution to this that isn't just "thinking carefully about the test setup" (profile-guided optimization/production profiles replayed for benchmarks seem like maybe it could be an alternative, but I haven't seen that used much).

sfink · a month ago

It's a subset of profile-guided optimization, but I fairly frequently will gather summary histograms from more or less representative cases and then use those to validate my assumptions. (And once in a while, write a benchmark that produces a similar distribution, but honestly it usually comes down to "I think this case is really rare" and checking whether it is indeed rare.)

sfink commented on I'm Unsatisfied with Easing Functions davepagurek.com/blog/easi... · Posted by u/ndyg

shermantanktop · a month ago

I read the article as an unreasonably deep dive into something that few people care about as much as the author. I certainly don’t, but that’s what makes it good. That’s perfect for HN.

sfink · a month ago

Not disagreeing, but you might be surprised at how widespread the interest in easing is. In my experience, easing is a major topic of debate whenever people are discussing the look and feel of animations.

Often people just argue over the proper parameters for the same old functions, but that's all they have available. Their arguments use lots of ambiguous human terminology like snappiness, surprise, anticipation, sluggishness, etc. that don't cleanly map to specific parameters.

Adjusting easing can produce dramatically different results in how we feel about something. It triggers our hindbrain. We want to pounce on the mouse, or block the incoming rock, or whatever, I guess? Try going in for a handshake a little faster or slower than usual and see what happens...