I think that what technical people fail to understand is that a lot of the time, "compliance" is not the same as a binary compiles/does not compile. For a lot of rules/regulations, compliance means "making enough effort that legal is willing to back you up".
A system which will just randomly decide to give the legal team reasons to not back you up is:
* A system whose output will get brought up in lawsuits and make legal's job harder.
* A system that will make the dev team perpetually chase its tail while it oscillates between the several different valid interpretations of the rules.
Odd take. So if it identified 17 real gaps and helped fix them, the fact it was wrong about one gap, and the appropriate humans caught it and no harm was done, the whole thing is useless?
Not saying that is the situation, I don’t know. But if “one error is too many” is your point of view… do you think the humans in these orgs are 100% perfect 100% of the time?
> So if it identified 17 real gaps and helped fix them, the fact it was wrong about one gap, and the appropriate humans caught it and no harm was done
How many gaps have humans not caught?
> But if “one error is too many” is your point of view
Yes, in regulated industries "one error is too many" is the only right approach.
Yes, humans also make errors, and there you have a range of options: from tracing and finding the causes of the error (and tightening processes) to literally jailing those responsible. Your hallucination machine will happily "identify" 17 gaps, and create 34 more. And no, there are no processes to make it better. The "make no mistakes" incantation will happily be ignored for obvious reasons, regardless of how many forms of it you throw at it.
It doesn't seem like you're engaging with the material circumstances described above. What does it mean for a human to not catch that a part of a codebase is actually compliant with regulations? What does it mean for the hallucination machine to create 34 more gaps when it doesn't appear to have more than read access? How would it not be useful to have a machine that identifies 17 real crimes that your highly regulated business is unintentonally committing even with a 90% false positive rate?
In a regulated industry 90% false positive rate is indistinguishable from 100% failure rate. Hell, in any industry.
You're basically saying "we need human review for literally everything AI outputs because we have no way of saying whether anything it produces is hallucination or not. And since it produces plausible-sounding things really fast, it puts enormous burden on human reviewers".
I just don't understand where your position is coming from here. You can't distinguish between a machine that says "here, look at these 170 results, 10% of them are highly serious problems that you should address, you should have some people look into that" and one that shrugs and says "I dunno, maybe just double check everything"? I assume you've come to this conclusion based on some reasoning, but you're not sharing it in this response AFAICT.
> You can't distinguish between a machine that says "here, look at these 170 results, 10% of them are highly serious problems that you should address
The machine doesn't say that. It says "Here are 170 completely correct and verified results".
You have to check and verify all of those results yourself, and on any given day it can be anywhere from 0% to 100% incorrect.
> I assume you've come to this conclusion based on some reasoning, but you're not sharing it in this response AFAICT.
The reasoning comes from actually working with AI tools. And the reasoning can be seen in the actual comment this tgread started from: https://news.ycombinator.com/item?id=48434824
We're assuming per earlier hypothetical that it has a 10% correctness rate. You had said
>In a regulated industry 90% false positive rate is indistinguishable from 100% failure rate
So defending that position on the basis of it not actually being a 90% failure rate would mean you shouldn't have taken it in the first place. The fact that the LLM lies about its failure rate is nearly irrelevant; the machine could output the literal string "The following is 90% likely to be a false positive: " followed by the LLM output.
The reasoning in the comment that started the thread is "it's annoying to redo human review". Your position as I understand it is that there is no or negative business value to a tool that spit out a list of potential issues of which 10% are real issues with your business. This is what I fail to understand. This would be an incredibly useful first step towards any audit and would save loads of money. Why not?
Congrats. I'm pretty sure I've helped more than a few friends and family members debug a router. Most of them didn't even know what a router was. Much harder to Google for specific issues like that, hence the 1 billion people that use AI globally.
Pretending that AI is not incredibly useful is... disingeuous
How'd you infer that I don't find AI useful from my statement? Of course I do.
I am merely saying that the argumentation in the "poem" is not specific to AI.
The grandma that would have phoned her nephew to fix the phone will still do the same thing now. She will not have magically switched to querying LLMs after a lifetime of technological illiteracy.
The tech-savvy person that uses AI today would have been more than capable than figuring out how to fix their router by using Google even without prior networking skills/experience 5-10 years ago.
Using AI to solve these problems is a novelty for a specific subset of the population. And the topic does matter.
Even the somewhat tech-illiterate mom would have been able to Google a recipe 10 years ago, or watch an Instagram reel 5 years ago. They were surely not going to call their friends to ask instructions on how to make an apple pie.
Pretending this is an AI novelty is indeed disingeneous.
I found this quite cringy and an attempt at pulling at one's heartstrings due to the lack of a strong argumentation.
I wouldn't have called a friend for a meal plan or to figure out a hiking path 10 years ago, I would have used a search engine.
If I want to talk to a friend, I don't need an excuse to do so. And I'm not going to waste their time by asking something I can easily figure out on my own, today with AI, years ago with Google, and prior to that with printed material.
The anti-AI craze is just as bad as the "AI will solve everything" crowd.
As others have echoed elsewhere in these responses, this idea can very easily be applied to the broader internet (eg, your Google searches) as well. Not everything is answered with Google. To your point about figuring out a hiking path, I backpack very regularly - search engines consistently return the same sets of results, and I've found wonderful places by talking to friends or others in the community that I, to this day, don't come across when searching for things online.
Just because it gets results doesn't mean there isn't more out there, and that there isn't a benefit to engaging with your community.
I see the same sameness in the results when I use AI to explore such subjects. There's a certain level of homogeneity that comes with relying on Google, Facebook/Instagram/Twitter, and AI for our answers.
Very interesting, this is the first time I hear about segmented iterators and hierarchical algorithms.
I faced a similar issue myself when implementing a chunked vector a la `std::deque`, but opted for callback-based internal iteration, i.e.
void ChunkedVector::forEach(auto&& f)
{
for (auto& chunk : chunks)
for (auto& item : chunk)
if (f(item) == ControlFlow::Break)
return;
}
Where `ControlFlow` is just:
enum class [[nodiscard]] ControlFlow : bool
{
Continue,
Break
};
This is massively simpler to implement, and can model simpler algorithms such as `for_each`, `fill`, `transform`, `count`, `accumulate`.
It's sometimes inferior in terms of ergonomics, and cannot express more complicated algorithms or iteration patterns (e.g. partial range, going backwards), but so far it has served me well.
Just something to consider if implementation simplicity is the priority and there's no need for a very generic suite of algorithms.
Note that my expectation would be that the non-boxed form would be as trivial as adding `[NonBoxedUnion(SomeImplStrategyChoiceEnum)]` (or `[NonBoxedUnion]` for some default strategy choices that likely are ok).
This would give you extremely fine grained flexible choice on how you wanted your non-boxing union to work. There's no single right answer. There are just tradeoffs in terms of space/speed/copying-costs/memory-safety/etc.
I think it would make the most sense as people who care about boxing will have very different views and needs in terms of things like space, casting costs, copying speed etc.
The vast vast majority of users do not need to care at all. And for that, a boxed approach works exceptionally well.
Erm... that's not just false. The point of templates is generic programming, reusable components. If you don't put them in a header, you're not reusing them much. And if you have to "selectively pick TUs where they're instantiated", you're basically admitting that you have to invest effort to reduce compile times. You are refuting the very point you're making.
C++ templates _are_ slow to compile. They require running something like a dynamically typed VM in the compiler.
**** Template sets that took longest to instantiate:
833 ms: sf::base::Optional<$> (911 times, avg 0 ms)
Each individual instantiation of this class is sub 1ms.
Including the header itself takes 3ms.
I'm sure I can optimize it even further if I wanted to.
---
Now to refute your other incorrect claims:
> The point of templates is generic programming, reusable components.
That's ONE use case. A more general use case is just reducing code repetition in a type-safe manner, which is extremely useful even within the same translation unit. Another use case is metaprogramming. And I'm sure I can come up with more. Templates are a versatile tool.
> And if you have to "selectively pick TUs where they're instantiated", you're basically admitting that you have to invest effort to reduce compile times.
...well, yeah? Of course you have to put in effort to reduce compile times. That doesn't undermine my point at all.
Not slow to compile? 0,833 seconds extra compile time for a trivial utility class that doesn't do anything interesting other than make something perceived "safer"? Does that mean that each of the 911 instantiations took several million CPU ticks? You could convince me that it's not slow if it was 2-4 orders of magnitude less.
As I wrote elsewhere, 1 second is a timespan where we could aim to compile 1 MLOC of code on a single core.
> A more general use case is just reducing code repetition in a type-safe manner
As I said -- code reuse. And interestingly your Optional.hpp is a header...
That's a strange dismissal. `Optional<T>` isn't "perceived" safety -- it eliminates a whole category of bugs (null dereferences, uninitialized reads) at the type-system level, with zero runtime overhead versus a raw pointer or sentinel value.
If you think that's uninteresting, that's an aesthetic preference, not a technical argument.
But let's set that aside, because it's also irrelevant to the compile-time claim.
The point of the example wasn't "look at this fascinating class," it was "here is a real template, used 911 times across the codebase, in a public header -- exactly the scenario you said would be slow -- and it costs under 1ms per instantiation."
You can swap `Optional` for any non-trivial template of similar complexity and the numbers will look similar.
On your 1 MLOC/sec benchmark: that's a fair reference point for C-like code, but it's not the right yardstick for template instantiation, which is doing semantic work (overload resolution, SFINAE, constraint checking) that a C compiler simply isn't.
Comparing them is comparing different jobs.
The honest question is whether template compilation is slow relative to what it's actually doing, and in well-structured code, it isn't.
And yes, `Optional.hpp` is a header -- that's the whole point of the demonstration. I'm not claiming you should hide every template in a .cpp file. I'm claiming that even templates in headers, instantiated hundreds of times, are cheap when written with compile times in mind.
The "put templates in .cpp where it makes sense" advice is for the specific cases, not a blanket rule.
Did it find any real potential issue, optimization/simplification opportunities, or sparked any thought-provoking discussion within your organization?
Or was it purely a net negative experience?
reply