3 ms·

Here specifically too: Microsoft has such a weird lead in AR/MR/VR and have mostly just been sitting on it. For example, because of early Kinect work, they own

Here specifically too: Microsoft has such a weird lead in AR/MR/VR and have mostly just been sitting on it. For example, because of early Kinect work, they own the patents that would have made Meta's weird journey between "no legs" to "everyone gets legs if they want them! excitement!" irrelevant or much faster had the partnership happened sooner. They built the first "metaverse cloud" on Azure and they've used it and they've made something as exciting in theory as the HoloLens boring Enterprise products. The other possible takeaway is that after Windows Phone, Microsoft really has been truly risk adverse when it comes to consumer products, even in areas where they had a lead and could have delivered something no one else could. > VSCode shows they can execute, but for some reason when the stakes are higher they don't do as well Windows Phone Windows Phone was arguably very well executed at the software level. Microsoft's troubles with Windows Phone were at the hardware levels and (worse) the economic levels where the phone carriers had already decided they prefer a duopoly and selling three things is one too many things to sell.

pjmlp 4y ago
Windows Phone was bad executed at development experience level, with the WinRT, UAP, UWP enforced rewrites.
- WorldMaker 4y ago
  We've had this argument more than once and I still disagree with that take. I took a .NET application through those transitions and there was never a "from scratch rewrite" step at any point. A lot of cheese moved and there was sometimes quite a bit of XAML shifts to meet new UI expectations, but most of the business logic code stayed the same or barely changed. On the other side, I've seen Apple enforce equal or worse "enforced" rewrites between major iOS versions with not even a fraction of the complaints Microsoft got across those product versions. (I had more inconvenience moving apps back and forth between WPF and Silverlight in some of the years prior, and even those moves were never from-scratch rewrites. Admittedly that may have left me with more skills to handle XAML changes and write to lowest common denominator XAML, so I am aware of my biases.) I realize you aren't ever going to agree with me on this, and I don't expect you to. I do think it is still useful for other people to see that there are counter-opinions here.
  - int_19h 4y ago
    Apple can get away with a lot more given its dominant market position (esp. when it comes to delivering paying customers to app authors). But when you're the new scrappy contender with minimal market share, so you need the devs to make apps for your store rather than the other way around, it better be smooth sailing all around.
  - pjmlp 4y ago
    A rewrite is a rewrite, even if only one line changes. Not going to bother to list everything that changed, it is public available for anyone to judge.
  - karmakaze 4y ago
    The difference of course is that iOS already has enough adoption to get away with this. Windows Phone and Windows UI development forked for no good reason while keeping very similar names and structures while trying to get initial adoption. It was clearly a mistake at that stage. I personally looked into the tech and as soon as I saw how fragmented it was realized MS didn't have a good plan and didn't venture developing for it.
    - WorldMaker 4y ago
      Windows Phone 7 was pretty clear [1] it was a temporary platform (bootstrapped on Silverlight) while they waited for the engineering projects that were to become Windows Phone 8 finished. Microsoft helped pay to migrate some projects across that hump and there was a migration story. That's the only "hard fork" between the versions. I know a lot of people (including respondents in neighboring comments) saw the changes between WP8 and WP10 as a big deal "soft fork", but very little actually changed other than a UI library upgrade from 1.x to 2.x. (In .NET; JS was dropped in 2.x and C/C++ developers saw some other shenanigans. But JS and C/C++ didn't exist in WP7 either so none of those developers saw all three "migrations" either.) I hear a lot from developers that it seemed very fragmented, but working in it at the time, it seemed very "incremental" at best, mostly just upgrading library major versions and dealing with semver major breaking breaks. Sure, that's frustrating when that's not your primary development environment and also you aren't getting paid enough for it because adoption is low, but that is a very far cry from "Microsoft didn't have a good plan". They were iterating hard on it. They made some semver breaks that other library authors in other ecosystems could get away with no problem, even with equally low adoption (looking at random JS libraries here). It's easy to blame low adoption for making those semver major breaks seem more painful and "fragmented" than they actually were in practice, but sometimes it just also looks like that was an excuse to ignore the platform more than a problem for development experience reality. (As you seem to state that you skipped the platform entirely, possibly because you were looking for an excuse to skip it and latched onto the first one you saw.) [1] Obviously not clear enough for some.

pjmlp 4y ago

Windows Phone was bad executed at development experience level, with the WinRT, UAP, UWP enforced rewrites.

WorldMaker 4y ago
We've had this argument more than once and I still disagree with that take. I took a .NET application through those transitions and there was never a "from scratch rewrite" step at any point. A lot of cheese moved and there was sometimes quite a bit of XAML shifts to meet new UI expectations, but most of the business logic code stayed the same or barely changed. On the other side, I've seen Apple enforce equal or worse "enforced" rewrites between major iOS versions with not even a fraction of the complaints Microsoft got across those product versions. (I had more inconvenience moving apps back and forth between WPF and Silverlight in some of the years prior, and even those moves were never from-scratch rewrites. Admittedly that may have left me with more skills to handle XAML changes and write to lowest common denominator XAML, so I am aware of my biases.) I realize you aren't ever going to agree with me on this, and I don't expect you to. I do think it is still useful for other people to see that there are counter-opinions here.
- int_19h 4y ago
  Apple can get away with a lot more given its dominant market position (esp. when it comes to delivering paying customers to app authors). But when you're the new scrappy contender with minimal market share, so you need the devs to make apps for your store rather than the other way around, it better be smooth sailing all around.
- pjmlp 4y ago
  A rewrite is a rewrite, even if only one line changes. Not going to bother to list everything that changed, it is public available for anyone to judge.
- karmakaze 4y ago
  The difference of course is that iOS already has enough adoption to get away with this. Windows Phone and Windows UI development forked for no good reason while keeping very similar names and structures while trying to get initial adoption. It was clearly a mistake at that stage. I personally looked into the tech and as soon as I saw how fragmented it was realized MS didn't have a good plan and didn't venture developing for it.
  - WorldMaker 4y ago
    Windows Phone 7 was pretty clear [1] it was a temporary platform (bootstrapped on Silverlight) while they waited for the engineering projects that were to become Windows Phone 8 finished. Microsoft helped pay to migrate some projects across that hump and there was a migration story. That's the only "hard fork" between the versions. I know a lot of people (including respondents in neighboring comments) saw the changes between WP8 and WP10 as a big deal "soft fork", but very little actually changed other than a UI library upgrade from 1.x to 2.x. (In .NET; JS was dropped in 2.x and C/C++ developers saw some other shenanigans. But JS and C/C++ didn't exist in WP7 either so none of those developers saw all three "migrations" either.) I hear a lot from developers that it seemed very fragmented, but working in it at the time, it seemed very "incremental" at best, mostly just upgrading library major versions and dealing with semver major breaking breaks. Sure, that's frustrating when that's not your primary development environment and also you aren't getting paid enough for it because adoption is low, but that is a very far cry from "Microsoft didn't have a good plan". They were iterating hard on it. They made some semver breaks that other library authors in other ecosystems could get away with no problem, even with equally low adoption (looking at random JS libraries here). It's easy to blame low adoption for making those semver major breaks seem more painful and "fragmented" than they actually were in practice, but sometimes it just also looks like that was an excuse to ignore the platform more than a problem for development experience reality. (As you seem to state that you skipped the platform entirely, possibly because you were looking for an excuse to skip it and latched onto the first one you saw.) [1] Obviously not clear enough for some.