Tricky. If the question is should calculus be a prereq for CS, I'd say only if you also want to require some EE background, in which case you need calculus to solve many of those problems. I do think a minimal amount of EE background is worthwhile, even if not critical; at my school you could do CS either as a BS or BA; I chose BS, so I did get the EE prereqs and am a little biased. Otherwise, though, calculus has little direct relevance to CS. Much more relevant would be Boolean logic, or maybe even a philosophy of logic course (it never hurts to hone the verbal skills too, and it trains the mind just as assuredly as pure math study). All that said, if you take it as a given that intro calc is required, and yet the student can't pass the class, if I were their advisor I'd be concerned. Basic calc may be tough to understand intuitively but is rather easy to apply superficially - which also happens to describe a lot of programming problems. They don't have to be able to prove the fundamental theorem of calculus from scratch, but if they can't at least follow the spoon-fed algorithms for obtaining simple derivatives and integrals, and/or don't have the ability to break down complex problems into smaller ones (and then apply said spoon-fed algorithms), then they might also have a hard time tacking difficult programming problems. This is nothing unique to calculus vs. other advanced math, though. Like 99% of people who learn any advanced math, it's not about whether they will use it later in life (I've literally never applied calculus in real life, to my recollection). It's about training to, and proving they can, solve complex problems given the tools needed to do so. They don't have to study calculus, or any other specific form of advanced math, to be a good programmer, but if they *can't* handle it after trying, I'd say it's something that at least should be looked into and understood why not.

I have a 7-year-old commercial desktop application that uses the MVVM pattern, which is currently built on WPF with many UI customizations. Every control has been re-templated and restyled. We have a custom video player that uses libav/ffmpeg for decoding and outputs video through `D3DImage`. We hook into Windows 10+ gesture events for modern touch support. Nonetheless it's now time to overhaul the application's frontend. This will be a complete gut job of the entire "view" layer. (The data model+view model layers will remain unchanged as these also are the foundation for a Blazor web app.) The question is whether to stick with WPF or move onto either WinUI3 or Avalonia. It's down to those three finalists, plus the slightly insane idea of building a UI from scratch with C# hooked into Win32 and Direct2D. WPF has aged remarkably well and is still very much in the running, but I'm concerned we're missing out on the improved performance and visuals that modern frameworks offer. Its reliance on the obsolete Direct3D9 and Microsoft's refusal to update it to D3D12, or better yet Direct2D, are frustrating. On the other hand I remain deeply concerned about WinUI3's stability and Microsoft's commitment to it (or lack thereof), and Avalonia only hit v1.0 recently and the number of commercial projects that utilize it is still relatively small (though growing). Note we only need to support Windows. I'm interested in hearing firsthand experiences from folks who recently used WPF, WinUI3, and/or Avalonia to make a new and/or renovated real-world commercial or LOB application. No theoreticals or hypotheticals please! :) What was your experience? Did you encounter any showstoppers? Any unresolvable bugs or concerns about the platform(s) that still keep you up at night? Were the platform developers responsive to support needs? Anything else you can share about the experience to help someone make a decision? Many thanks in advance.

That was an interesting read, as was this: [Vacuous truth - Wikipedia](https://en.wikipedia.org/wiki/Vacuous\_truth#:~:text=In mathematics and logic%2C a,does not really say anything.) I don't pretend to be a mathematician, but if all conditions can be satisfied by all members of an empty set, then all members of the empty set would satisfy the condition that their parent set is non-empty. If we took the other approach and said that no condition can be satisfied by all members of an empty set, then all members of the empty set would fail to satisfy the condition that their parent set is empty. Both approaches lead to contradictions, which is why the answer seems like it should be undefined.

I figured I might be in the minority here, but suprised how overwhelmingly folks agree with Microsoft on `[Empty].All() == true`. Mathematically I totally get it. None of the items is false. Fine. But consider a real-world application and what I, as someone giving orders, would expect: Darth Vader is commanding the Imperial fleet and approaching a suspected Rebel base but is uncharacteristically concerned about civilian casualties for once. "Are there any civilian inhabitants of this planet, commander?" "No, Lord Vader," the commander replies. "Good, so they're all rebels?" "Yes, milord." "Sterilize the planet," Vader commands. The fleet spends the next four hours bombarding the planet, burning the entire surface and boiling the oceans, while Vader waits impatiently as he is eager to proceed to the next suspected target. Finally when the carnage is over, Vader asks, "Well done, Commander. How many Rebels did we kill?" "Well, um, none, milord," the commander meekly replies. "What do you mean?" "The planet was uninhabited." Vader initiates a force choke. "You said there were Rebels here!" The commander struggles to spit out his last words. "I said the inhabitants were all Rebels, not that there were any inhabitants."

Oh after this episode I no longer use `All`; instead: public static bool AnyAndAll(this IEnumerable source, Func predicate) { if (source == null) return false; bool any = false; foreach (var item in source) { if (!predicate(item)) return false; any = true; } return any; }

You're not wrong. But you're not right either. Maths vs. Words :-D

Only because you agree with their logic. Not everyone does. The ambiguity is the issue, not whether you or I agree with the decision.

Here's a more obscure one. `HashAlgorithm.TransformBlock` is for computing things like MD5 and SHA hashes on streamable data. `TransformFinalBlock` needs to be called at the end, even if there's no data left to include in the hash. Notably you have to give it both an array AND the length. You can give it an empty `byte[]` and specify it has 0 length, and it's perfectly happy. But give it a `null` buffer - even if you specify 0 length! - and it throws on you. I'm explicitly telling it I have no data to give it, but I still have to give it the empty array, for reasons.

But also great example.

Would you think otherwise if the method were called `Every`?

Well look I'm not saying there's no good *argument* in favor of `[Empty].All()` returning `true`, and I totally get the programming logic of starting with `true` and breaking if and only if you find a `false`. It's not like the decision is unjustifiable. But I think the "Right Thing" to do here is more than sufficiently debatable that if ever there was a time to throw an exception (which they love to do in countless other contexts) it would be here.

Someone really should start a weekly blog of inane .NET logic when it comes to what it does or does not throw an exception for vs. just behaving according to some default arbitrary choice. Entry #1: On an empty collection, `.Any()`, with our without a condition, always returns `false`, as any sane person would expect. However, `.All(condition)`, on an empty collection, returns `true`. HUH? If I look at an empty room and ask "Are all the people in there aliens?" the answer I expect is apparently YES? If ever there were a situation where a method call is so nonsensical that there is no possible objectively right way to handle that which everyone would agree on (thus justifying an Exception), it's asking about `All` the items in an empty collection. It's tantamount to division by zero. And yet on a `null` collection, even though these are all extension methods and perfectly capable of treating `null` as empty, it throws .NET's all time favorite and #1 most useless exception, `NulLReferenceException`. Clearly the .NET developers' goal is to ruin as many of my days as possible.

I find Windows Forms' popularity in 2024 inexplicable, I'll be honest, but I will defend MFC and WPF. If you want to use C++ and want to fully leverage Windows and aren't worried about cross-platform, there's still no better option than MFC. The thing to remember about MFC is it literally is a set of FOUNDATION classes. You can still utilize every modern Win32 API you want to. MFC just takes care of the most obnoxious parts of the scaffolding and UI interactions that you really don't want to be dealing with, and it's stuff in Windows that hasn't changed in decades. So MFC really by definition will continue to be relevant and usable indefinitely as long as Windows exists, most likely, and really needs no significant updates. Your alternative is to use pure Win32 with no helper framework. If you really want to do that, you might as well just write in assembly too. :D WPF is in a somewhat similar boat except it's C# and XAML. It is infinitely flexible and extensible. I mean, there's literally no application UI you can conceive that you can't do in WPF given that you can completely retemplate any control and even use Direct3D if you want to. You might be doing a lot of the work yourself, but it's doable, so again, it sort of by definition has an indefinite shelf life. As for Forms, it's more or less the C# equivalent of MFC, but WPF offers far more flexibility in customizing UI, so unless you hate XAML for some reason (though you actually don't HAVE to use XAML if you really don't want to) I don't see why you'd pick Forms over WPF today. Nonetheless it is on par with MFC and WPF in terms of reliability and scalability so I also don't begrudge anyone who uses it. Other than those three (MFC,WPF,and Forms), none of Microsoft's application frameworks are suitable for enterprise or commercial productivity applications. UWP is more or less on par (IMO) with Android and iOS for dinky consumer "apps" but out of the question for anything that needs to scale. WinUI3 came with a lot of hype but years later still suffers from stability problems, and not being open source I'm not going to let myself be 100% reliant on Microsoft to fix their bugs or find workarounds (wait, I guess it finally is open source as of late last year, so maybe that will be an option soon). MAUI (nee Xamarin Forms) is a sad parody of its former self. Blazor Hybrid, I don't even know what the @!%*% that's supposed to be. And Visual Basic? Well remember VB.NET is just a programming language and is actually equivalent to C# line-by-line. Based

Whoever gave that directive is a man after my own heart. It's extreme, to be sure. Realistic to literally follow 100% of the time? Probably not. But as an aspiration, a philosophy - absolutely. If you do this, you will be able to grow and scale your products effortlessly for decades - basically for as long as the programming language you use is supported - without a rewrite. Nuget packages, even entire application frameworks will come and go, yet your core code will be snug as a bug in a rug, wrapped in layers of abstraction that shield it from the chaos. When your favorite library is deprecated, revealed to have a critical vulnerability, or the vendor jacks up the price on you, you scoff at how simple it is to assign someone to find a replacement and write the wrapper layer - *completely independently of everyone else*. Your customer tells you the application you designed for Azure now needs to run on AWS? "No problem", you say, "give me a week." Microsoft decides to make 100 new breaking changes to ASP.NET Core? Bah! The upgrade takes an hour. You will never be stuck relying on proprietary technology outside of your control ever again. The term "technical debt" won't even be part of your vocabulary. So yes. Those who know, do this.

An informal survey here to find out if anyone is actually using Win UI 3 in a real commercial application that people pay for? I'm sure there are plenty of LOB apps and personal projects etc., but I mean is anyone using it for anything serious that they expect to make money off of? A bet-the-company flagship product? Three years after release, compared to WPF it's buggy, inflexible, and poorly supported (by Microsoft or by the community - try running a search to find something Win UI 3 specific and seeing how much UWP or WPF content you have to sift through). I badly need to move off of WPF for its being nearly 20 years old and unsupported, but I find WinUI 3 to be essentially unusable. It suffers from the ultimate problem that nearly all Microsoft development technologies suffer from - because they don't use it to develop their own consumer products, it - at best - isn't a strategic priority, or - at worst - it's deliberately crippled to make sure their own products can't be edged out. I'm tempted to just use DirectComposition and build an entirely homegrown UI framework, which I then at least can control and debug. I'm almost certian this is what all the major development shops (including Microsoft) do for their flagship products. What other options are there at this point really?

None of the above I'm sorry to say. I would make all future applications using pure HTML5 backed either by Typescript, C#/WASM/Blazor, or pure JavaScript. Then distribute it across platforms as a PWA or a Blazor hybrid app. You're then dependent on no one company's whims and shortcomings. 5 years ago I would've been horrified by this suggestion but I'm a convert now. Microsoft has proven itself completely inept at native frontend and without web support MAUI can't be taken seriously anyway. Google Flutter is interesting but requires Dart which makes porting existing apps impossible and limits the available open source ecosystem severely. Other options - Uno is too slow on the web. Avalonia is a maybe but last I checked has no web support. Here's the bottom line. No one has a strong commercial interest in making a true write-once-run-everywhere ecosystem. For anyone who has it - like Microsoft with Office or Google with GSuite - it's a competitive advantage and they're not gonna give it away. Whatever they do give away will be made by a different team than their commercial products and be inferior and watered down. If you want something done right you have to do it yourself.

Actually all copyrights, trademarks, and patents would be invalid, as pi existed since the Big Bang (if not earlier) thus rendering all IP unoriginal. You're still screwed on the malware and defaming scientology fronts though.

Not at all what I'm asking.

With the hodgepodge of frameworks available to make Windows applications these days - MFC, WinForms, WPF, WinUI, UWP, MAUI, Blazor Hybrid - and that's just the ones made by Microsoft! - it's really difficult to know which are suitable for a modern commercial application. Rather than ask for recommendations or believe marketing hype, the best evidence for whether a framework or language is good is who's actually developing commercially successful applications with it. So what frameworks and languages are the big commercial shops using when publishing Windows applications these days? Specific applications I'd like to know about are - - Microsoft Office for Windows - this appears to be C++ with some kind of Javascript engine. There might be some .NET in there but it doesn't seem to be prevalent. I'm guessing they're using DirectComposition and have a homegrown control library that's completely untethered from the OS, but does anyone know for sure? - Adobe Suite - also appears to be C++, but I'm guessing they have some home-grown cross-platform framework that allows them to keep the Mac and Windows versions in sync easily. - Visual Studio IDE (not Code) - At one point this was WPF, but I can't tell what it is now. - Slack - Electron maybe? - Google Chrome - Obviously not .NET - guessing C++ and DirectComposition? Secondarily, I can't find any evidence that big commercial applications are actually written using any of the Microsoft frameworks that are publicly available, other than perhaps WPF. UWP, WinUI, and Blazor all seem to be commercially irrelevant as far as I can tell. Would love to hear evidence to the contrary though.

Doesn't express have memory and cpu core limitations that dev and the commercial editions don't? That would almost certainly explain it. Personally I like testing on low memory, low cpu SQL because it forces me to optimize performance.