Recent submissions

Comment · 4 hours ago
People hate AI because culture is being turned into slop in front of our very eyes. There's clear evidence that people collectively reject:

1. AI games

2. AI Art

3. AI Music

4. AI literature in most forms, except for factual text like search

Or at least, they won't pay money for it

AI hatred isn't being pushed by people with a narrative. I can't use AI for my game, because it'll sell £0 if I do. That's the net result of millions of other people telling me that they despise AI and won't purchase my product if it contains any AI, and I'm just making a business decision

Also google and some other big tech companies were widely loved for a while. Microsoft/gates managed to entirely rehabilitate their image at one point, and google was seen as one of the good guys. Those days died with the cambridge analytica scandal, and there's no evidence its coming back

Comment · 9 days ago
Humans can be wrong, but luckily we have an entire process for dealing with this, which is broadly called this new fangled 'science' thing
Comment · 9 days ago
You've got under 5 minutes to decide whether or not a widely reported critical security vulnerability actively being exploited in the while is severe enough to warrant taking down your site or not. The downside for taking down your site is approximately 0, and the upside is that you don't get shrekd

No security expert can or should work that fast. Its a completely reasonable thing to do given the hyperbolic reporting just in case it turns out to be true. Some websites being down for a few hours doesn't end the world

Comment · 9 days ago
Because the tools don't understand the papers either. We know for a fact that:

1. These tools are wrong a significant % of the time

2. They have an upper complexity bound where they start to fall apart

Relying on AI to check AI papers is a terrible idea

Comment · 9 days ago
For game development its hard to see how Rust can really replace C++ in practice. It'll take 15 years at minimum to replace the current development ecosystem for building games
Comment · 11 days ago
I've never particularly enjoyed programming on its own merits, but also think AI is crap. Its mainly because AI clearly accelerates the parts of programming that I've found tend to lead to software projects falling apart, ie not understanding the code

The last 20 years of experience have told me that that's the #1 variable that correlates with the death of a project, so I'm in no hurry to speed that along. People have been trying to find some way to skip that difficult step of actually understanding what's happened since programming was invented, and its always a bad idea - because that process of internalising a projects structure is the single most valuable thing for a project. Creating a project structure that can be internalised by human beings - and then doing that - is software engineering

Comment · 13 days ago
You absolutely can make assumptions about what happens if you set the flag, and the spec guarantees that you can!

There's no difference between the flag being set/unset by your build system, and #define-ing or #undef-ing the symbol in code

Comment · 15 days ago
That's not what the C/C++ spec says people can rely on with assert/NDEBUG. Like don't get me wrong, you can do what you want, but you can and will break code in ways that introduce memory unsafety with this approach
Comment · 15 days ago
You use the status of NDEBUG to control whether or not your asserts are run. I don't understand how this is complex

If you want to use asserts, you need to control the definition of NDEBUG. You either do this with your build system (common), or manually (slightly less common). This is literally <assert.h> 101

The preprocessor is widely used for a variety of things when its necessary, including #includes and #defines, because there's literally no other mechanism for this. Its bizarre to say that nobody controls the definition status of NDEBUG because people don't use the preprocessor

Comment · 15 days ago
Blindly replacing #include <assert.h> to look up something incompatible that doesn't respect NDEBUG seems like a remarkably bad idea
Comment · 15 days ago
Of course? You simply undefine NDEBUG in your library

Its trivially easy to guarantee that an assert always runs, and its well defined behaviour according to the spec. There's no reason not to if you want to use asserts in a way that guarantees that they always fire, which is a supported use case. Its common practice

There's no equivalent for contracts

Comment · 15 days ago
Its pretty easy for me to guarantee that my asserts will all always be run via NDEBUG. I can't make that same guarantee for contracts
Comment · 16 days ago
This is the biggest problem with contracts, there's simply no way to actually say "please always execute this check". A lot of people replying seem to think that the critique is with the concept of contract based programming, but the C++ version of contracts is just weird

The programming model for C++ contracts as described by the authors, and spec, is that they are 'ghost code'. You must never assume that a contract check is actually executed, even if you've asked your compiler to execute your contract checks. This is because ABI/ODR problems can and will cause your contract checks to be deleted, as well as the 'observe' contract mode which is a strange one

So its hard to know what the use case for them is as a result. You can't use them for safety checks, because you must assume they won't be run. Hilariously, they actually introduce safety problems vs asset: Eg take two pieces of code:

    assert(p != nullptr);

    assert(p->some_value());
vs

    contract_assert(p != nullptr);

    contract_assert(p->some_value());
People mistakenly transform #1 into #2 unconditionally, not realising that this is actually a misuse of the contracts feature. It can, and will lead to undefined behaviour - while being perfectly well defined with asserts

I have a feeling that in 10 years the advice will be to never use contracts in anything approaching code that needs safety, as they're generally less safe than using an assert for no real reason. So what's their use case?

Comment · 16 days ago
Getting involved with epic games as a game developer feels like willingly feeding yourself into the mouth of an open shark. Yeah maybe they have a better cut, but I'm still not doing it

Valve rightly get a lot of flak for the gambling and high % cut, but you do get a functional useful service in return at least, that doesn't appear to be actively trying to screw you over

Comment · 19 days ago
I've seen this with godot. People are letting their agents blindly file AI generated PRs even though Godot specifically bans this, and then coming in and giving a very weak apology when they get called out by the devs. A lot of the bugs are incredibly low priority bugs as well that no reasonable person would ever really run into, with these huge long wordy slop reports

Its kind of appalling that people think this is an acceptable way to behave

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton