How does that contradict what you quoted? The claim is that if the Japanese had been able to conditionally surrender, with the condition of retaining their emperor, then they would have done so. You respond by pointing out that when the Japanese did eventually unconditionally surrendered, much of the government was still against that decision. That implies nothing about what their response would have been to a conditional surrender. It's just a non sequitur. If anything one would expect that there would have been less elements of the government resisting a conditional surrender and so the coup would have been more likely to be suppressed in that case.
I'm not an expert on this by any means, but from what I've read about the four-color theorem, essentially all of the insight in the proof came from human mathematicians. Mathematicians figured out an ingenious way to reduce to the problem to carrying out a a large number of tedious computations, and the computer was used only to carry out those computations and thereby complete the proof. This seems quite different from a computer coming up with a proof by itself.
One issue with trying to stand out is that you might stand out in a bad way, rather than a good way. I have a blog, and a Github profile, but I'm not sure if I want employers looking at them, since a lot of my writing is poor, and a lot of my code is bad. There's good stuff there as well, I think, but my model of employers is that they are more concerned about false positives than false negatives, they tend to see "red flags" as nullifying any positive traits, and so, when they're examining my public portfolio, the parts that are bad are going to stick out and become salient in their mind, moreso than the parts that are good.
I don't worry about this too much though because in my experience, no employer has ever looked at these things (even though I have usually made some mention of them on my CV). If they have they've never mentioned it at interview.
Isn't this a fairly simple way of doing this? That said, it is a bit non-obvious if you haven't seen it before.
select earliest_joiner.* from employees as earliest
left join employees as earlier on
earlier.role = earliest.role
and earlier.join_date < earliest.join_date
where earlier.id is null
order by earliest.join_date
It doesn't have any particular theme or anything, it's just a place to put infodumps on things I've been reading about. It only gets updated very sporadically these days.
> early Perl was missing little things like named function arguments
It's still missing those :)
(To be clear for people unfamiliar with Perl, it probably will never have them, because it doesn't need them. In Perl, all functions effectively have a single parameter of array type. The standard convention is to assign each array entry to a variable at the start of your function definition, and the names of those variables then effectively act as parameter names. But that's just a convention and you can do something else if you want.)
I know cygx already replied, but to be clear, function signatures have been available in Perl since 2015. They were added (as experimental) in 5.20, and are now enabled by default with `use v5.36` or later.
All new features must now go through an experimental phase after the smartmatch debacle. Signatures stayed in experimental status a little longer than most new features due to an unfortunate change with respect the order of function signatures and function prototypes. Provided you weren't using prototypes (which you almost never need) then they've been largely stable since 2015.
Most distro's under current support ship with at least Perl 5.24, so you can use them almost anywhere.
Could you explain your comment further? I don't understand it. Specifically, I don't understand what "has many Ys through Xs" means. That phrase just doesn't syntactically make sense to me. And then you talk about storing "user_id on both" as a denormalized solution---but what that makes me think of is having two independent one-to-many relations (user-to-X and user-to-Y), with a table for each, each having a user_id column linking back to the user---but that's perfectly well normalized as far as I know, so I assume you probably intend to convey something different.
If I understood it correctly, the GP is talking about those normalized tables:
U | X
X | Y
and claiming that if you need the relations of U | Y often, you are better storing them as:
U | X
U | X | Y
Or just the later table, since the first is now completely redundant.
So yes, that happens, and depending on the size of those tables, it may be true that the denormalized for is faster. But it's just wrong to claim that one or the other is faster without any further information, and IMO, the more common case is that the normalized one is faster.
I've tried changing the settings, but it's confusing. Am I trying to stop my laptop from "locking", "sleeping" or "hibernating"? It's not clear to me which thing it's doing. Maybe it's doing one thing some of the time, and the other thing the rest of the time. And even now that I think I've set it to do none of these things, the screen still disappears and I have to re-enter my password within 5 minutes. So either the settings don't work, or the UI is too confusing for me to figure out what's the right thing to do. Either way, putting a YouTube video on is much easier.
It's entirely possible for a distinction that contrasts a large majority with a small minority, or even an actually-existing totality with a hypothetical set of counterexamples, to be meaningful.
