SuperV1234

He decided to use LLM assistance exactly because he's an extremely competent guy.

We're getting closer and closer to the day we can have an Opus-like model running locally. The dream!

This is my experience as well. Some of my coworkers ask questions in chat that could be trivially solved by querying Claude. If I were tasked with answering that question, the responsible thing to do would be to query Claude rather than risking a manually-written incorrect answer off the top of my head. So yes, I will reply with "Claude says..."

Human slop.

If someone answers your question with "Claude says..." it's a clear indication that you should've asked the question to an LLM yourself before bothering a human.

This is just the new version of LMGTFY.

> AI is the reason our software stack is overengineered to the 10th degree

Complete BS.

Expected anti-AI psychosis propaganda but was pleasantly surprised.

> 2023 > 200 upvotes

typical hn

Completely agreed. Insane how everyone's free and open-source ideals seem to disappear when they feel personally attacked or scared by a new technology.

We have open-source models, and they're getting better and better.

That makes it even worse -- spending that much time with AI should make it glaringly obvious how valuable it is.

Taking your advice to heart -- fuck it, I'll make my software and art with generative AI assistence despite any possible backlash :)

It's also ironic how the "every programmer I know has basically gone insane over the last couple of years" sentence applies to author of the article as well. The ego, luddism, and fear of change is real.

> The main problem, however, was code quality.

> The sleight of hand misdirects the reader away from the main way bugs are eliminated: by dedicating engineering resources to it.

Perhaps the amount of bugs comes from using a C-like language that requires meticulous manual care to avoid writing runtime bugs.

Even C++ would be a safer choice because of RAII.

When you have to dedicate significant resources to avoid/fix runtime issues that are made impossible at compile time by other languages, the programmer isn't entirely at fault.

Is that all that Mythos did?

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?

How does this compare to frontier models?

Data Oriented Design rocks. It was the subject for my CppCon 2025 keynote: https://youtube.com/watch?v=SzjJfKHygaQ

It's not that simple.

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.

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.

And if my router wasn't working 5 years ago, I would have first used a search engine and tried to figure it out on my own.

Pretending it's an AI novelty is... disingenuous.

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.

Finally, a sane policy.

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.

Boxed, and needs complex incantations to avoid the boxing. Meh.

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.

So? The original argument was about the "ugly" syntax that the user didn't want to interact with nor read. I proved that there's no need to do so to consume reflection utils.

Alright, I'll bite.

This is my `sf::base::Optional<T>` template class, a lightweight replacement for `std::optional` with same semantics: https://github.com/vittorioromeo/VRSFML/blob/master/include/...

This is what ClangBuildAnalyzer reports:

  **** 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.

C++ templates are not slow to compile.

I'm bullish on LLM-assisted development but this is just a very stupid way of performing such a critical migration.

That's just false. Templates are not slow to compile at all, and you can selectively pick TUs where they're instantiated.

My entire VRSFML codebase compiles from scratch in ~4s and I liberally use C++ features, I just avoid the Standard Library most of the time.

Templates are not inherently slow, people just don't know how to use them and don't know how to control instantiation.

Most people still think that templates have to go in header files, which is also just plainly false.

This is a myth, C++ is not inherently slow to compile. It's the standard library that is very bloated and the main culprit for slow compilation.

Utter BS. Compilation times matter for productivity, developer motivation, iteration speed, CI turnaround time, and so on.

I'm sure you wouldn't say "it doesn't matter how long it takes to compile" it if took days. So where do you draw the line? Regardless, it matters.

No, it objectively isn't objective.

Package? We're suggesting to copy paste 5 lines and stick them into a header.