rfgplk

C++ is actually obscenely complex, I don't deny that. Just mastering object lifetime rules is crazy difficult due to all the edge cases, but it comes with the territory.

But isn't this a problem with all code? Looking at a Rust function signature how can you be sure that it does what it says it does? Or python?

The standard library implements really do suck (in some cases), but this should be separated from C++ (the language). Even the standard splits the language grammar from the standard library cleanly.

Not yet, I might one day.

This is gonna be a long critique, I'll try to keep it concise.

C-like C++ is good start, if code doesn’t require more complexity don’t add unnecessary C++ complexities.

C is almost obsolete nowadays. Not to mention that C++ is effectively a strict superset of C (nearly 99% of the C standard is in C++) and the few features that aren't are included as compiler extensions (VLA, restrict keyword, nested functions). There are a handful of C features that aren't in C++, and for very good reason (most of them suck). When was the last time you ran into a C library that a pure C++ compiler couldn't compile? Only if someone decided to spam the new keyword all over the codebase (or something similar).

In general case code should be readable to anyone who is familiar with C language.

Most C++ already is? Even very template heavy C++.

Don’t do this, the end of “design rationale” in Orthodox C++ should be immedately after “Quite simple, and it is usable. EOF”.

A lot of the methods in that document are necessary to make C++ shine, especially template metaprogramming.

Don’t use exceptions.

Optional but irrelevant.

Don’t use RTTI.

.. Why? Reimplementing RTTI in C will give you almost the same overhead.

Don’t use C++ runtime wrapper for C runtime includes (<cstdio>, <cmath>, etc.), use C runtime instead (<stdio.h>, <math.h>, etc.)

.. Why? Those wrappers all include the "raw C runtime" under the hood (literally they do #include <stdio.h|xx>. Near 0 compiletime overhead?

Don’t use stream (<iostream>, <stringstream>, etc.), use printf style functions instead.

This is a design decision.

Don’t use metaprogramming excessively for academic masturbation. Use it in moderation, only where necessary, and where it reduces code complexity.

There are many programs that are _impossible_ to write in a finite time without metaprogramming. How will you (with zero runtime overhead) dispatch a function with a variable arity of random types to a handler that requires exactly that type of function? Arbitrarily? In C++ it's possible, in C it isn't.

One thing I've noticed about a lot of these "strict C" developers is that quite often they actually refuse to learn C++. One of the most common complaints of C developers regarding C++ is "it does things behind the scenes/performs magic", often with regards to operator overloading. When they refuse to actually look at the implementation (y'know you can check if an operator has been overloaded) AND they refuse to acknowledge that a huge chunk of "pure C" does HEAPS of magic behind the scenes (that the developer has no idea about) unless they've actually studied the spec in detail. Malloc and memory allocation methods are at least 10k+ lines of code for instance.

I've developed a style that I legitimately call Heterodox C++ (mainly due to the popularity of Orthodox C++), it is effectively a purely functional & metaprogramming heavy style of C++. Quite the opposite of this, not everyones cup of tea, and it won't fit into every codebase but it is incredibly powerful. The template metaprogramming C++ offers is the most powerful of any imperative language, and (subjective opinion) is second only to Lisp, but few people make use of it. With some of C++26 features you can almost even replicate most of Rusts safety features in pure C++ (via function tagging + reflection)

A few comments.

VCs think, 'Apps are risky, infrastructure is safe,' so they invested in AI infra.

First off, this isn't even infra in the infra sense of the word. Infrastructure implied something physical, a pure software product can almost never be considered 'infra'. A tool maybe, but not 'infra'.

VCs can also be irrational and driven primarily by personal connections rather than reason. I didn't do a deep dive in this project/leadership, but often who you know is some important than what you produced. There's a reason why a lot of VCs go for the old motto of "I'd rather invest in an A team with a C product; than invest in a C team with an A product".

The calculus in “buy or build” has shifted for me over the last six months especially. If I can make an agent build it, I get the version that’s tailored for me.

I feel like this is really going to change the software industry moving forwards. Historically it was tedious and time consuming to actually develop tailored dev tools which is why so many organizations relied on third party solutions. When nowadays you can easily half bake something in a few hours and get it working, tailored _specifically_ to your needs.

$7m actually isn't a whole lot, especially if they hired a (larger) engineering team. Assuming their cali based, that's easily 150-200k per engineer, a team of 20 easily eats through that. Idk the specifics, but I don't the organization was fradulent, it could also be that they're going commercial and no longer want to maintain their oss stack

Made me laugh. Thanks :)

Like OK someone vibecoded an FPS in COBOL or Pokémon emerald in a web browser with web assembly? Ok good for them, piss off karma farmer.

Sorry, but most of these discussions reek of extreme gatekeeping. First off, neither of these things are impossibly difficult and are easily doable with some dedication by hand. LLMs simply accelerate the process, the human still has to come up with the architecture, _idea_ and plan to do something like this.

It's not impressive that Claude wrote it, it was impressive if you have written it, OP.

Do you have evidence that it's Claude written? Looking through the source it isn't clear to me, at all. Plus, even if it _was_ Claude/LLM assisted, why does that take away from the project?

Meaningless and easily bypassable. Will actually try coding up a tensor library with it, see if it sabotages anything.

If the claimed capabilities are true, Fable 5 is already at a superhuman level. We might see genuine unprecedented leaps in technology now, across all fields.

I'm actually working on something similar to this. Basically works as an additional preprocessed layer over C++. You can get some crazy results, but it's tricky to integrate with existing build tools without causing havoc.

void DoSomething(const void* p, size_t numBytes)

would be something like

template <typename T> void DoSomething (const T& ref) or void DoSomething(const T& ref, size_t numBytes) or C++20-y void DoSomething (const auto& ref)

If the class you're passing in already qualifies a size like member fn, template<typename T> requires requires(T t){ t.size(); } void DoSomething(const T& x){ ... x.size(); }

void DoSomething(const uint8_t* p, size_t numBytes)

This is awful you lose type info irreversibly.

template <typename T> void DoSomething(std::span<T> data)

You can do this but the above examples work just as well.

Or maybe something even more complicated, like this?

template <typename T, std::size_t N> void DoSomething(std::span<T, N> data)

// Or this? template <typename T, std::size_t N> void DoSomething(std::span<const T, N> data)

This is more explicit, not more complicated...

In this way, we still keep the clarity and simplicity of the function invocation: DoSomething(&data, sizeof(data));

Stripping types is not a good idea, especially because you'll run into object lifetime issues _REALLY QUICKLY_. You need to guarantee that the object is trivially copyable.

Very nice, fairly efficient too.

I don't like the explicit split of Newtonian and relativistic gravity, this is often how it's presented in educational content, but it creates too much confusion; for instance it gives the illusion that they are somehow separate theories even though Newtonian gravity is a limiting case of Einsteinian gravity when v << c and gravitational fields are weak (see Poissons eq for Newtons gravitational potential.

Lastly, you should consider rendering spacetime similar to Alessandro Roussels spacetime visualization https://www.youtube.com/watch?v=wrwgIjBUYVc; probably the best and most innovative one I've seen.

the result is some massive crap in nextjs that needs 10GB mem to compile, has 1000s of lint errors, dev logs in git (very noisy ones) and so on.

The anti-LLM propaganda is getting ridiculous at this point. No project "needs 10GB" to compile, unless you're working with astronomically massive repos, and _no_ LLM will _ever_ generate that. Lint errors (depending on cause) are either meaningless or a result of poor prompt engineering. If you want your project linted/formatted a certain way make it clear to the LLM.

Companies IPOing should be forced to put up their estimated market cap as collateral in cash. Oh what is that? You don't have $1 trillion in cash to put up? Cool, you're not a $1 trillion dollar company then.

Plus that's what the whole article is about. I'm not sure how you could've missed that?

Even if code typing goes away, a new breed of engineering will take it's place.

Exactly, time amortized LLMs are already unbeatable at this point.

You're assuming the current ensemble of commonly used software stacks is the most optimal there is. This assumption is simply wrong. Even looking at something simple like the office suite you can probably find countless areas where improvements can be made.

Something that I've been thinking about for the past year or so is coming to grips with the fact that the vast majority (anecdote) of software engineering work is not novel (and maybe that's okay)

Correction, essentially 0% of software is novel. Git wasn't novel. Chromium wasn't novel. Linux wasn't novel. Even C when it came out wasn't novel. Likewise Unix. They're all permutations of either prior knowledge, or evolutions of already existing concepts. They only might _appear_ novel to people who lack the depth to see what technology really is. Effectively applied physics (which has been solved for... over a few centuries at this point?) which itself is applied mathematics. There is novely to be found in physics and math themselves, but it's far out of scope of practical engineering.

C adopts defer

C will almost certainly adopt defer in the next revision standard. C++ (via RAII + scoped classes) already effectively has defer.

But the fact that it's unsafe means it's effectively unadoptable, no reason not to use C inplace of it.

Customers may build the software they need entirely in-house or via prompt-engineer consultants, without the need to buy software tools like today. It could be a very very different world.

Already happening. I know of a few places that have gotten such large gains from LLMs that they know have their engineers working on creating homegrown ports of popular services (Docker etc.).

Or just like a 700 or so 1-founder companies in the world and everyone else is without work?

This. But instead of 700 it's more likely that everyone will be a founder (more or less). It's already scary how easy it is to launch an MVP or produce prototypes with the latest models.

“Verify all facts and compliance requirements”

No. This is a disasterous instruction. Not only is it vague, but it's also meaningless. When giving instructions to an LLM your prompt must be concise and exact. Tell it _exactly_ which requirements need to be followed, ideally have it write or (preferably) pass audited tests to enforce these requirements. You also need to provide it with a hard source of truth it can rely upon. Instead of saying "verify facts", you're better off by saying "... make sure [whatever you're doing] matches with data at X.Y.Z, verify by running [instruction/command/program]"

I primarily use Opus for a Lisp-like DSL codebase (non public, closed source) and it genuinely has _never_ hallucinated. All it pulls from is BNF, language spec + examples. So I have no idea how people are getting it to hallucinate on _popular_ languages.

Those models simply don't hallucinate if you use them properly in any form. The only way they _might_ hallucinate is if you use the web based chat interface and give them zero context.