Again, I'm not criticizing that person specifically. They repeated a word that appears in all the articles.
There are two points I was trying to make: 1. At the relevant time, there were no separate Eastern and Western empires, so this city was just Roman, without qualification. 2. Even later, it could just be called Eastern Roman. Calling it Byzantine instead may be a conscious choice to make the Roman-ness disappear. Again, I'm speaking about the general use of the term in all the articles, not by the OP.
Anyway. Even the person in this thread arguing most vehemently for the use of the term Byzantine says it applies to the "latter eastern Roman empire". So it shouldn't be used for this city, since it's neither form the Eastern empire (which, again, did not exist yet) and especially not from its latter period.
"Constantine split the empire" is just incorrect. There were co-emperors with regional responsibilities both before and after him. They were co-emperors of one empire. If you want a firm split, 395 (death of Theodosius) is the more common date AFAIK.
I'm not denying that gradually, over well more than a thousand years, the empire (only surviving in the East) changed character in many ways. I am denying that a unique Eastern character sprang up (and immediately applied to Egypt) the moment that Constantinople was founded.
One of the articles mentioned inscriptions in Coptic, Latin, and Greek. The elites would have spoken both Greek and Latin, I think? Greek was commonly known and used. Caesar, a Very Latin Roman, as he was being murdered in Rome, is conjectured to have spoken Greek to Brutus, another Very Latin Roman.
The notion that people are mostly monolingual, and that language is very closely tied to a cultural identity, is a modern projection (and far from universally true nowadays as well).
Not singling you out, all the articles do it, but: Strange to call this Byzantine. The coins found are from the reign of Constantius II, who at times ruled the whole empire alone (as did his successor Julian). The idea that the East, even when administered separately, was some foreign/"Byzantine"/not-really-Roman "other" was invented much later.
It seems pretty clear that they do only minimal live testing during the "open a ticket, implement something, deploy it in production, all while the customer is still on the call" cycles. So your second concern is probably not relevant in this particular setting.
Regarding the first, I think you're probably right, but then again, if there is a 15-minute base cost, it's hard to amortize that through fewer incremental runs of the compiler.
(Which isn't to say that I think they are doing the right thing.)
My thought reading this article was: Why write the system in any one language at all? And I don't just mean having some parts in one language and others in another language, I mean redundant implementations of the same parts. You can use an AI to rewrite parts of the system, and then throw away the old part... or you could just keep the old part.
That is: Have a Haskell base system. Have a Python "development" version on which you iterate at lightning speed. But also, in the background, moving at whatever pace it takes, have an agent running that imports all the Python development changes into the Haskell version. Have nightly builds of the Haskell version to reap its benefits (issues caught by the type system, more efficient native code). They must have continuous or nightly processes to fix bugs in the Python code anyway, there is no way that all the things they ship "while still on the call with the customer" are always tested on the full test suite and always 100% correct.
And it doesn't have to be Python/Haskell of course. The "development" version could be a (hypothetical?) interpreted Haskell. I have no idea if ghci would be useful for this. Neither do I know if the 15-minute Haskell build time is spent in the frontend (so an interpreter would have to pay that cost too) or in code generation or linking (which the interpreter wouldn't need to care about). Anyway, these are things I would think about before I did what the OP did.
How do you break a regression? A regression is breakage. Are you one of the people who use "regression" to mean "regression test"? Did Codex learn this from you? I hate it.
Define "exists". Are you questioning whether a human typed those characters with human fingers on a keyboard? Or are you questioning whether Alec Scollon is the name on that human's government-issued ID? It's not exactly new or unusual for people to use pseudonyms.
You:
>>> You want comprehensive tests at every level, far more than is reasonable for a human to build or maintain
Also you:
> You have to iterate on the tests, review and validate them
Yes, "maintain" is not quite the same as "review", but the line is veeery fine. I find it really tiring to review masses of tests that an agent spews out.
Especially because I know what it has a tendency to write irrelevant/vacuous/useless tests. It's insane the amount of times I have told Codex to "write a test that reproduces the reported bug, SEE THE TEST FAIL, then implement a fix", only for it to guess an irrelevant test, not run it to see it fail, and implement a code change that has nothing to do with either the test or the actual bug.
I found Codex to use "gate" in a different sense: As the condition of an if statement. I have a local style rule not to use that. Another really grating thing is to use "X-shaped" for "something vaguely related to X". And using temporal words like "still" and "already" in contexts with no temporal connotation.
I wonder how long this will still be a thing. More and more companies seem to come to the conclusion that tokenmaxxing is just too expensive for the value it delivers. Will there be others that continue doing it? Will there be companies that advertise "unlimited tokens" as part of job listings? How will they react when employees test the limits of "unlimited" (whether by accident or not)?
I would expect Postgres to be heavily tested with things like Valgrind and various sanitizers. I'd be surprised if there were low-hanging fruit. But also, if there is code that does something fishy with pointers, wouldn't the AI likely paper over it by adding an unsafe block in the Rust version, preserving the same fishiness? It's hard to know how hard it would try to prove that the original is broken.
I know how to write a test that verifies other tests. But I can do that already, I'm wondering what Beagle would add.
I also know that if the meta-test is writable to the agent, it will change it if it feels like it wants to get rid of some other test. Even if it can't change the meta-test, it can hollow out existing tests to make them pass trivially.
I don't think nondeterminism is the problem. The problem is following rules: If I tell the agent not to change tests, it can conveniently "forget" about this. It doesn't much matter if it forgets deterministically. The problem is that it can forget at all.
Thinking about this more, like every blockchain, this only makes sense if there is an incentive to publish each log entry as quickly as possible. Once it's published, of course it's tamper-proof, including against "the operator of a recorder can delete the bad day". Presumably the incentive to publish and the protection against the operator choosing to "never write a record at all" is the same: You must get paid for publishing a log entry. Because a log entry is, quite literally, "proof of work".
But if you're incentivized to publish as quickly as possible, then your customer gets the log immediately, and there is no need for a "trusted" third party to act as a "witness" and seek rents for not doing anything useful.
And none of the above protects against the vendor using your sensitive data to (a) do the work as contracted, with a cryptographically verified log and everything, but also (b) copy/analyze/abuse said data without telling you.
It's 2017 again, and someone on HN is inventing "blockchain for X", poorly. (Also note that it doesn't matter what kind of work X is, except for aligning this with HN's current main interest.)
There are two points I was trying to make: 1. At the relevant time, there were no separate Eastern and Western empires, so this city was just Roman, without qualification. 2. Even later, it could just be called Eastern Roman. Calling it Byzantine instead may be a conscious choice to make the Roman-ness disappear. Again, I'm speaking about the general use of the term in all the articles, not by the OP.
Anyway. Even the person in this thread arguing most vehemently for the use of the term Byzantine says it applies to the "latter eastern Roman empire". So it shouldn't be used for this city, since it's neither form the Eastern empire (which, again, did not exist yet) and especially not from its latter period.