reichstein

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.

Probably don't care.

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.

https://www.build.aau.dk/report-from-aau-warns-danish-homes-...

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".)

Just because it's my windmill to tilt at: `[\s\S]` can be written shorter and more precisely as `[^]`.

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.

... thus falling into the Pitt of failure, where every way out is just a little too far away.

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.

Your irony detector may need calibration.

Or mine does.

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.

Agree, other than that I wouldn't use "2-arity". Maybe "2-ary", but that's just "binary" written confusingly. It works for "n-ary".

I'd rather say that a binary operator _has_ an arity of 2 or talk about the arity _of_ an operator.

"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.

That's not how it works.

Maybe if I'm given two colors inside that range, I can say which is bluer and which is greener. Given just one color, I simply cannot say that it's green or blue, or even if it's more green than blue or vice versa.

I stopped at the 3rd or 4th come because I couldn't give a honest answer. That makes the test useless. I can't complete it with correct answers, and if I give incorrect answers, the conclusion is useless.

The word "development" can mean several things. I don't think "software development" sounds bad when grouped with a phrase like "urban development". It describes growing and tuning software for, well, working better, solving more needs, and with fewer failure modes.

I do agree that a "coder" creates code, and a programmer creates programs. I expect more of a complete program than of a bunch of code. If a text says "coder", it does set an expectation about the professionalism of the text. And I expect even more from a software solution created by a software engineer. At least a specification!

Still, I, a professional software engineer and programmer, also write "code" for throwaway scripts, or just for myself, or that never gets completed. Or for fun. I will read articles by and for coders too.

The word is a signal. It's neither good nor bad, but If that's not the signal the author wants to send, they should work on their communication.

And I got it. When the algorithm sees a word that is already in the list, it discards the word in the list first. Then it adds the word again with the same probability as any other word. This ensures that only the last occurrence of each word can occur in the final list, so the final occurrence of each word are all in the final list with the same probability, and prior occurrences are always removed, if no earlier then when the next occurrence is seen.

If the input is known to be large, there is no reason to start by adding every element. It can treat the first round like any other, and start out with a _p0_ that is smaller than 1.

The way I'd describe it is:

- You have a buffer. You initially try to fit every unique word on there. - If the buffer gets full, you know that you can't fit all the unique words in there. So you decide to keep only a fraction, _p1_, of them. Run through the buffer, keep each value with probability _p1_. - Keep adding new words, again only with probability _p1_. - If the buffer gets full again, _p1_ was too large, so you choose a lower fraction, _p2_, retain existing elements only with probability _p2_/_p1_, and continue adding new words with probability _p2_. - Every time the buffer gets full, you lower the faction of words you try to retain.

The choice of using _pn_ = (1/2)^n is just easy for a computer, it only needs entire random bits at each step.

What I _don't_ get is how this is correct for counting unique words. If I have a text of 16384 unique words, then I can accept that each will be in the final list with the same probability. But if I take that list and repeat the last word 30000 times, then it becomes overwhelmingly plausible that that word is in the final list, even though I haven't changed the number of unique words. Maybe there is some statistical property that evens things out, but I couldn't see it from the article.

NAND gates are enough to computer any boolean function. Being Turing complete requires some notion of state and state transition.

However, a RAM machine where the program counter is memory mapped, can be Turing complete with a [single machine instruction]( https://en.m.wikipedia.org/wiki/One-instruction_set_computer).

Pretty much. _Language_ is how we propagate meaning.

Words are units of language, that can be used to build larger composite language constructs. (And words, _when written_, are themselves built from smaller syntactic units, letters, at least in non-idiographic writing. But words exist independent of writing, writing is just one way to represent words and language.)

And as with everything human, context is important. The same word can have different uses, and the receiver depends on context to determine which meaning the word should carry. That context can come from the grammar (is it a noun or a verb?), pronunciation (it's really a different word then, it just happens to be spelled the same), and general social context (where are we, and what are we talking about?)

It's all pragmatic. It's what we have made to work. Building larger things from smaller things is how we've made language scale to thousands of words, millions of books, which can all still be read my most people. (And maybe understood.)

The article seems to be about a discussion that is really about proper names. That's a more philosophical discussion because it touches on "identity", what it means to be "the same".

But even names are usually just context dependent designators for an entity that all the participants already (are expected to) agree on what is. That's why using a name is enough to designate it.

Language isn't deep. If it was, it wouldn't work. Anything that two people can agree on, can be used to transfer meaning.

When you read the post, it does sound slightly deranged, but if you check the links, they're not actually as bad as they sound.

If everybody agrees, you won't get the kind of conflict about company choices that this is about, so obviously there is a disagreement. But that disagreement doesn't have to be between "leadership" and "employees". It doesn't have to be a culture war, or about "SJW"s. It may really just be about _how far_ you can go in your advocacy in the workplace.

It's quite possible that there are still lots of internal discussions about Google's engagement with various governments. But there are limits to how you can express your displeasure, and there should be. You can be too antagonistic, too aggressive, to the point where you _do_ appear threatening or disparaging to your coworkers, and that is not ok.

In the end, it is a place of work, and every other _worker_ should be able to feel safe. Because they have to be there too. That's the line that you shouldn't cross when advocating or demonstrating in the workplace.

Whether you're political or vegan, don't call your coworkers names for disagreeing with you. Any words you sling in your protest, assume that some of your coworkers will be hit by them. Even if you think anyone believing what they believe must be "bad people", you were the one to break the truce and start a conflict in the workplace if you say, fx, "all meat eaters are morally bankrupt".

You have to work with those people again afterwards. And they have to work with you. And maybe they no longer want to.

GC is usually not specified to happen at particular times, or saying which values are definitely going to be GCed. Instead it relies on the language semantics, so that any value which is used later in the program, is not going to be GCed. How and when the runtime system determines that a value is not going to be used again is an optimization problem, not a correctness problem.

So everything you quote Lua a saying here is consistent. The thing is that it only considers "used later" as "used later by the Lua program". Or rather, it only considers Lua values as "values". A value stored in non-managed memory is not a value. It's not GCed. The `ffi.new`-created Lua value is, and it's finalizer happens to free the native memory that the pointer refers to.

So non -Lua "values" are not GCed, they are freed as side effects of Lua values being GCed.

Not guessing at what the original author intended, but the formula `floor(x + 0.5)` does not currently round to the nearest integer for all floating point values. If 0.5 is just outside the bits of the mantissa, there will be an intermediate rounding before doing the `floor`.

One such value is 0.49999999999999994, another is 4503599627370497.0

I got a 100% agreement with majority too. I did not try to define anything formally, instead I judged each case by itself, asking whether I'd consider that thing a "vehicle". Which ended up meaning "car" in practice.

You only go mad if you try to lawyer things. Or your opponent does, which means that this test lacks the thing that really makes rules-making hard: determined opposition, would to trust your every word.