I'm not sure if you do, honestly. The point of the exercise is exactly the ambiguity that stood out to you.
Also, the question was very explicitly not asking if an ambulance in the park is "okay." The question is asking is it a rule violation.
It's an excellent analogy, in my opinion, because what it's trying to be analogous to is the general ambiguity of language that makes content moderation difficult. It's hardly even an analogy because it is about precisely an identical concept: determining whether behavior is violating a rule.
You and antihero are talking about two different kinds of "good listening," though.
"Being a good listener" has both a practical and a social component. You are referring to the social component ("in Japanese culture..."). The tenets of social interactions in Japanese culture which have been ingrained in speakers of the language to one extent or another. The performance aspect of the act of listening.
antihero is talking about the practical form of "good listening" when they say "that makes you a terrible listener though." That is, what is the function of "listening" in a social interaction? I would hazard a guess that they believe the function of listening is to understand what another person is saying.
And by that benchmark, an individual who is not actually reaching any sort of understanding is a "bad listener" irrespective of how successful they are at performing the cultural/social component of the act of listening.
There's the additional implication that because signaling you are understanding when you are not leads to misunderstanding (which is the antithesis of the intended function of listening), it makes the listener an even worse quality listener than if they were not performing.
OP was not suggesting that search engines cannot be used as a tool in the process of taking the test. Rather, that your test should not be something which a candidate can Google a pre-existing solution to and submit as their own.
While I agree with both sentiments, I find the juxtaposition between the two interesting as it implies a relationship between them but they don't seem to be related at all.
>...he should seriously consider putting more effort into the documentation and distribution side.
In addition to what other people have said, Blow is explicitly working on documentation over time and closed beta users have access to a fair number of documents detailing both language features and the philosophy behind the language.
One huge reason why the language IS still in closed beta is because Blow believes heavily in not releasing half-assed work. Documentation is a part of that.
"This version of the sentiment which you did not express is totally reasonable, therefore it seems nuts to hate people for the sentiment that you DID express."
I would imagine it's because WSL is a terribly confusing name itself for a lot of people.
There are two ways to read "Windows Subsystem for Linux":
1. This is a subsystem that runs on Windows that enables Linux binaries.
2. This is a subsystem that runs on Linux that enables Windows binaries.
The confusion comes in the fact that when I write those two sentences, I naturally want to write "This is a subsystem FOR Windows..." or "This is a subsystem FOR Linux... ." I had to consciously avoid using "for" in that sentence to highlight the problem.
So when someone who doesn't know what the thing does reads "Windows Subsystem for Linux" they may walk away with the false impression that the subsystem allows Windows binaries to run on Linux. Likewise, what you're seeing now is that people are seeing "DOS Subsystem for Linux" and thinking that this enables you run DOS on Linux.
It seems like a lot of the discussion surrounding DOD that gets popular interest is centered on a small set of patterns that you can apply. And the implication that DOD is the application of these patterns usually follows.
Taking this article as an example, it frames DOD as an optimization technique and explicitly states that these patterns are the main concepts of DOD.
But while these patterns are interesting and often show up in data-oriented designs, they are not themselves foundational to data-oriented design.
This is interesting to me because it seems to obviously be missing something. If the article went through a list of the design patterns present in the GOF book and framed them as the main concepts of OOP, I would imagine people would be a little bit suspect, right?
That's because it's kind of the reverse, isn't it? The main concepts of OOP may result in certain common PATTERNS of code structure and layout -- which have usually been given names like "Strategy" and "Visitor" and "Singleton" -- but those patterns are not themselves the main concepts of OOP.
Likewise, data-oriented design might lead you to convert an array-of-structures into a structure-of-arrays or avoid branching on a hot path but those patterns are not themselves DOD.
Also, the question was very explicitly not asking if an ambulance in the park is "okay." The question is asking is it a rule violation.
It's an excellent analogy, in my opinion, because what it's trying to be analogous to is the general ambiguity of language that makes content moderation difficult. It's hardly even an analogy because it is about precisely an identical concept: determining whether behavior is violating a rule.