5 ms·

TFS was never really that good and I won't defend it, but Winforms and WPF are more RAD tools not really appropriate to projects like Office. They are excellen

TFS was never really that good and I won't defend it, but Winforms and WPF are more RAD tools not really appropriate to projects like Office. They are excellent for the tasks they were designed for. Re the Office libraries you probably wouldn't want to use them anyways. They were designed for maximum flexibility and performance not with ease of use or fast development velocity.

Ididntdothis 7y ago
I think it’s a big problem if a vendor of dev toolkits doesn’t use them themselves. WPF is a great example. The underlying concept is very interesting but it seems they stopped developing it before it had the chance to be really good.
- jdsully 7y ago
  I don't think its fair to say it wasn't used. Just that it wasn't used on the big projects like Office. There were certainly a ton of internal tooling from that era that did indeed use it, which was also the primary use case in the wild: Internal line of business applications. With RAD you are making tradeoffs that aren't appropriate for massive code bases. Microsoft always took dogfooding very seriously. It's a bit like complaining Ford doesn't use its pickup trucks to transport vehicles to the dealer. They just aren't designed for that purpose.
  - Ididntdothis 7y ago
    To some degree I understand what you are saying but it’s still a wrong strategy. It means there are easy to use tools for small apps and large apps have to deal with Win32 directly with nothing in between. No wonder the desktop is dying. The propaganda MS has been putting out also contradicts this. I remember well how they were first telling us that WPF, then Silverlight, then WinRT is the future of windows. Got burned a few times and then refused to look at UWP which is now the future of Windows until it probably isn’t.
    - JamesBarney 7y ago
      Most desktop projects I've seen have stuck with WPF and they've all been happy with that decision (except for a few who wish they'd gone web).
      - Ididntdothis 7y ago
        That’s pretty much how I feel. Go to web if possible. It’s also better for the resume :)
    - jdsully 7y ago
      .NET has a very good inter-op story for win32. If you started with MFC, WPF, or another framework and then needed to add win32 flourishes you can do so quite easily. It's quite a different thing to try and retrofit a traditional win32 message pump application with one of these frameworks. Especially if it's in an entirely different language and runtime. Had Office been born in the early 2000s its quite likely they would have tried to use .NET and had the same issues as Longhorn. I think Microsoft did have broad ambitions for the framework, but reality was the tech couldn't handle large scale software at that time and Longhorn failed as a result. I think your right it is a little unfortunate win32 is needed if you want to make a million LOC desktop application. I don't think there really was anything better for native code up until recently with modern C++. The ugliness of COM and MFC are really due to limitations of C and C++ at the time. Now I don't think there is enough demand to really justify something radical. .NET Always did reasonably well for web backends, and I think they have the right strategy to keep pushing there.

Ididntdothis 7y ago

I think it’s a big problem if a vendor of dev toolkits doesn’t use them themselves. WPF is a great example. The underlying concept is very interesting but it seems they stopped developing it before it had the chance to be really good.

jdsully 7y ago
I don't think its fair to say it wasn't used. Just that it wasn't used on the big projects like Office. There were certainly a ton of internal tooling from that era that did indeed use it, which was also the primary use case in the wild: Internal line of business applications. With RAD you are making tradeoffs that aren't appropriate for massive code bases. Microsoft always took dogfooding very seriously. It's a bit like complaining Ford doesn't use its pickup trucks to transport vehicles to the dealer. They just aren't designed for that purpose.
- Ididntdothis 7y ago
  To some degree I understand what you are saying but it’s still a wrong strategy. It means there are easy to use tools for small apps and large apps have to deal with Win32 directly with nothing in between. No wonder the desktop is dying. The propaganda MS has been putting out also contradicts this. I remember well how they were first telling us that WPF, then Silverlight, then WinRT is the future of windows. Got burned a few times and then refused to look at UWP which is now the future of Windows until it probably isn’t.
  - JamesBarney 7y ago
    Most desktop projects I've seen have stuck with WPF and they've all been happy with that decision (except for a few who wish they'd gone web).
    - Ididntdothis 7y ago
      That’s pretty much how I feel. Go to web if possible. It’s also better for the resume :)
  - jdsully 7y ago
    .NET has a very good inter-op story for win32. If you started with MFC, WPF, or another framework and then needed to add win32 flourishes you can do so quite easily. It's quite a different thing to try and retrofit a traditional win32 message pump application with one of these frameworks. Especially if it's in an entirely different language and runtime. Had Office been born in the early 2000s its quite likely they would have tried to use .NET and had the same issues as Longhorn. I think Microsoft did have broad ambitions for the framework, but reality was the tech couldn't handle large scale software at that time and Longhorn failed as a result. I think your right it is a little unfortunate win32 is needed if you want to make a million LOC desktop application. I don't think there really was anything better for native code up until recently with modern C++. The ugliness of COM and MFC are really due to limitations of C and C++ at the time. Now I don't think there is enough demand to really justify something radical. .NET Always did reasonably well for web backends, and I think they have the right strategy to keep pushing there.