Brandon Staggs

No, but because Windows machines cost so much less for substantially the same thing. The fact that I build my own machines is not really the point; I don't believe most Windows machines are dead in 3-5 years, that's ridiculous. Nearly everyone I work with is using Windows machines at least that old. If you prefer MacOS that's certainly fine, nobody can criticize you for that. My personal experience as someone actively doing development for Macs is that it is easily the worst system to target for development and gets worse with every major update. Although it may be a lot of Unix under the hood, Apple is locking it down more and more with every update. Apple behaves as if it owns not only its hardware but their users. The Apple Tax is not just overpaying for hardware, but losing personal computer sovereignty with every update. It's bad enough on Windows, it's many times worse on Mac.

One of the supposed benefits to an EV cert is that it comes with instant SmartScreen rep. My own experience was than the first time I signed with my EV cert nobody saw any SmartScreen warnings, which was never the case when I first used cheaper certs in the past. Do different browsers use their own screening systems? Windows + Edge should be consistent, but maybe other browsers don't care what SmartScreen thinks?

Sounds like a very poor choice of computers, then. I have like four or five Windows PCs in my house all being used that are 5 or more years old. But, I did build them myself. The cost of Mac computers is outrageous. I am forced to buy them for development work, but unless you are or want to be in the Mac ecosystem, the prices are just too high. This is par for the course with Apple products since the 80s, they have always been overpriced but catering to a subset of the population that buys into their marketing. I will say that modern Mac computers are almost works of art from a hardware standpoint and I guess I understand that for some people this justifies the price, and for others MacOS is better suited to them and you can only legally use their OS on their devices, so.

Yup, which is just one more reason why safety through automatic initialization is illusory.

Much easier said than done if you have a large legacy application built around Trident. If you are using a lot of synchronous javascript calls the refactoring job to work in the asynchronous Edge browser is no small refactoring task. Obviously it would be a worthwhile thing to do, IMO, but of course that needs to be balance against other concerns...

Funny, that was the first step in the right direction I've seen Bezos take with the Washington Compost.

I'm seeing this more and more lately. It is very worrisome that people actually think these autocomplete engines are authoritative and will actually argue with you if you present facts that disagree with the text generated by these tools. They may have their uses, but this is borderline scary.

The fact is that any design-time component can crash the IDE. All you have to do is uninstall them all and see if your problem persists. If it does, you can be relatively certain it is the IDE itself and not a component. You seem very resistant to this basic troubleshooting step. That doesn't seem rational. I agree that Delphi quality is not where it needs to be. I do not agree that the IDE is as useless and impossible to use as you have said. Shrug.

To be clear, I do compile MacOS (Arm64) targets. It seems self-evident to me that the comparison you suggest is invalid. Doesn't make a difference either way; unless Windows on ARM is a passing fad, which I doubt, we need a compiler that can target it.

I can't compare emulated Delphi x64 code on Windows vs compiled ARM64 code because Embarcadero doesn't offer the latter yet. Ostensibly, the benefit will be not having to rely on a layer of processor architecture emulation. I certainly can't see the benefit of Embarcadero pretending there is no ARM64 Windows executable format and ignoring it altogether. If you decide the x64 output works better you aren't going to be forced to distribute ARM64 binaries.

This also depends on application. There is no way I would trade my desktop AMD cpu for Snapdragon. I do not care about power consumption there and there is no comparison on performance. But on a laptop, I am already using Snapdragon and I am pleased with it. I don't know what we're arguing about here. Personally I want the ability to target Arm64 on Windows now that there are seriously good Windows computers using the architecture.

I wouldn't know. I don't build for Linux and I don't work for Embarcadero.

The x64 compiler is no paragon of code output. I think it would be nice to not have to rely on Embarcadero writing its own compilers. Obviously it goes without saying I would hope they configure the toolchain properly for good output, too. Performance and power use. So far the testing of Windows applications on Snapdragon indicates you're going to get the best performance and efficiency with native code, which is exactly what one would expect...

The events of the last six months have certainly changed some of my opinions on this, but I am still trepidatious about an LLVM ARM64 Windows compiler "just working" with code that has been in production for 25 years. And regardless of my concerns about potential issues, I very much want an ARM64 Windows compiler as soon as possible. I'd actually like the option to build x64 with LLVM as well. Whatever issues there are to deal with, such as making sure exception handling works as I expect it to, I'll deal with them.

You may not understand how Delphi works. In Delphi, all of your third-party components are DLLs running in the IDE's process. That's how RAD works, for better or worse, and it means that problems in third-party components will often cause havoc in your IDE. If you are unwilling to start from scratch with no third-party components and do some basic trial-and-error you will never know if the problem you are having is Delphi or not. I can say I do simple and complex searching in the IDE every day many many times as I work and I do not have any problems with those features. The most likely difference between my setup and yours is going to be what components we have running in the IDE, so, it's a good place to start.