I think television has done more harm, politically.

Radio did plenty of harm as well (especially post 1987). Rush Limbaugh had a peak audience of 20-30 million listeners a week in the 90s. The current state of politics might've been unpreventable, at least in the US.

Radio did plenty of harm in 1930s Germany - Hitler was a master of the new medium.

> C# is a nightmare of language identities - a jack of all trades, master of none, choose your dialect language.

I honestly have no idea where you would get this idea from. C# is a pretty opinionated language and it's worst faults all come from version 1.0 where it was mostly a clone of Java. They've been very carefully undoing that for years now.

It's a far more comfortable and strict language now than before.

I can see where he's coming from. For example, `dynamic` was initially introduced to support COM interop when Office add-in functionality was introduced. Should I use it in my web API? I can, but I probably shouldn't.

`.ConfigureAwait(bool)` is another where it is relevant, but only in some contexts.

This is precisely because the language itself operates in many runtime scenarios.

I guess that's a good point. I admit haven't used or seen `dynamic` in so long that I completely forgot about it.

But I'm not sure that's really a problem. Does the OP expect everyone to use an entirely different languages every single context? I have web applications and desktop applications that interact with Office that share common code.

Even `dynamic` is pretty nice as far as weird dynamic language features are concerned.

Interestingly enough `.ConfigureAwait(bool)` is entirely the opposite of `dynamic` -- it's not a language feature at all but instead a library call. I could argue that might instead be better as a keyword.

It is a library call, but one that is tied to the behavior of a language feature (async/await).

The reason I bring it up is that it is another one of those things where it matters in some cases depending on what you're doing.

Look at the depths that Toub had to go through to explain when to use it: https://devblogs.microsoft.com/dotnet/configureawait-faq/

David Fowl concludes in the comments:

    > That’s correct, most of ASP.NET Core doesn’t use ConfigureAwait(false) and that was an explicit decision because it was deemed unnecessary. There are places where it is used though, like calls to bootstrap ASP.NET Core (using the host) so that scenarios you mention work. If you were to host ASP.NET Core in a WinForms or WPF application, you would end up calling StartAsync from the UI thread and that would do the right thing and use ConfigureAwait(false) internally. Request processing on the other hand is dispatching to the thread pool so unless some other component explicitly set a SynchronizationContext, requests are running on thread pool threads.
    > 
    > Blazor on the other hand does have a SynchronizationContext when running inside of a Blazor component.

So I bring this up as a case of how supporting multiple platforms and runtime scenarios does indeed add some layer of complexity.

> It is a library call, but one that is tied to the behavior of a language feature (async/await).

This is a good example of C# light-touch on language design. Async/await creates a state machine out of your methods but that's all it does. The language itself delegates entirely to platform/framework for the implementation. You can swap in your own implementation (just as it possible with this union feature)

> So I bring this up as a case of how supporting multiple platforms and runtime scenarios does indeed add some layer of complexity.

I agree that's true. A language that doesn't support multiple platforms and runtime scenarios can, indeed, be simpler. However that doesn't make the task simpler -- now you just have to use different languages entirely with potentially different semantics. If your task is just one platform and one runtime scenario, the mental cost here is still low. You don't actually need to know those other details.

> This is a good example of C# light-touch on language design.

Is it? F# code doesn't even need ConfigureAwait(false), one simply uses backgroundTask{} instead of task{} to ignore SynchronizationContext.Current, and this didn't require any language design changes at all (both are computation expressions), but it would for C# precisely because it delegates this choice to the framework.

dynamic was also added as part of DLR, initially designed for IronPython and IronRuby support.

This inspired the invokedynamic bytecode in the JVM, which has brought many benefits and much more use than the original .NET features, e.g. how lambdas get generated.

Cloud is now massively larger than any other part of Microsoft. It's why he became the CEO in the first place.

He maybe never had a strategy for Windows but he wasn't hired to have a strategy for Windows.

Now try and read it assuming that instead of a screw up, this user was actually hacked. How do they recover?

Honestly, if you are using Gmail as your primary email I could probably ruin your entire year. I could just try and hack you (not even successfully) and Google will just shut down your entire life rather than attempt to work out who's right.

> I could just try and hack you (not even successfully) and Google will just shut down your entire life rather than attempt to work out who's right.

Had this happen to me. Fortunately the 'attacker' wasn't actually trying to do this, so damage was limited, but it's chilling when you think about what some motivated script kiddy can do with your Google account just by requesting password resets.

> They're not human languages. they're languages of the machine.

Disagree. Programming language for human to communicate with machine and human and human to communicate about machine. Programming language not native language of machine. Programming language for humans.

Otherwise make good point.

*dolphin noises*

Raymond Chen already discussed this. Microsoft wants to sell Windows. Windows exists to run software. If Windows doesn't run software, Microsoft doesn't make that sale.

If your business runs on some obscure piece of software for which updates are neither cheap or easy, you're not going to buy Windows if it doesn't run that software.

Name and shame doesn't work because the developer isn't part of the transaction.

The only thing it changes is the audience. Developers are an insanely small subset of iPhone users but these applications are targeting everyone else.

> The rule is just a bandaid on Apple's lack of true sandboxing for apps.

That's not it at all. If an app can run arbitrary code then it can run other apps and that can by-pass the app store. They are specifically trying to prevent something like Wechat on the iPhone. It's not about security, it's about money and control.

Wechat works on iPhone

Wechat is large enough to be able to negotiate requirements with Apple. They are the gateway to an entire continent and close to 2 Billion users. And since they are a 'everything app' the frequency of use and reliance is likely compounded.

Apple's not picking up the phone for 50 million users. So we shouldn't expect anything different here.

Luckily there are other phones and mobile os's to develop for.

If we had to live with this rule during the "classic" Mac era, it would have disallowed HyperCard.