palmtree3000
It's a different "we". Rephrased:
since Houston's government is not solving the problem at hand in a good way, Waymo decided to solve it in a worse way
Now my sibling comment links to a paper where they say they can find heat differences in the body that are sufficient for their needs, so this is still a possibility! But it does mean you need to be somewhere with a heat gradient: the paper mentions just under the skin.
There are a lot of similarities! The type systems are similar, with some name changes (sum types -> enums, typeclasses -> traits). Pattern matching is basically the same. Haskell uses (lazy) lists mostly the same way rust uses iterators. Ownership is new, but imposes some of the same requirements that immutability does (no cycles without shenanigans[0]). Rust requires that values are aliasable XOR mutable: Haskell does too (they're always aliasable and never mutable).
Other features include the prominent arcs in this field. The powerful gravitational field of a galaxy cluster can bend the light rays from more distant galaxies behind it, just as a magnifying glass bends and warps images. Stars are also captured with prominent diffraction spikes, as they appear brighter at shorter wavelengths.
[0] https://webbtelescope.org/contents/news-releases/2022/news-2...
I think there are two reasons.
First, languages live or die by their ecosystems. If you love a language, it's very much in your interest for other people to use it, so they write code that you can use.
Second, most programming happens at work. Most people don't get to choose what programming language they write at work: they're locked into whatever choice somebody else made. The more popular your language is, the more likely that choice is to be made in your favor (or alternatively, the easier it'll be to find a job where that choice has been made in your favor). If I want to write Idris at work, well, tough luck.
Both of these are largely zero-sum, which makes things worse. It's not 100% zero-sum, in that if you manage to light a passion for <language> in somebody they might write code (in that language) that might not have been written at all. But mostly language evangelism won't change the total number of programming hours per year (or the number of available programming jobs), so all that's left is to fight over who gets how much.
So if you care a lot about which programming language you write, I don't think it's odd to come at it from combative angle: it's a fight! Some will lose and some will win, so you better try and be one of the winners.
I agree that a reference frame that has about the same velocity as the stuff you care about is in some sense privileged. But the fact that we haven't seen the merger happen yet means that it's outside our light cone, which means there exists a reference frame where the merger hasn't happened yet.
that is to say, t_{this_coversation} < t_{merger}, in that frame.
The Weird, Dangerous, Isolated Life of the Saturation Diver
I haven't found any implementations I'd consider good. The problem as I see it is that there are tree based algorithms like https://webspace.science.uu.nl/~swier004/publications/2019-i... and array based algorithms like, well, text diffing, but nothing good that does both. The tree based approach struggles because there's no obvious way to choose the "good" tree encoding of an array.
I've currently settled on flattening into an array, containing things like String(...) or ArrayStart, and using an array based diffing algorithm on those, but it seems like one could do better.
Re: implementation: make putting money into a bank account tax deductible and pulling money out taxable, then continue to use the existing income tax system. Any money you earn that you don't spend is a tax write-off, any money you spend that you didn't earn this year is something you have to pay more taxes on.