This might seem too suspicious, but that SOUL.md seems … almost as though it was written by a few different people/AIs. There are a few very different tones and styles in there.

Then again, it’s not a large sample and Occam’s Razor is a thing.

> _This file is yours to evolve. As you learn who you are, update it._

The agent was told to edit it.

It was modified by the agent.

> Do not enable container scanning, it just increases your bill, nobody ever looks at the scan results.

God I wish that were true. Unfortunately, ECR scanning is often cheaper and easier to start consuming than buying $giant_enterprise_scanner_du_jour, and plenty of people consider free/OSS scanners insufficient.

Stupid self inflicted problems to be sure, but far from “nobody uses ECR scanning”.

I hope this is a troll.

The best, or cheapest, or most-loved, or most extensible software is often written to be as small as is practical in the problem.

Huge codebases are necessarily going to be harder to process by humans (LoC -> hours in the day) and LLMs (LoC -> tokens/context growth) alike.

Or train (and appropriately credential) more teachers and pay them like the critical specialists they are.

If teacher pay made a big difference in outcomes, expensive private schools would have very well paid teachers. But private schools typically have lower teacher pay than public schools.

Say more?

Possible, yes, but certainly not easier—especially not if the test harness doesn’t manage filesystems anywhere else.

And even then, that’s still a behavior mock, of a kind. There are lots of ways in which a dummy ISO mount behaves much unlike filesystems your deployed code might run on. You could address those issues, but doing so is very laborious and starts requiring more and more specialized code. Unless the code under test is part of a database storage engine or something, it’s likely even less worth it.

I thought lots of data indicated that millennials were drinking less than previous generations?

Maybe, but that precedent has been set before for other types of loans, and in a limited way for student loans, and the sky didn’t fall. The upward price pressure on university prices is far more influenced by other factors (which should be fixed!). Loan forgiveness probably is a drop in the bucket, I suspect.

>Maybe, but that precedent has been set before for other types of loans.

what is this referring to?

Some of those already exist, e.g. https://bellard.org/tcc/

However, they're not in widespread use. I would be curious to learn if there's any data/non-anecdotal information as to why. Is it momentum/inertia of GCC/LLVM/MSVC? Are alternative compilers incomplete and can't actually compile a lot of practical programs (belying the "relatively simple program") claim? Or is the performance differential due to optimizations really so significant that ordinary programs like e.g. vim or libjpeg or VLC or whatnot have significant degradations when built on an alternative compiler?

True! But C++ is popular almost entirely because of when (in history/what alternatives existed at the time) and where (on what platforms) it first became available, and how much adoption momentum was created during that era.

I think claiming that C++ is successful because of the unintuitive-behavior-causing compiler behaviors/parts of the spec is an extraordinary claim--if that's what you mean, then I disagree. TFA discusses that many of the most pernicious UB-causing optimizations yield paltry performance gains.

If I may pontificate a bit, I was a major contributor to the success of C++.

Back in the 80s, I was looking for a way to enhance my C compiler. I looked at Objective-C and C++. There was a newsgroup for each, and each had about the same amount of traffic. I had to pick one.

Objective-C required a license to implement it. I asked AT&T if I needed a license to implement C++, and could I call it C++. AT&T's lawyer laughed and said feel free to do whatever you want.

So that decided it for me. At the time, C++ did not exist on the PC other than the awkward, nearly unusable cfront (which translated C++ to C). At the time, 90% of programming was done on the PC.

I implemented it. It was the first native C++ compiler for the PC. (It is arguable that it was the first native C++ compiler, depending on whether a gcc beta is considered a release.)

The usage of it exploded. The newsgroup traffic for C++ zoomed upwards, and Objective-C interest fell away. C++ built critical mass because of Zortech C++.

Borland dropped their plans for an OOP language and went for Turbo C++. Microsoft also had a secret OOP C language called C*, which was also abandoned in favor of implementing C++.

And the rest is history!

P.S. cfront on the PC was unusable because it was 1) incredibly slow and 2) did not support near/far pointers which was required for the mixed PC memory models.

P.P.S. Bjarne Stroustrup never mentioned any of this in his book "The Design and Evolution of C++".