Then you will be glad to learn that it is absolutely impossible for any language to cause physical harm as a direct result. In your prior example of "inciting violence", the language wasn't the cause of the harm, the violence was the cause of the harm; and the cause of the violence was the listener's choice, not the speech, or the speaker.

The freedom of speech naturally extends to all speech. Your freedom of speech is respected if and only if you can say whatever you want to say without any change in your legal status. Social consequences are, of course, another matter entirely.

forEach(iterator, function):
..if (!iterator.at_end()):
....function(iterator.get())
....forEach(iterator.next(), function)

A better question would be: How do you implement a loop construct without recursion?

Keep in mind that recursion is nothing more or less than the ability to return to a previous point in the control flow of a program. The stack overhead associated with a lack of tail-call optimization and the special treatment of iterative constructs are merely implementation details, whereas recursion is a fundamental concept in computer science without which most programs would be impossible to express.

I realize you were joking, but there isn't really anything conceptually difficult about recursion. It just means that part of the program refers back to itself. Whenever you have self-similarity in the program's control flow, including the trivial case of repetition, you have recursion.

I think part of the problem is that most students are introduced to specialized loop keywords and "the" stack (a mere implementation detail) first, and only exposed to explicit recursion later as an "advanced" concept. Recursion should come first. Really, which is easier to understand:

void iterative(int n) {
..while (n > 0) {
....print(n);
....n = n - 1;
..}
}

void recursive(int n) {
..if (n > 0) {
....print(n);
....recursive(n - 1);
..}
}

From a modern compiler's point of view (with support for tail-call optimization) these examples are exactly equivalent, but the recursive version doesn't require an understanding of mutation, which is counter-intuitive for many beginners, and makes the control flow explicit where the "while" statement hides the control flow behind a special keyword.

Under the system I described, the insurance company can provide any level of access required. Even a full database dump, if necessary—just make sure it's locked down so that such requests can only come the agency needing access. If they want to use their own transfer protocol, arrange for a hardened proxy server and do whatever protocol translation you need at that point. If your database gets hacked through an insecure interface demanded by some external agency, there will be a log entry recording that proxy as the source and everyone will know who is to blame.

That isn't really true. A well-designed system (they do exist) would leave the decryption to a dedicated security module, separate from where the data is stored. To gain access to the data you first establish a secure connection to the data store, authenticate yourself, and retrieve the encrypted data. You then connect to the security module, re-authenticate, and present the encrypted data along with a (crypographically signed) request for decryption. The security module logs and validates the request, decrypts the data, and sends the plaintext back to the client through the encrypted connection. At no point does any system other than the security module and the client's computer have access to the plaintext, and the rules for validating requests can be as strict as you like.

The security module is an obvious target for attack, but it's also a single-purpose system on which you can focus all your security-hardening efforts.

What logical basis do you propose for this exception? Unvaccinated is unvaccinated. Those who were not vaccinated for perfectly good medical reasons are exactly as much a threat to you and your kids as those who were not vaccinated due to philosophical objections or any other reason.

When it comes down to it, your willingness to tolerate this exception shows that your intent is merely to punish people for not helping out with your vaccination program, not to protect yourself against any reasonable threat of infection.

Typhoid Mary is a particularly poor example here because she was well aware that she was contagious, having been informed of that fact on several occasions, and yet repeatedly placed herself in an ideal position to pass the disease on to others. That isn't negligence, it's deliberate harm.

As for the rare cases where one can be asymptomatic and yet contagious, that's a risk you'll just have to take. It's not like vaccination eliminates that risk; even ignoring the fact that it isn't 100% effective, those who are immune can still be carriers. The most effective response in this case is to practice basic sanitation measures and limit direct contact, regardless of vaccination status.

Nonsense. Putting aside the slip into ambiguous collectivist language ("society" does nothing; only individuals are capable of making choices and taking action), it is reasonable for you to exercise your freedom and refrain from contact with the unvaccinated, if that is your choice. Your fears do not justify restricting the freedom of others.

Sure, and there's nothing wrong with that. The ability to trust in others on the basis of common experiences and values is a good thing, when it isn't being abused as an excuse for aggression. But don't trust blindly; it's up to you to take steps to ensure that the other parents you associate with are in agreement with you regarding what is reasonable and necessary for the protection of all your children. And if it happens that such agreement is lacking, to find a voluntary response to the situation rather than resorting to violence and threats.

As I said before, I am not opposed to vaccination per se. It's a great invention and most people should choose to be vaccinated and to vaccinate their children unless they have a good medical reason not to. All I'm saying is that people should not be forced to undergo a medical procedure against their will (or against their parents' will, in the case of children), and that the choice to avoid vaccination is not, in and of itself, an act of violence against others—negligent or otherwise.

In the end, you want everyone else to be vaccinated so that you (and your kids) do not run the risk of accidentally contracting a disease against your will, which you consider harmful. To that end, you're willing to deliberately force others to undergo a medical procedure against their will, which they consider harmful. The hypocrisy in this position should be self-evident.

No, it can't. Refusal to vaccinate yourself or your kids does not, by itself, cause harm to anyone else. If any harm does occur later on, it will be due to interacting with others while infected and contagious. Provided that the proper steps are taken, it is perfectly possible for the unvaccinated to avoid becoming infected, and even if infected, to avoid passing the disease on to others during the contagious period. Vaccination is certainly more convenient, but it is hardly the only way to avoid passing on diseases short of total isolation.

"Negligence" is a tenuous argument at the best of times; to apply it here, you would need to show that the individual had reason to believe that he or she (or his/her child) was actually contagious and chose to interact with others anyway without taking effective precautions to prevent the spread of the disease.

I favor vaccination, but I also feel very strongly that people have the right to decline any medical procedure they do not wish to undergo, vaccination included.

What libertarians generally believe, as a direct consequence of the Non-Aggression Principle, is that the owner of the road decides the terms for the use of his or her private property. Either a space is privately owned by someone, who has the right to determine who can enter it and how it can be used, or else it is unowned and thus available for anyone to homestead. There are no "public spaces", and no one has the authority to enact a "public-health measure" restricting the use of others' property.

There's a simple solution for that: give both sides a fixed amount of time (several days) to enter a review. Reviews remain hidden until the time limit has passed.

The site should allow reviews to be edited until the time limit expires, rather than locking in reviews once both sides have submitted, to as a safeguard against coercion. Otherwise one party could force the other to enter a positive review while they watch, then lock it in by submitting their own review.

I'm not really sure how creating yet another way for a "designated program" to monitor input events is supposed to address the problem that any X11 client can monitor keyboard events on any window in the absence of a grab, unless you intend to rewrite all existing software to grab the keyboard on receiving input focus, and force all the desktop environments to implement support for the extension and move their global keybindings into a specially designated client. At that point you might was well switch to a system designed for secure I/O from day one—like Wayland.

It's no different with a rootless X server on Windows. Input received by any X window can be observed by any X client, unless one client grabs the input. XWayland will probably work the same way, with native Wayland clients secure from each other and from X11 clients but no isolation between X11 clients and no support for grabbing input directed at non-X11 windows. XWayland is meant as a shim between the Wayland compositor and ordinary X clients; it doesn't support external window managers and isn't expected to host a full X11 desktop environment. You wouldn't run something like a screen locker as an X11 client under XWayland. It wouldn't be secure, for the same reasons that screen lockers aren't secure under X11 now, and similar compatibility problems would occur if you tried to implement the Wayland input model with X11 extensions.

It's easy to implement the insecure X11 model on top of a secure system. The reverse is much more difficult.

Some other window most likely does have the keyboard focus, but that's not the same as grabbing the keyboard. Having the focus doesn't prevent input events from also being delivered to other windows, it just tells the non-focused windows to ignore the events. Integrity and privacy for both input and output is a hard problem and something very few windowing systems manage to get right. The solutions tend to involve some degree of inconvenience for the user.

What exactly would you propose to add? This isn't a matter of implementing new functionality, but rather removing fundamental misfeatures. Any change to address this issue is going to end up breaking existing applications which depend on the original input behavior.

In any case this is hardly the only reason to switch to Wayland. It's just one of many areas which highlights the drawbacks of trying to tack modern best practices on top of an aging framework. Better to adopt a clean and modern design as the base and confine the hackish workarounds needed to support older clients to a separate compatibility layer.

Yes. This isn't just X, by the way; it's a common design across most operating systems. Any client can register to receive keyboard and mouse input regardless of the current focus, unless another client has already "grabbed" the input device. This is how things like global keybindings are typically implemented. Windows used for password entry (including lock screens) can grab the keyboard to prevent other programs from listening in. The problem is that this only works if no other program has already grabbed the keyboard.

Secure input handling is one of the many reasons why everyone is eventually planning to switch to Wayland. Under Wayland, only the compositor has access to the raw input or the ability to inject simulated input events. The compositor manages any global keybindings and forwards the remaining events exclusively to the active window.

The concept of the "Nanny State" is more about means than ends. If a state's approach to "protecting" people involves restricting their freedom, then it's a Nanny State. The goal is laudable, but does not justify the means.

You're assuming that they already know that you have the keys. If they don't know that, then demanding that you open the cabinet amounts to a call for self-incrimination—not because of the contents per se, but because it would show that you had access to the contents. (Perhaps you received a locked cabinet with no key, and have no idea what may be inside.)

Similarly, if they haven't already shown that you have access to the social media account in question, then simply revealing that you know the password would be self-incrimination. Perhaps someone else set up the account in an attempt to frame you.