With my car, trying to lock the doors just doesn't work if one is left open — not always the most obvious failure mode, but it's been enough to get me to notice something's wrong.
> With my car, trying to lock the doors just doesn't work if one is left open
for suburban single family residence dwellers with their own garage, they may not always (or ever) lock the doors while the car is parked in their locked garage.
No car I'm aware of requires this. If the ignition is off and the doors are all closed, the car is, for all intents and purposes, asleep. If anything, doors unlocked may be lower power... as that would disable (or, rather, not enable) alarm functionality.
For me, at least, there's an important difference missing from the debate over the term "C/C++": compiling C code is always much faster than you would expect, but compiling C++ code is always much slower than you would expect...
And yet there's an ongoing effort to optimize the kernel compile time by rearranging all of the headers. On a modern machine with plenty of cores a kernel build is pretty quick, but they're talking about slicing 20% or more off the top.
Pixel phones can take "Motion Photos" — it seems like this is basically just an mp4 file stuffed into a jpg somehow (but without sound). The Google Photos app lets you export it as an mp4 or gif file, or pick a specific timestamp to export a still image.
It looks like the Samsung Camera has something similar, but I'm not sure if it's compatible...
Conversely, I think the beauty is that they _are_ the same as top-level functions, just in a special namespace. This means that you can call "instance methods" directly from a class, i.e. the following are equivalent:
(1) + 2
(1).__add__(2)
int.__add__(1, 2)
This comports with the "explicit is better than implicit" policy in Python. The only "magic" part is when dot-notation is used to call an instance method, which is just syntactic sugar. Another example of this philosophy is that operator overloading is simply reduced to implementing a method with a specific name.
I think a "magic" this keyword can create a lot of nasty edge cases that can be difficult to reason about; the way "this" is used in JavaScript is notoriously complex in ways that it might not be in a statically typed language like C++. What should "this" evaluate to outside of an instance method? What about in a class definition inside an instance method? What if an instance method is called directly instead of on an instance? All of these situations require making their own "rules", whereas in Python the correct answers can be easily reasoned about by starting from first principles.
> And Sundar has needed to go for a long time... How do you turn the largest consumer and commercial OS into a dumpster fire of exploits, half-finished ideas (Settings vs. Control Panel, anyone?!?)...
I always found this an interesting phenomenon. I hate being "wrong" as much as anyone else. But it seems like the best way to not be wrong is being aware of the uncertainties in your understanding, not making claims about topics where you have gaps in your knowledge, and adjusting your understanding based on new information. To have absolute confidence in what you are saying without regard for reality seems like the easiest way to be wrong...
I imagine it's possible, but "no reason" is definitely a stretch. The parts of DC that are federal land are hardly contiguous, and trying to force a clean split between DC and Maryland looks like it would be a nightmare: https://www.washingtonpost.com/graphics/local/dc-marijuana-m...
you wouldn't have to be perfect. You could carve out just the contiguous core. I believe this was floated by Jeff Flake. Federal buildings can, in general, exist on state land.
On a related note, the finance-related apps on my phone all offer me the option to sign in with a fingerprint sensor. Arguably you have two forms of authentication there: the presence of the physical device itself (using the secure element or whatever it is), as well as the biometric identifier (fingerprint scanner).
Neither of those are present when logging into your bank from its website, and I would also suspect that jailbreaking a phone significantly reduces the trust you can have in either.
Also, from a bank's perspective, all they care about is reducing their liability, without inconveniencing too many customers. In that context, it makes a lot of sense for banks to disallow their products from being used on jailbroken phones.
