Hyperbolic title is, unsurprisingly, misleading. At least the article follows the style consistently.
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 distinction is not physical vs (entirely) digital.
If you buy games at GOG, you get entirely non-physical products, but you own and control those bits. You can download the game and keep playing it as long as you can provide it with a suitable runtime environment
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.
It's not that I don't agree, but lawyers will then ask you to define "buy" in such a way that it is distinguishable from a perpetual lease with a cancellation clause _to buyers_, without also disallowing a lot of actually useful leasing agreements.
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".)
Assigning to multiple variables in a single expression is fine and useful. Take
```
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.
The value of the variable is not hoisted by the Java compiler. (It's not that JVM, that only executes the byte code, what y doesn't have that kind of ambiguities.)
The semantics of Java is not undefined on multiple assignments to the same variable in an expression, so it can't hoist something if it would change the outcome.
Now, I don't actually know what the outcome is, because I don't remember whether `a += e` reads the value of `a` before or after evaluating `e`. The code is still confusing and unreadable to humans, so you shouldn't write it, but the compiler behavior is not undefined.
And if your variable is accessed from multiple threads, it may be undefined which intermediate values night be seen.
Semantic major/minor version 0.15 means it's still in development. It's not supposed to be stable.
Going from 0.14 to 0.15 allows breaking changes.
Try making a similar change between version 5.0 and 6.0, with hundreds of thousands of existing users, programs, packages and frameworks that all have to be updated. (Yes, also the users who have to learn the new thing.)
So "cooperative multitasking is not preemptive multitasking".
The typical use of the word "asynchronous" means that the _language is single-threaded_ with cooperative multitasking (yield points) and event based, and external computations may run concurrently, instead of blocking, and will report result(s) as events.
There is no point in having asynchrony in a multithreaded or concurrent execution model, you can use blocking I/O and still have progress in the program while that one execution thread is blocked.
Then you don't need the yield points to be explicit.
Aks. "Every beef anyone has ever had with Nvidia in one outrage friendly article."
If you want to hate on Nvidia, there'll be something for you in there.
An entire section on 12vhpwr connectors, with no mention of 12V-2x6.
A lot of "OMG Monopoly" and "why won't people buy AMD" without considering that maybe ... AMD cards are not considered by the general public to be as good _where it counts_. (Like benefit per Watt, aka heat.)
Maybe it's all perception, but then AMD should work on that perception. If you want the cooler CPU/GPU, perception is that that's Intel/Nvidia. That's reason enough for me, and many others.
Availability isn't great, I'll admit that, if you don't want to settle for a 5060.
JSON is a text format. A parser must recognize the text `2` as a valid production of the JSON number grammar.
Converting that text to _any_ kind of numerical value is outside the scope of the specification.
(At least the JSON.org specification, the RFC tries to say more.)
As a textural format, when you use it for data interchange between different platforms, you should ensure that the endpoints agree on the _interpretation_, otherwise they won't see the same data.
Again outside of the scope of the JSON specification.
The JSON spec only defines the JSON text format. It doesn't say what the text means. There are obvious interpretations, but every program that reads or writes JSON can decide what it does with it.
On the other hand, the thing that makes JSON actually useful is the interoperability, that JSON written by one program, on one platform, can be read by another preterm on another platform.
Those programs have to agree on a protocol, what the JSON text must satisfy and what it means.
It's usually not considered valuable to require object properties to be in a specific order, so they don't. But they could.
So you're saying that "an ask" is "an order" or "a demand", rather than "a request".
Why not use those words?
I don't understand what "an ask" means.
I don't know what the speaker intended with it, and I wouldn't know how a receiver would understand it.
It's just communicating badly, using words with no fixed shared meaning.
Or somebody too afraid to be confrontational to phrase a demand as actually demanded.
And "learnings" is just somebody too lazy to say "lessons learned".
I'm personally convinced that the reason the conditional operator of called "the ternary operator" it's that the ANSI C Programming Language book contains the phrase "the ternary operator, ?:", and a lot of readers didn't know what "ternary" meant and thought it was a name.
"Success" is to achieve the intended goal, without causing new problems that outweigh the benefit of reaching that goal.
Reaching the goal is not a moral measurement, it is all about efficiency. If you don't reach the goal, your efficiency is zero.
The moral question is what new problems are acceptable. That's where reasonable people can disagree.
Many quick-sort implementations are deterministic, so will consistently have their worst case behavior on the same inputs again and again.
The good ones try to do a little better than choosing the center element as pivot, but with a well crafted input, it can easily become polynomial anyway.
Luckily sorting is something you can easily choose another implementation of, if the default over didn't fit your use-cade, unlike the GC built into the single language implementation that your customer uses.
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.