MurphyA/hacker-news huggingface dataset:
by Lapra | 2025-11-02 17:31:55+00:00
I'm sorry, what? If you're a voting member, then yes I //do// expect you to read all the candidate statements. That's the least you can do to be actually informed about your decision. The laziness on display - even being bragged about here - is astonishing. If you don't have the time to be informed about your decision, then there's always the other option - not voting.
by elmerfud | 2025-11-02 17:32:06+00:00
I hope what I'm about to say doesn't actually come true but I do fear over the last couple of decades that we are being set up for it. In the past, and unless developed countries, elder care has been around quantity of life and not always quality of life. There has been a steady cultural shift, and first world countries, around people's focus to be about quality of life and not quantity.

I do believe that there will be a cultural shift in the next decade or two that quality of life will be the primary driver and not quantity. This has started with, what I consider a number of good things, such as living wills. I don't think those are bad to make your wishes known on what should be done in the event of an emergency where you're not capable of expressing it. I do expect this will move forward onto other things. What to do when you've had a stroke and you're cognitively impaired. Then what to do when you're just tired of living.

I am a strong believer in people's independence and free choice. Even if that free choice is them wanting to unalive themselves. That's another interesting term that's become popular as of late, unalive instead of suicide. I also think that suicide shouldn't be something people do and it definitely shouldn't be something that a culture accepts as a whole even if it is liberal enough to allow the freedom of people to choose it. Because when a culture accepts that it devalues life overall. Caring for your elders in a society teaches compassion to the younger generations. It teaches that they have to sacrifice and be compassionate to those who are the weakest among them. Just because choices are available it doesn't mean that those are choices that should be done.

I hope this doesn't come to pass but I really believe that it is a strong possibility that it could. Especially as younger generations are taught to be more selfish and self-centered, parents feel like they want to be less of a burden to their children, it sets things up where this is a very real possibility. There's always the fear of the government death panels and so forth, I don't believe that would pass broad societal approval, but I do believe that a cultural shift where this is voluntary is a very real possibility.
by bccdee | 2025-11-02 17:32:15+00:00
Spec & Malli look cool. But my concern is more with something like this (reusing my earlier example):

let mut authn = UserLoginView.build(userDataRepository); let session = authn.login(user, pwd); // vs let session = userLogin(userDataMap);

In the first case, we know that `login` only has access to the fields in `UserLoginView`. In the second case, `userLogin` has access to every field in `userDataMap`. It's not simple to know how changes to other facets of the user entity will bleed across into logins. With `UserLoginView`, the separation is explicit, and the exchange between the general pool of user info and the specific view of it required for handling authorization is wrapped up in one factory method.

In the first case, it makes sense to unit test logins using every conceivable variation of `UserLoginView`s. In the second case, your surface area is much larger. `userDataMap` is full of details that are irrelevant to logins, so you only test the small relevant subset of user data variations. As the code ages and changes, it becomes harder and harder to assess at a glance whether your test data really represents all the test cases you need or not.

I worry that Clojure-style maps don't fix the problems pointed out by the article. In a codebase that passes around big dumb data objects representing important entities (incrementally processing them, updating fields, etc), the logic eventually gets tangled. Every function touches a wide assortment of fields, and your test data is full of details that are probably inconsequential but you can't tell without inspecting the functions. I don't see how Clojure solves this without its own UserLoginView-style abstraction.
by runarberg | 2025-11-02 17:32:47+00:00
I‘m not convinced this exercise in what to and what not to include in this cost-benefit-analysis will lead to anything. We can always arbitrarily include an extra item to include to shift the calculations in our favor. For example I could simply add the cost of creating the data which is fed into the training set of an LLM, that creation is done by our human biological machinery and hence has the cost of the frozen blueberries, the rigid fiber insulations, the machinery that dug the waterpipe for their shower, etc.

Instead I would like to shift the focus on the benefits of LLM. I know the costs are high, very very very high, but you seem to think that the benefits are also so high measured in time saved. That is the amount of tasks automated are enough to save humans doing similar tasks by miles. If that is what you think I disagree. LLMs have yet to prove them selves with real world application. We are seeing when we actually do measure how much LLMs save work-hours, that it the effects are at best negligible (see e.g. https://news.ycombinator.com/item?id=44522772). Worse, generative AI is disrupting our systems in worse way, where e.g. teachers, peer-reviewers, etc. have to put in a bunch of extra work to verify that the submitted work was actually written by that person, and not simply generated by AI. Just last Friday I read that arXiv will no longer accept submissions unless they have been previously peer-reviewed because they are overwhelmed by AI generated submissions[1].

There are definitely technologies which have saved us time and created a much more efficient system then was previously possible. The loom is a great example of one, I would claim the railway is another, and even the digital calculator for sure. But LLMs, and generative AI more generally are not that. There may be utilities for this technology, but automation and energy/work savings is not one of them.

1: https://blog.arxiv.org/2025/10/31/attention-authors-updated-...
by NoMoreNicksLeft | 2025-11-02 17:32:49+00:00
>If you let in people with the skills you want isn’t it mutually beneficial?

No. If a person can decide for themselves what they want (what benefits them), then I decide that I do not what that, and it is therefor not mutually beneficial. If you have some alternate theory of objective benefice, I'll hear it, but it seems you only assume such exists.
by jamamp | 2025-11-02 17:34:15+00:00
Unfortunately that might also be due to how Instagram shows ads, and not necessarily Anthropic's marketing push. As soon as you click on or even linger on a particular ad, Instagram notices and doubles down on sending you more ads from the same provider as well as related ads. My experience is that Instagram has 2-3 groups of ad types I receive which slowly change over the months as the effectiveness wanes over time.

The fact that you are receiving multiple kinds of ads from Anthropic does signify more of a marketing push, though.
by voidhorse | 2025-11-02 17:35:03+00:00
I completely agree that much of software engineering is not engineering, and building systems around LLMs is no better in this sense.

When the central component of your system is a black box that you cannot reason about, have no theory around, and have essentially no control over (a model update can completely change your system behavior) engineering is basically impossible from the start.

Practices like using autoscorers to try and constrain behaviors helps, but this doesn't make the enterprise any more engineering because of the black box problem. Traditional engineering disciplines are able to call themselves engineering only because they are built on sophisticated physical theories that give them a precise understanding of the behaviors of materials under specified conditions. No such precision is possible with LLMs, as far as I have seen.

The determinism of traditional computing isn't really relevant here and targets the wrong logical level. We engineer systems, not programs.
by embedding-shape | 2025-11-02 17:35:22+00:00
Yes, but I think my previous point still matter, namely what exact model is being used greatly affects the results.

So without specifying which model is being used, it's really hard to know what is better than something else, because we don't understand what the underlying model is, and if it's better because of the model itself, or the tooling, which feels like an important distinction.
by ManuelKiessling | 2025-11-02 17:35:22+00:00
I think there might be a middle ground that could be worth exploring.

On the one hand, there’s „classical“ software that is developed here and deployed there — if you need a change, you need to go over to the developers, ask for a change & deploy, and thus get the change into your hands. The work of the developers might be LLM-assisted, but that doesn’t change the principle.

The other extreme is what has been described here, where the LLM provides the software „on the fly“.

What I‘m imagining is a software, deployed on a system and provided in the usual way — say, a web application for managing inventory.

Now, you use this software as usual.

However, you can also „meta-use“ the software, as in: you click a special button, which opens a chat interface to an LLM.

But the trick is, you don’t use the LLM to support your use case (as in „Dear LLM, please summarize the inventory“).

Instead, you ask the LLM to extend the software itself, as in: „Dear LLM, please add a function that allows me to export my inventory as CSV“.

The critical part is what happens behind the scenes: the LLM modifies the code, runs quality checks and tests, snapshots the database, applies migrations, and then switches you to a „preview“ of the new feature, on a fresh, dedicated instance, with a copy of all your data.

Once you are happy with the new feature (maybe after some more iterations), you can activate/deploy it for good.

I imagine this could be a promising strategy to turn users into power-users — but there is certainly quite some complexity involved to getting it right. For example, what if the application has multiple users, and two users want to change the application in parallel?

Nevertheless, shipping software together with an embedded virtual developer might be useful.
by jstimpfle | 2025-11-02 17:35:46+00:00
I've certainly seen my share of buggy multi-threaded programming. On the other hand, that's nothing compared to all the buggy and bad code I've seen overall. And I don't think it's going to get better by telling people not to even try.

I'm very doubtful that multi-threading can be abstracted behind a library. Simple message passing can cover a lot of use cases but not everything by far. I've also seen the Javascript model work fine, but it's not real multi-threading (no parallelism). As to async frameworks, they too are restrictive and they come with a lot of complexity.
by Yoric | 2025-11-02 17:35:55+00:00
(author here)

I didn't mention tokio's io_uring because, as far as I understand, it is unmaintained. I vaguely recall a conversation in which someone (a contributor?) was claiming that it was not possible to implement most of the features of tokio on io_uring due to conflicting models. [source needed], obviously.

I will admit the very existence of glommio or monoio had entirely slipped my mind. I'll probably need to add a few paragraphs about thread-per-core runtimes. Thanks!
by miki123211 | 2025-11-02 17:36:26+00:00
If you write your software in a language that needs GC, everybody using your software needs GC, but they're guaranteed to get memory safety.

If you write your software in an unsafe, non-GC language, nobody needs GC, but nobody gets memory safety either.

This is why many software developers chose the latter option. If there were some use cases in which GC wasn't acceptable for their software, nobody would get GC, even the people who could afford it, and would prefer the increased memory safety.

Fil-C lets the user make this tradeoff. If you can accept the GC, you compile with Fil-C, otherwise you use a traditional C compiler.
by mghaderi | 2025-11-02 17:36:41+00:00
I implemented a neural network from scratch in x86 assembly (no frameworks, no Python) to recognize handwritten digits from MNIST. Feedback on performance optimizations or next steps is welcome Uses AVX-512 SIMD for parallel float32 ops (~7× faster than NumPy). Runs in a lightweight Debian Slim Docker container. The goal was to understand neural networks at the CPU level.
by lloydatkinson | 2025-11-02 17:37:22+00:00
I’ve used bisect a couple of times but really it’s a workaround for having a poor process. Automatic unit tests, CI/CD, should have caught it first.

It’s still very satisfying to watch run though, especially if you write a script that it can run automatically (based on the existing code) to determine if it’s a good or bad commit.
by thayne | 2025-11-02 17:37:59+00:00
> just target storage interfaces that can be easily distributed—things like Postgres

But as I mentioned above, that makes the system more complicated for people who don't need it to be distributed.

Setting up separate db software, configuring the connection, handling separate updates, etc. is a lot more work for most users than Jellyfin just using a local embedded sqlite database. And it would probably make the application code more complicated as well.
by zeristor | 2025-11-02 17:38:16+00:00
“Albotherm are developing glass coatings that reversibly transition from transparent to white to reduce solar gain in hot weather, allowing buildings and greenhouses to regulate their own temperature without electrical input. Our coatings are tunable to transition temperatures between 18 °C and 45 °C to create comfortable internal temperatures in a range of climates.“

As discussed in the BBC Bottom Line podcast with Evan “Brexit” Davis

https://www.bbc.co.uk/programmes/m002k4kp
by HarHarVeryFunny | 2025-11-02 17:38:38+00:00
Yeah - he chose it as a pithy/catchy description of the issue, then immediately clarified what he meant by it.

> In other words, it is easy to fall into the trap of abstracting away the learning process — believing that you can simply stack arbitrary layers together and backprop will “magically make them work” on your data.

Then follows this with multiple clear examples of exactly what he is talking about.

The target audience was people building and training neural networks (such as his CS231n students), so I think it's safe to assume they knew what backprop and gradients are, especially since he made them code gradients by hand, which is what they were complaining about!
by lapcat | 2025-11-02 17:38:44+00:00
> yeah but you're sort of attributing dishonesty to someones post when I don't think it merits it.

There's a potential for dishonesty, but lack of honesty can also mean just opacity or reticence. Either way, openness and honesty are superior.

I do think that sometimes people say "devil's advocate" when it's their own opinion but an "unpopular" opinion that they may be embarrassed to admit, so they hide behind the devil, pretending they're not the devil themselves.

> "Devil's advocate" is a common enough term, whats the big deal? Is it the word "devil"? Do you think someone is calling you Satan?

No. The issue is not the term. A different term would not help. But the term is instructive about its own usage. In the Catholic Church, nobody wanted to argue against a potential saint, so someone had to be specifically appointed by the Church to argue the other side, a position the arguer didn't necessarily believe. The problem with devil's advocates online is that they're self-appointed for some reason, despite the fact that usually there are already people who sincerely believe that opinion and would argue for it, without the need for a devil's advocate. The Catholic Church canonization process is completely different from online arguments, and there's no need for the special role of the devil's advocate.
by pizlonator | 2025-11-02 17:38:49+00:00
It's super fun to write C and C++ code in Fil-C because it's like this otherworldly crossover between Java and C/C++:

- Unlike Java, you get fantastic startup times.

- Unlike Java, you get access to actual syscall APIs.

- Unlike Java, you can leverage the ecosystem of C/C++ libraries without having to write JNI wrappers (though you do have to be able to compile those libraries with Fil-C).

- Like Java, you can just `new` or `malloc` without `delete`ing or `free`ing.

It's so fun!
by embedding-shape | 2025-11-02 17:39:15+00:00
> Probably not seeing how the code for at least the 3rd was written in 1994, some 30 years before Fil-C existed.

How is this possibly the most charitable reading of parents comment, and honestly, do you think that's what they meant? You can't read that in some other way, where maybe parent wasn't actually asking about time traveling but something else?
by ninetyninenine | 2025-11-02 17:39:36+00:00
I get your point. YOu're saying the world needs to be simulated in order to produce identical sensor output.

I disagree. And my evidence for it is that the trendline clearly shows the rate of improvement for pictures is happening at a rate which clearly shows it will produce pictures that will be indistinguishable.

Like this is independent of whether or not the world needs to be simulated. The On the ground evidence literally shows that the projected trendline is that all pictures and all videos from AI will be indistinguishable in 5 years or less. Right now I would say a PORTION of AI and that portion increases every month.
by ramoz | 2025-11-02 17:39:38+00:00
Hooks are underutilized and will be critical for long-running and better agent performance. Excited to release Cupcake in the coming weeks. What I started building when i made the feature request for hooks.

- https://github.com/eqtylab/cupcake

- https://github.com/anthropics/claude-code/issues/712
by ndiddy | 2025-11-02 17:39:59+00:00
My hope is that if they started responding to CVE bug reports for hobby codecs with something like “This is a codec written by someone in his free time and intended to be used for preservation purposes. We do not support using this codec with untrusted input and may not implement a fix for this bug within the 90 day CVE timeline”, it would stop the harassment. The companies doing the CVE spam would either have to start fixing things themselves, contract someone to do so, or stop using ffmpeg due to all the scary CVEs getting flagged in whatever bullshit security compliance standard they use.
by nixpulvis | 2025-11-02 17:41:10+00:00
It's not a workaround. In this case it seems like it, but in general you cannot always rely on your existing tests covering everything. The test you run in the bisect is often updated to catch something new which is reported. The process is often:

1. Start with working code

2. Introduce bug

3. Identify bug

4. Write a regression test

5. Bisect with new test

In many cases you can skip the bisect because the description of the bug makes it clear where the issue is, but not always.
by UniverseHacker | 2025-11-02 17:41:35+00:00
I think it’s true that most people have a bad experience, but I don’t think it’s caused by things like height, age, and income level…. But social skills, confidence, and emotional vulnerability, which are things almost anyone can develop with deliberate effort, and also lead to better and more stable relationships.

For me, developing vulnerability and risk taking caused me to go from completely unsuccessful, to being able to date pretty much anyone I wanted on these apps. Counter intuitively, the main thing I had to do was stop holding back the things I had previously been afraid to share about myself because I was afraid they made me seem unattractive, and instead confidently own who I really am. It’s very rare for a woman on these apps to encounter someone that seems genuine, unafraid, and vulnerable- and you will stand out like crazy.

It’s not just men having a hard time on these apps- despite the huge number of people, most women really struggle to find anyone that seems appealing, and most of the dates they do go on end up awful as the men are emotionally unavailable, nervous, and afraid to be vulnerable, which makes them impossible to connect with, no matter how tall and rich they may be.

It’s very appealing to believe that the problem is something outside of your control, but it’s rarely the case.
by keernan | 2025-11-02 17:41:46+00:00
My comment has been getting some downvotes which puzzles me.

Is the AI algorithm not essentially a lookup table of sentences containing a word and then doing some statistical analysis of all the sentences in the lookup to determine the probably of the next word (in a very simplistic analogy)?

And isn't that precisely what the word index of the the Encyclopedia provides? Look in the word index for a word, the index will direct you to every page of the 23 prior volumes where that word occurs; go to every page, find the sentences on each page containing that word; now do your analysis of the sentences found to come up with the most probable next word.

Or manually review every sentence when you are 13 in 1965 to get the same understanding.

Am I missing something?
by dpflan | 2025-11-02 17:41:58+00:00
`git-bisect` is legit if you have to do the history archaeological digging. Though, there is the open question of how git commit history is maintained, the squash-and-merge vs. just retain all history. With squash-and-merge you're looking at the merged pull-request versus with full history you can find the true code-level inflection point.
by yawpitch | 2025-11-02 17:42:35+00:00
No, I specifically didn’t, and apparently an inability to read English is amongst your other, let’s just say interesting, attributes.

When an ignorant idiot says “it was probably A” and then someone who actually knows the area says “actually, that’s the thinking of someone who is either ignorant or an idiot, because there’s an equal or better chance it was B” that someone isn’t saying “it was definitely B”, they’re saying the ignorant idiot is an ignorant idiot for assuming A… there’s also a significantly better chance it was C, D, E, or in the case of Doncaster and Peterborough several more letters up to W… my point in its entirety is that it takes an ignorant idiot to assume it was A.

Especially when it was not, in fact, someone motivated by Islam (or even a misreading of Islam). When this is all said and done it will almost certainly have been motivated by either alcohol, drugs, mental illness, or straightforward injured male pride, just like almost every other violent event in this country.

In more ignorant and idiotic countries he’d have had a gun. I’m glad I’ve moved somewhere he only had a knife, and most (if not all) of the injured will pull through.
by uecker | 2025-11-02 17:42:41+00:00
X11 had the distinction between trusted and untrusted X11 clients basically forever. But nobody bothered to even spend the minimal amount of work to make this usable in practice^1. This had two reasons: 1.) It is irrelevant when you run the programs as the same user so nobody bothered (and no: Wayland does not help: https://github.com/Aishou/wayland-keylogger) 2.) It is more fun to simply pretend it is unfixable broken and write something new (something any good engineering manager should have stopped immediately).

¹. I used to use this and also fixed some bugs in some programs. The main problem when I last checked a decade ag was that some important extensions such as composite would need to be exposed to untrusted clients.