Deprecation is just a tag. You don't have to respect it. And if you want the project to continue, you can freely fork it.

The bits are untyped, the choice of operation decides how the bits are interpreted. Nothing enforces the type of that result, you can always interpret it as something else. It may not be meaningful. Or it may be, like a fast inverse square root.

Strong typing means that each value has an intrinsic type, and there is no reinterpreting it. What CPUs do is not that, or rather the only types are "_n_-bits" (_n_ a power of 2).

"Safe strings" is an example of that idea. Not always possible or practical, but always worth considering if you're doing "validation" as a function.

Someone saying that a mirror swaps left and right is comparing it to a photograph, and only because we, as bipedal creatures, really prefer to orient images of other humans with heads up.

One half of one dimension less than a human. But sure looks convincing on the surface.

There are very strict rules for scientific experiments _because_ we know that without them, just guided by "common sense" or "be reasonable", someone would get blinded by ambition or "the potential" and go further than the majority want to accept.

Anyone can "experiment" without it being an accepted scientific experiment. But then they're personally responsible for any and all bad outcomes. If you follow the rules and get the experiment pre-approved, you'll likely be covered by your employer's insurance and free from criminal liability . That's a very good incentive.

Odd hours, sitting too much, inhaling too many exhaust fumes, having people yell at you if _they're_ late.

Sounds like a fairly hard job.

It's parsing that's hard , for example when it needs to match up braces, or start and end tags, even if either is easily matched by a RegExp.

And you still need to be careful if the source you're looking in has any way to escape text or have different meanings for the same text. In source code, you should recognize comments and strings (and RegExp literals) so you don't match inside those. In HTML, you should recognize CDATA sections, including script elements. If they contain `That's is, your 99.9% is probably too damn high.

But people write all kinds of crap manually. So far, the data people have been writing has tended to be denser around what people could agree on (there are many lies, but only one truth), so the model is more likely to go there.

If we start putting AI generated text into the training data, it's not clear what that means for the resulting model. It's already clear that some actors are trying to influence models by putting large amounts of content out there that agree with them.

Figuring out which content is safe to train from is the real problem for future model trainers.

- Simple robust syntax

> - One obvious way to do things

That always leads to more verbosity. Much syntactic sugar is a more specialized way to do a subset of a more general thing. Why have `a + b` when you could just write `a.add(b)`? Because it's easier to read. The general functionality needs to account for all cases, the specialized one can cut that down just the things that matter to a specific common use case.

- Static type checking

\Which one?\

That's a very, very deep can of worms. One could argue that of an LLM is generating the code, then the type system doesn't need to be understandable to humans, so throw in all the features you'd ever want and just have the LLM change the code if it's not valid. Unions of higher order generic functions, sure! Or one could argue that there should be minimal magic, because the LLM understands the language only by its source, so everything should be explicit. If the LLM can prove that something is sounds to the compiler, accept it. Give ways to give extra evidence of soundness, like declaring invariants and contacts.

- Purely functional encouraged, escape hatches for performance

"One obvious way to do things", except when you need two. Purely functional except when it matters.

Why doesn't performance always matter? (And how will an LLM know if it does?)

Being purely functional is nice for data, but not for data structures that are updated in place. If all you do is stream data from one DB query into another, then your mutable state is the database. Otherwise might as well accept that it's a multiparadigmatic language with both imperative, functional and OO features. Just like all the others.

- Inspect-able, testable, and reviewable in small pieces

Good modularity and abstraction. No global scope. Maybe something like dependency injection to decouple from dependencies? (That does not make code readable, though.)

- Something like formal predicates, preconditions, post-conditions, assertions, or effects typing

That! LLMs look at the source. The more explicit the source is, the less it has to infer from context or existing knowledge. If the LLM can create its own predicates, accepted by the static type/analysis system, to prove that it's code is sounds, that allows more flexibility than having to fit into any fixed type system. Do we want or need that flexibility? Maybe. Most LLM-generated code is directly inspired by existing idiomatic code in the same language. Some is translated from other languages, trying to match up idioms. Some is just blindly trying to make unit tests pass. We could end up with generated predicates tailored to specific unit tests, not the actual concept.

It's not "operator overloading" any more than two _different_ classes having a `length` property is "length overloading".

Using the term "operator overloading" to begin with is the error here.

The "ghost cut" is a two-step text move. A perfectly fine operation to have, _because_ it's not the same as a cut operation followed by a single paste operation.

Cut can be used without paste, and paste can be used more than once. They're combinable primitive operations. Sometimes what you want isn't that combination. Someones it is. But claiming that they're _broken_ ... is not a sign of someone who's able to see past their own needs and preferences.

I have no idea what "randoseru" means, or what kind of backpack it is. Looking it up, it seems to be a design that carries special meaning in Japan, and not really anywhere else. While other countries _may_ have similar designs, it's not something special to them.

Even if the emoji looked like a ranoseru backpack, it wouldn't mean anything to most people. If anything, the front pocket is more likely to be associated with a backpack used for school.

The things you don't own are because they require an online service to work. No matter what you do, short of removing the dependency, aka "cracking", it will only work as long as the online service allows it to work.

Any feature of.a consoles with OTA software updates are in that category. Even if you own the hardware, you don't _control_ the software.

The Danish Building code has requirements for retaining heat in the house, which is great in the cold winters, but devastating in the heart of modern summers. Combined with rules that practically require large south-facing windows to satisfy the total energy requirement limits, it gets very, very hot. And air conditioning subtracts significantly from your energy rating, making it almost impossible to include AC in a new building and satisfy the emission rating that any new building must satisfy.

The code allows only 25 hours a year where indoor temperature exceeds 28 degrees, but the validation of a building uses old temperature data, so on practice it's more hours of higher temperatures, and for houses that, even if you want to add AC later, wasnt designed for that.

Abs to add insult to injury, if you renovate an older building, you _can_ be required to bring it up to modern specs. That can be so expensive that it's cheaper to tear it down and build a new building. Because you can't do something half-good?

The building code _is_ a real problem, and changes ... well, haven't happened yet, so the buildings built today will be unlivable for as long as they stand in the new hotter summers.

The thing is, you never did _buy_ that Steam game. And you never bought the software on the TV, which you did buy the hardware of, you bought a software lease along with the hardware.

The latter case I can see something to do about - define the software and its functionality as an "essential component" of the hardware, and require companies to not break essential components of hardware they sell. They can stop offering online services, but the rest of the device should keep working.

For pure software leases, I don't see a good way to not have them be whatever the contract say they are, not without reclassifying them as something else than a copyrighted work. (But then "sellers" should be very clear what you're "buying".)

``` target[i++] = source1[j++] + source2[k++]; ``` That's idiomatic, it shows the intent to read and consume the value in a single expression. You can write it longer, but not more clearly.

It's only when you assign to the same variable multiple times, or read it after it was assigned, that it introduces ordering issues.

A single `i++` or `++i`/`i += 1` is safe and useful.