As far as I can tell, the only issue with the workhouses was that they provided a better standard of care than the employed poor received. That should no longer be the case today.

The other issue was possibly that the profitability of running such a place was overestimated given how few "able bodied idlers" there were, but it seems obvious that such places would need to be state funded.

I suspect they would work quite well for (an evolution of visual novels), since those are already set in the first person, but don't require moving around the way FPSs do. Not sure how the controls would work though...

I believe this is no longer the case. One of the big changes in Plasma 5 was rewriting the process model used for plasmoids. That said, I can't find a source to confirm this, and am too lazy to download and run one of the Project Neon ISOs.

From Wikipedia, citing the US Copyright Act:

Whether or not it's a patch is immaterial; as a derivative work the subtitlers cannot legally distribute it. In practice, both the publishers (at least the smarter ones) and subtiltlers tend to ignore this.

The law was quite clearly written when a translation of the original work would be a substitute for the original. e.g. owning an English translation of a book would negate the need to own the original. IMO works which do not substitute for the original work such as subtitles or dubbed audio tracks should not be considered derivative works. An alternative would be for translation to be recognized as fair use (since it is merely the analog equivalent of format shifting). Of course, the actual likelihood of US copyright becoming less draconian is quite remote...

...and 16 other languages.

I would argue that the main issue is Python's lack of static typing. Pretty much every non-interpreted language has static typing, and it's arguably more fundamental/basic than OOP.

The experts developed those rules over time - an expert system is incapable of that sort of learning. If anything changes, they won't have anyone who understands the basis of the system well enough to define new rules.

You can't tell people how to feel - how often does telling an angry person to calm down work?

I have some personal experience in this, and the trick seems to be to break the cycle. You're depressed because your situation sucks, and your situation sucks because you're depressed. Working at overcoming the symptoms of depression is a rational solution because it breaks the loop, but it's not an emotional one because they still feel like crap (at least until things pick up, but even then there'll be depressive bouts). Wording things such that you're not invalidating them will make them more receptive, but it is very much a case of having to walk uphill to get treatment for a broken leg.

That said, the person in question actually has to learn how to break that cycle; it's not something you can just tell them. There are things like CBT that are based around this, but at the end of the day it's very much based around learning how to regulate and control your emotions.

I disagree - Perl's biggest issue is that things which should be defined in the language's grammar are instead defined in code. This reduces it to a language of special cases.

Consider the following:

$_ = foo 1;
bar;
print;

Does the function bar, in the absence of an argument, use $_ as its argument?
Some functions do, some don't, and this is true even among the core functions. This is because the implementer of the function must explicitly read from the global $_, rather than the language passing the argument to it. The resulting inconsistency can make it difficult to reason about what a Perl script is actually doing.

There are other issues, such as variables inside functions being global by default, but that's the big one.

I suggest you look at using D instead. It is as powerful and efficient as C++, syntactically very similar to C#, and can link C++ libraries.
The main benefit this provides (apart from performance) is that it will be much easier to do a cross-platform release - although C# has Mono, I've found it to be unreliable.
That said, D is somewhat obscure, so caveat emptor.

tldr: good faith = don't be a dick

Disclaimer: IANAL, and I am not particularly familiar with equity law, which (promissory) estoppel falls under.

In contract law, acting in bad faith refers to following the literal wording of the contract while taking actions that would deprive the other party of their benefits. e.g. you lease a car, but do not provide the car key. In some jurisdictions there is an implied duty of good faith in contracts, while in others explicit terms are required.

Now, in this case there is no contract because there is no quid pro quo relationship between Tesla and the licensees (the legal term is consideration). Instead it is enforceable by promissory estoppel, which essentially means Tesla can't sue someone who relied on their statements.

Since Tesla isn't explicitly receiving anything in return for the license, it's unclear what an action in bad faith could deprive them of.
One argument would be that the benefit Tesla accrues from this is that other companies will (hopefully) build infrastructure. It's entirely possible that they may choose to do so using Tesla's patents but with incompatible, DRM'd connectors. I suspect this is what the good faith requirement is intended to prevent. (Non-DRM'd connectors would be more of a grey area, since they could argue that it was used simply because their technology is better.) In other words, the other company would not be permitted to prevent Tesla from supporting their charging stations if they used the patents in question.

Subjectivity cannot be eliminated completely; that is why the reasonable person test is used in law. Most (or possibly all) human languages require some interpretation on the part of the reader, and as a result terms like 'reasonable person' and 'good faith' are used in law to imply that such interpretation is required there.

You jest, but given that ChromeOS is a Gentoo-derivative, it might not be that far off...

I'll second this. I got a paid subscription to them after the picked up a kernel performance regression bug that no one else had noticed. They also regularly do file system benchmarks, which are really useful if you're interested in that.

C# is now 14 years old - I highly doubt it can be considered fly-by-night at this point. Not to mention Swift doesn't even achieve feature parity with it - it lacks C#'s variant generics and list comprehensions (which seem to be combined with lazy evaluation and called LINQ in C#).

My underlying point is, why create a new language? It's justifiable if you're actually trying to add new features or paradigms (e.g. Rust was created so that memory safety could be enforced at compile-time), but otherwise it's just change for the sake of change. It would make more sense to adopt the syntax of an existing language (e.g. Java, C#, C++, etc.) so as to leverage existing users of those languages, rather than requiring them to relearn the semantics. If you need to replace Objective-C, why create a whole new language when there are plenty of perfectly good ones already?