That's not true. As with all game theory payouts, it's not saying that a Nash equilibrium is inevitable, it's saying that to avoid it you need incentives outside the game, it's saying that the incentives of the game itself don't suffice.
In terms of "the tragedy of the commons", that outside incentive is usually public shaming in smaller communities, or rules and laws in larger and more anonymous communities. If you look at shared resources across history and cultures, you usually find communities enforce very strong outside incentives against spoiling the commons instead of just relying on the kindness of strangers.
Under what circumstances a passenger needs to identity themselves differs significantly from state to state. Also, neither Brendlin v. CA or AR v. Johnson talk about identification requirements, so I'm not sure what you're thinking there. Maybe you're confusing it with exiting the car?
And before someone says "but the Supreme Court overrules the states", no it doesn't. Many state courts have found that their state constitutions grant their citizens more rights than the US Constitution in various circumstances.
I loved Connections so much as a kid, but I'm so tired of this clip. There's so many better clips from this show.
So he nailed a 13 second countdown. Who cares? Newscasters do this at every commercial break. Sports announcers do this without a script and they still nail the cut to commercial almost every time. Yes, there's a talent to timing your speech to a countdown in your ear, but it's a talent that people do thousands of times a day around the world on far less preparation than Burke had here.
The fact that this article calls a simple cut a "sleight of hand" just terrifies me. Does the public really not know what editing is?
If it gets someone to watch the show for the first time then that's a win in my book. I think every young student should be exposed to Connections at various stages of their education.
I absolutely adore both Burke and the Connections series, and without a doubt this is a lovely shot, but I feel the same: I don't get the hype. It's been memefied to death for no real reason. There's no incredible feat involved. It wasn't a tightrope walk without a net live on air. You can bet they had stand-in footage done before that they could have made a montage of in case Burke stumbled a line.
I suppose it's like a magic trick. It's less impressive once you understand how it all works. But still, it's clearly effective and you can admire the artistry.
It's very common the US as well, but primarily in education circles. I honestly have no idea what percent of the general public would recognize it immediately (hard to know for anything, really).
> My understanding was that it was the tenant rights movement that killed SROs and boarding houses by making it practically impossible to keep them orderly
It depends on the time frame you're talking about. Long-term SROs like boarding houses were absolutely affected in the 50s/70s by tenant rights laws. But they adapted. In the 70s/80s, SROs were still widespread in large cities except that they all had occupancy time limits (usually 60s days or so) to avoid tenancy laws. But people who relied on them could just move to a new one when the time limit came, so the market was still viable.
But then in the late 80s/early 90s they all got zoned away in the way this article talks about. It was really more NIMBY than reformer. Note that this time frame corresponds with the height of the US crime wave, and what was once a sketchy urban neighbor became the source of major neighborhood blight, especially as re-urbanization started up in the late 90s
In OP's defense, "becoming suspicious" doesn't mean it's always wrong. I would definitely suggest an explaining comment if someone is using DISTINCT in a multi-column query.
Snopes has this as mixed because Stalin may or may not have expressed this sentiment at some point, but it seems impossibly unlikely to me that this pun works in Russian as it does in English.
It's hard to talk in the abstract because obviously people can abuse any type of code feature, but I generally find chaining array methods, and equivalents like c# linq, much easier to read and understand than their looping equivalents.
The fact that you single out .reduce() here is really telling to me. .reduce() definitely has a learning curve to it, but once you're used to it the resulting code is generally much simpler and the immutability of it is much less error-prone. I personally expect JS devs to be on the far side of that learning curve, but there's always a debate about what it's reasonable to expect.
The wonderful thing about .reduce() is that it can compute literally anything. The problem with .reduce() is that it can compute literally anything. As for the rest of the morphism menagerie, I like being able to break up functions and pass intermediate results around. It's literally cut and paste with map/filter, with a loop it's rewriting. Yay composability.
That said, it's easy to get carried away, and some devs certainly do. I used to be one of those devs, but these days I sometimes just suck it up and use a local variable or two in a loop when the intent is perfectly clear and it's not leaking side effects outside of a narrow scope. But I'll be damned if I let anyone tell me to make imperative loops my only style or even my primary one.
Reduce cannot calculate literally anything, in the sense you mean. It corresponds in computational power with primitive recursion. And quite famously, there are problems primitive recursion cannot solve that general recursion can.
On the other hand, I don't think I've ever seen something as recursive as Ackermann's function in real life. So it can probably solve any problem you actually mean to solve.
Naw, GP is right, I'd forgotten about the limits of primitive recursion. But for almost any given real-world problem, it's something you can get away with forgetting.
Unfortunately, since we don't have continuations, we cannot make reduce _stop_ computing. In such cases where that is needed, it might be better to use a loop that can be broken out of.
Well, you can always throw an exception :) (ducks)
But yes, it's best used on sequences where you know you'll consume the whole thing, or at least when it's cheap enough to run through the rest with the accumulator unchanged.
> The fact that you single out .reduce() here is really telling to me. .reduce() definitely has a learning curve to it, but once you're used to it the resulting code is generally much simpler and the immutability of it is much less error-prone. I personally expect JS devs to be on the far side of that learning curve, but there's always a debate about what it's reasonable to expect.
Not only that, but the words that GP uses to single out .reduce() start with:
> I see so much convoluted code with arr.reduce() or many chained arr.map().filter().filter().map()
Which I do not doubt, but the point is diminished when one understands that a mapping of a filtering of a filtering of a mapping is itself a convoluted reduction. Just say that you prefer to read for-statements.
I say convoluted. I prefer using the functional-style array methods, but there's a time and place for everything, and I feel a lot of Javascript developers extend those methods beyond what is reasonable and into a convoluted mess, especially with reduce.
Give me a good classic `T[] => I` reduce function and I'm fine with it. Not the more common case of folks mutating the accumulator object.
> “nobody reads intermediate commit messages one by one on a PR”
I clean my history so that intermediate commits make sense. Nobody reads these messages in a pull request, but when I run git blame on a bug six months later I want the commit message to tell me something other than "stopping for lunch".
> pedantically apply DRY to every situation or forcing others to TDD basic app
Sure, pedantically doing or forcing anything is bad, but in my experience, copy-paste coding with long methods and a lack of good testing is a far more common problem.
You may be 100% correct in your particular case, but in general if senior devs are complaining that your code is sloppy and under-tested, maybe they aren't just being pedantic.
Good commits are not a requirement form bisect.
I commit when I think something more or less completed, or I want to start a major refactoring and I'm afraid I might need to revert it.
I don't always check if commits are buildable, PR should be, because that is what is merged to master and tip of master should be buildable.
If a commit isn't buildable then when you get to it with bisect you have to skip. If this happens once in awhile it's not fatal, but it's sure not helpful
I actually find the relevant PR/MR discussion a lot more useful than the commit messages themselves. So any git blame is just to get a commit hash and look that up in GitLab/GitHub to see the entire change set and any comments around it. It makes me wish those comments were bundled with the merge commit somehow and could easily be accessed in the terminal where I'm viewing the git history.
> Sure, pedantically doing or forcing anything is bad, but in my experience, copy-paste coding with long methods and a lack of good testing is a far more common problem.
This is a false dichotomy and an unproductive thing to focus at.
Experienced engineers know when to make an abstraction and to not. It is based in the knowledge about project.
Abstarct well and don't do compression. Easy said, and good engineers know how to do it.
In terms of "the tragedy of the commons", that outside incentive is usually public shaming in smaller communities, or rules and laws in larger and more anonymous communities. If you look at shared resources across history and cultures, you usually find communities enforce very strong outside incentives against spoiling the commons instead of just relying on the kindness of strangers.