MurphyA/hacker-news huggingface dataset:
by npteljes | 2025-09-08 06:53:57+00:00
Regulars devs don't need an excuse, they have a good reason: their optimization targets are different. The people that turn their work into their salary, and mostly the people who buy into those software, don't go away because of how large the thing is, so, why sacrifice other goals, to further this particular goal?

"If demosceners can do it" is not a good argument to talk about software, because demosceners are the cream of the software crop, when it comes to the specific thing that the demoscene is all about. It's like saying if racers can make that corner doing a 100, regular drivers have no excuse. Or I'm greatly misunderstanding your point.

Filepilot looks great. I wouldn't pay, as Double Commander serves me just fine, but an 1.8 MB download is impressive. DC is 10 MB in comparison. Still perfectly fine.
by komali2 | 2025-09-08 06:54:15+00:00
Does your linter not have a fix command for things like import order? Does your editor not auto trim white space?

To be frank, everyone I've worked with that complained about the linter didn't know much about their tooling. They didn't know about the fix command (even though I put it in the readme and told them about it), they didn't know how to turn on lintfix and prettier on save, wouldn't switch on git hooks and didn't know their lint failed until GitHub said so, and none of the people like this were so productive that it made up for this trait.
by anovikov | 2025-09-08 06:55:12+00:00
Easy peasy. People buy homes because they feel psychologically insecure and uncertain about being able to keep roof on their heads in the future. It never made sense as an investment apart from a short period in 1970s and even that because stock market was in shit then.

Rich people know they face no risk of not being able to afford housing. So they put their money where the returns are.
by gf000 | 2025-09-08 06:55:29+00:00
> this means that accidental complexity has not disappeared, it has only moved

I would argue that it is essential complexity that we reuse (what the library does), at the added cost of some accidental complexity from dependency management, etc.

Which is a fair price where the essential complexity reuse is larger than the overhead (e.g. it generally makes no sense to bring in isOdd as a separate library, but for larger functionality you are likely better off doing so).
by adrian_b | 2025-09-08 06:56:26+00:00
By "iron", I assume that you mean "cast iron", as pure iron is hardly used for anything.

Cast iron is lighter than steel, not heavier, because of its higher carbon content.

However, objects made of cast iron are indeed heavier than similar objects made of steel, and this is what you must have in mind, because the objects made of cast iron are always made thicker, both because cast iron is weaker, which requires greater thickness for the same strength, and because it is harder to make thinner objects by casting than by forging.
by arcticbull | 2025-09-08 06:58:08+00:00
First of all, wut. Second, that's irrelevant because stable coins rely on fiat backing (ostensibly) so you're stacking a new problem on top of what you perceive to be a different problem. If you believed that to be a problem then stable coins give you that problem twice as hard. And a whole mess of new ones too, like zero recourse against the newly intermediated offshore issuers in low-or-zero regulation locales.
by rgoulter | 2025-09-08 06:58:46+00:00
> I don't know what "fellow engineers" the author is accustomed to collaborating with, junior or otherwise, but the attributes enumerated above are those of a sycophant and not any engineer I have worked with.

I read "junior" as 'subordinate' and 'lacking in discernment'.. -- Sycophancy is a good description. I also like "bullshit" (as in 'for the purpose of convincing'). https://en.wikipedia.org/wiki/Bullshit#In_the_philosophy_of_...

The point being, there's nuance to "it felt like a collaboration with another developer (some caveats apply)". -- It's not a straightforward hype of "LLM is perfect for everything", nor is it so simple as "LLM has imperfections, it's not worth using".

> Another key activity identified as a benefit to avoid in the above quote is: > > ... required me to learn ...

It would be bad to avoid learning fundamentals, or things which will be useful later.

But, it's not bad to say "there are things I didn't need to know to solve a problem".
by bad_username | 2025-09-08 06:58:54+00:00
The "entry barrier" and the level of commitment required to bring an OSS project to "findable in Google, has at least some github stars/whatever equivalent, is green in CI, and actually works when you try it" is higher that the authors of a typical internal library in a typical enterprise can afford. Which is why the recognition and trust is usually higher. All IMHO.
by ojosilva | 2025-09-08 06:59:55+00:00
Yeah, it's amazing how fast people can overlook incorrect results when the form is in the spotlight. Or the AI rhetoric is convincing or plausible.

I recall a tweet by Altman, leaking the launch of GPT-5, praising their new model's answer to a prompt about thought provoking TV shows about AI. The X thread that followed was about the form ("em-dashes are still there!") and nearly nobody cared to evaluate that neither shows recommended were about AI. They weren't, or at least, were very debatable as belonging to the genre.
by gf000 | 2025-09-08 07:00:01+00:00
> I feel as if a lot of multipliers have happened that he didn't anticipate

Such as? I think his essay still stands the time that no single multiplier is even close to an order of magnitude productivity boost, with the exception of already existing code.

LLMs are possibly the biggest change to how software is developed, but they are also nowhere near this magnitude - if any - in case of more complicated software.
by doganugurlu | 2025-09-08 07:00:08+00:00
If the VISA issuing officer will actually verify anything, it’s a reasonable expectation (dare I say, obvious) that the applicant must be a resident of the country where the embassy is.

You can’t expect a person living in country X to validate the documents from Y country. It’s quite unreasonable to expect that they will even understand the language the document is in.

If the claim is the VISA issuing officer already doesn’t verify anything and therefore familiarity with the language and system of country Y isn’t necessary, that’s a different discussion.

The thing to fix here is requiring that someone already in US has to go to a consulate to renew/change their VISA. For someone who went to college in US for 4 years, and then did OPT for ~2 years, it’s meaningless for them to go to their home country to apply for an H1B, because all the documents they will bring will be from the US and the home country consulate personnel may not even be fit to check the validity of those documents.
by IanCal | 2025-09-08 07:00:58+00:00
Because the set of problems we make to be solvable with code is huge and the world is messy. Many of these things really are at a very high level of abstraction and the boiler plate feels boilerplatey but is actually slightly different in a way not automatable. Or it is but the configuration for that automation becomes the new bit you look at and see as grunt work.

Now we have a way we can get computers to do it!
by MangoToupe | 2025-09-08 07:01:15+00:00
I find it hilarious how painful starbucks has made the process of ordering coffee. I only drink drip coffee and think we deserve a distinct queue. This phenomenon has, a little distressingly, spread to places like dunkin donuts. People love to drink their sugary milk with a splash of coffee, I guess. I don't begrudge them this but I do question paying $7 a day for what must be a significantly-increased chance of getting diabetes. Curiously, these same people often turn their nose up at equally-sugary soda. You'd think people would just learn to make this at home with a moka pot and a milk skimmer that costs less than what they paid for a single drink...

Between this and the inexplicably high cost of hot black coffee, i've just given up ordering from "coffee shops" and buy it from wendys and mcdonalds instead. The coffee is both cheaper and delivered faster and it could taste a lot worse.
by defrost | 2025-09-08 07:01:40+00:00
> Personal computers at home were NOT.

Subjective. I'm still in touch with a wide circle of both genders who had PC's at home back when we collaborated on projects together.

eg: one of these authors: https://global.oup.com/academic/product/geometric-mechanics-...

had a father who sold early Apple & IBM home computers, much fun was had by my circle building transputer array's and other such things in back sheds.
by pjmlp | 2025-09-08 07:01:41+00:00
One of the reasons CUDA won over OpenCL, was that NVidia, contrary to Khronos, saw a value in helping those HPC researchers move their Fortran code into the GPU.

Hence they bought PGI, and improved their compiler.

Intel eventually did the same with Open API (which isn't plain OpenCL, rather an extension with Intel goodies).

I was on a Khronos webminar where the panel showed disbelief why anyone would care about Fortran, oh well.
by tomhow | 2025-09-08 07:01:55+00:00
Please don't do this. If you want to get your project seen on HN, just email us (hn@ycombinator.com) and we'll review it for you and if we think the audience will like it we'll consider if for the second chance pool (https://news.ycombinator.com/pool, explained here https://news.ycombinator.com/item?id=26998308).
by sigmoid10 | 2025-09-08 07:03:13+00:00
It is definitely because it's a smaller model. TPUv7 has ~10% lower flops at FP8 and 33% lower memory bandwidth than Nvidia Blackwell cards. Add CUDA to the comparison and they'll probably be even worse at real world utilization. Grok is already running on Blackwell cards and although there's little info on GPT5, I doubt they are behind.
by gf000 | 2025-09-08 07:04:09+00:00
AI solves "essential complexity" the same way they solve the Halting problem...

These are fundamental CS concepts, you don't solve them.

Also, I would first wait for LLMs to have reliable reasoning capabilities on trivial logic puzzles, like Missionaries and cannibals, before claiming they can correctly "reason" about concurrency models and million LOC program behavior at runtime.
Show HN: Auto-copy all tabs and YouTube transcripts for AI (Chrome extension)
by brynlai | 2025-09-08 07:04:16+00:00
Noticed I was using AI Studio more often, and copy pasting content from my tabs into it.

For example, documentation, articles, blogs and YouTube videos.

It was annoying, especially if I wanted the transcripts from YouTube videos.

I'd open 20+ tabs. Click "View More," drag & copy all the transcripts, repeat 20 times.

And sometimes it would be 50+ tabs.

So I built this extension to do it for me.

Was curious if anyone else had this problem and maybe this could help them too, so I decided to put it on the Chrome Web Store.
by pjmlp | 2025-09-08 07:04:51+00:00
Until Rust gets into any of industry compute standards, being a nicer language alone doesn't help.

Khronos standards, CUDA, ROCm, One API, Metal, none of them has Rust on their sights.

World did not back OpenCL, because it was stuck on a primitive C99 text based tooling, without an ecosystem.

Also Google decided to push their Renderscript C99 dialect instead, while Intel and AMD were busy delivering janky tools and broken drivers.
by tripletao | 2025-09-08 07:06:19+00:00
> If PRNG sequence is reused to generate more shuffles, then the next shuffle can be predicted from the previous one.

That's theoretically true by a counting argument, but for a CSPRNG the only way to compute that next shuffle costs about as much computationally as brute force. 128 bits is enough to make that infeasible, though 256 may be preferable for the usual abundance of caution.

The number of permutations doesn't matter here, since an attack becomes computationally infeasible before it becomes counting infeasible. It's also possible for a practical attack to exist even when the output can't be predicted exactly, since statistical information is still valuable.
by NKosmatos | 2025-09-08 07:06:36+00:00
The scene is not what it used to be, but it's still alive and will remain for decades. We "old-timers" were lucky to be around the 90s when the demo groups and parties were on full swing.

There are many groups and parties to mention, but for those interested have a look over at: https://www.pouet.net/toplist.php

https://files.scene.org/

https://assembly.org/en/articles/assembly-summer-2025-demosc...
by Podrod | 2025-09-08 07:06:49+00:00
I don't think they ever stopped using the name. The wiki article has Sound Blaster audio devices listed as being released up to 2021 and a quick search on Amazon shows they're still selling them brand new.

https://en.m.wikipedia.org/wiki/Sound_Blaster

Guessing the kickstarter is for some retro thing judging by the image of their old talking parrot on that announcement page.
by KronisLV | 2025-09-08 07:07:17+00:00
If you are in circumstances where the answers to those questions are a resounding "No" then you should just set up the tooling to format the code on save / commit and perhaps to make the CI complain if anyone skips that and leave it at that.

Furthermore, instead of nitpicking over small details, it can actually be a good idea to just leave everything on default, forgo whatever your individual style might be and stick to what's been deemed to be good enough as the default - so the code will look more familiar to anyone who picks it up (and has used the tools you use for linting and formatting). Yes, formatting is different from linting; though if you set up one, you might as well do the other.
by topspin | 2025-09-08 07:07:23+00:00
I do. I've been buying Intel for the same reason as the author: I build machines that don't have glitches and mysterious failures and driver issues and all the rest of the garbage one sees PC assemblers inflict on themselves. Make conservative choices and leave ample headroom and you get a solid machine with no problems.

I've never overclocked anything and I've never felt I've missed out in any way. I really can't imagine spending even one minute trying to squeeze 5% or whatnot tweaking voltages and dealing with plumbing and roaring fans. I want to use the machine, not hotrod it.

I would rather Intel et al. leave a few percent "on the table" and sell things that work, for years on end without failure and without a lot of care and feeding. Lately it looks like a crapshoot trying to identify components that don't kill themselves.
by kqr | 2025-09-08 07:08:00+00:00
The thing about making invalid states unrepresentable is that we are often overconfident in what counts as invalid. What counts as valid and invalid behaviour is given by the requirements specification, but if there's anything that changes frequently throughout development, it's the requirements. What's invalid today might be desirable tomorrow.

Thus, we have to be careful at which level we make invalid states unrepresentable.

If we follow where Parnas and Dijkstra suggested we go[1], we'll build software with an onion architecture. There, the innermost layers are still quite primitive and will certainly be capable of representing states considered invalid by the requirements specification! Then as we stack more layers on top, we impose more constraints on the functionality that can be expressed, until the outermost layer almost by accident solves the problems that needed to be solved. The outermost layers are where invalid states should be unrepresentable.

What often happens in practice when people try to make invalid states unrepresentable is they encode assumptions from the requirements specification into the innermost layers of the onion, into the fundamental building blocks of the software. That results in a lot of rework when the requirements inevitably change. The goal of good abstraction should be to write the innermost layers such that they're usable across all possible variations of the requirements – even those we haven't learned yet. Overspecifying the innermost layers runs counter to that.

In the example of the app market place, any state transitions that are well-defined should be allowed at the inner layer of the abstraction that manages state transitions, but the high-level API in which normal transitions are commanded should only allow the ones currently considered valid by the requirements.

[1]: https://entropicthoughts.com/deliberate-abstraction
by masklinn | 2025-09-08 07:08:21+00:00
> why is Rust performance contingent on a C malloc?

Because Rust switched to “system” allocators way back for compatibility with, well, the system, as well as introspection / perf tooling, to lower the size of basic programs, and to lower maintenance.

It used to use jemalloc, but that took a lot of space in even the most basic binary and because jemalloc is not available everywhere it still had to deal with system allocators anyway.
by lock1 | 2025-09-08 07:09:33+00:00
IMO, rather than focusing on flexibility vs inflexibility when deciding "tight domain model" or not, it's much better to think about whether your program requirement can tolerate some bugs or not.

Say we have a perfect "make illegal states unrepresentable" model. Like what you said, it's kind of inflexible when there are requirement changes. We need to change affected codes before you can even proceed to compile & run.

On the other hand, an untyped system is flexible. Just look at Javascript & Python ecosystem, a function might even contain a somewhat insane and gibberish statement, yet your program might still run but will throw some error at runtime.

Some bugs in programs like games or average webapp don't matter that much. We can fix it later when users report the bug.

While it's probably better to catch whether an user can withdraw a negative balance or not at compile time, as we don't want to introduce "infinite money glitch" bug.
by zokier | 2025-09-08 07:09:45+00:00
To me one of the problems in modern demoscene is that modern PCs (especially GPUs) are so ridiculously powerful that full fat PC demos struggle to fully take advantage of it, at least in a way that is apparent to viewer. To me it feels like the emphasis has shifted more on the content side than purely techical excellence.

Sizecoding is another matter, and arguably the more interesting side of the scene these days. But it is kinda sad that we need artificial restrictions to make things interesting rather than trying to exploit every drop of perf you can squeeze from the computer.
by rthrfrd | 2025-09-08 07:10:36+00:00
I think what's interesting/telling is you view (3) as less desirable.

Alternatively, you could have spent that half hour on the train exercising your own creativity to try and satisfy your curiosity. Whether you're right or wrong doesn't really matter, because as you acknowledge it's not really important enough to you to matter. Picking (2) eliminates all the possible avenues that might have lead you down.

I'm not saying one is better than the other, just that you're approaching the criticism on the basis of axioms that represent a narrow viewpoint: That of someone who has to be "right" about the things they are curious about, no matter how trivial.
by davydm | 2025-09-08 07:11:51+00:00
it's not a panacea, but sticking to strict tdd also really helps, for the same reason too: it makes you think about the problem before just jumping in to "solve" it

if you're doing it strictly, you should be following the red/green/refactor approach: 1. write a test which inches forward the expectations of capabilities from the system - the smaller the step, the better; run this test and verify that it fails for the right reason(s) - ie, that it's actually failing at the point you need to extend 2. write only the code required to solve the test - this may seem obtuse at first, but even obtuse solutions (eg a function which just does `return 0;`) are a valid start - rein in your desire to solve the whole thing right now - no test, no code; now re-run the test until you get a green, tweaking if you have to to pass the test. Reaching for a debugger is valid, but shouldn't be your first choice. 3. refactor - this is the part a lot of people leave out. It doesn't just apply to the prod code either - is there a pattern emerging in tests? could you simplify the test to make it easier for a stranger (you in 2 months) to read and understand what's going on, what the test requires, and, if it breaks, why?

the process forces you to slow down a bit into steps of incremental extension of the system - it forces you to re-read your code at least twice, and to have a proper plan before writing production code. It provides a test suite to run against regularly to prove that regressions haven't been introduced. You should 100% have this running somewhere, and github actions have made this really trivial to have continuous-integration-style testing on your code.
Show HN: C++ Compiler Support Page
by cemdervis | 2025-09-08 07:12:29+00:00
Hi HN,

I have created a webpage that displays all C++ features since C++20 in a simple, searchable table.

It is intended to serve as a quick reference for C++ developers, whether as support for cross-platform development or simply to track the current support status out of curiosity.

I created it as a simpler, more structured, and more up-to-date alternative to the cppreference compiler support site. Please note that the page intentionally does not list LWG and CWG papers. This might change as I am continually updating the site and trying out new ideas.

Questions, feedback and suggestions are appreciated, either here or in the form of GitHub issues.
by internet_points | 2025-09-08 07:12:38+00:00
There's data definitions:

data Constant = Constant Double deriving (Show)

is a bit like `#[derive(Debug)] struct Constant(f64);`, ie. it's just a wrapper around a double and you can print it.

And there's typeclasses. Show is a typeclass. You can think of them as interfaces, so `instance Sqlite DB where open dsn = ...` is a bit like saying Sqlite is an implementation (instance) of the DB interface (typeclass). The typeclass itself could be defined like `class DB where open :: String -> IO ()` meaning the interface requires a function taking a string and having IO access (and of course you can require more than one function in your interface/typeclass).

The article also uses typeclasses with parameters. Parameters (and functions and variables) are written lowercase, while classes and constructors and such are capitalized, so

class (Expr e) => Stringify e where stringify :: e -> String instance Stringify Constant where stringify (Constant x) = show x

means there's an interface Stringify that's parametrized over some type e (and that e in turn has to be in the Expr typeclass).
by sireat | 2025-09-08 07:12:38+00:00
Like Simon I've started to use camera for random ChatGPT research. For one ChatGPT works fantastically at random bird identification (along with pretty much all other features and likely location) - https://xkcd.com/1425/

There is one big failure mode though - ChatGPT hallucinates middle of simple textual OCR tasks!

I will feed ChatGPT a simple computer hardware invoice with 10 items - out comes perfect first few items, then likely but fake middle items (like MSI 4060 16GB instead of Asus 5060 Ti 16GB) and last few items are again correct.

If you start prompting with hints, the model will keep making up other models and manufacturers, it will apologize and come up with incorrect Gigabyte 5070.

I can forgive mistaking 5060 for 5080 - see https://www.theguardian.com/books/booksblog/2014/may/01/scan... . However how can the model completely misread the manufacturers??

This would be trivially fixed by reverting to Tesseract based models like ChatGPT used to do.

PS Just tried it again and 3rd item instead of correct GSKILL it gave Kingston as manufacturer for RAM.

Basically ChatGPT sort of OCRs like a human would, by scanning first then sort of confabulating middle and then getting the footer correct.