9 ms·

OMG. MFC ? You mean Microsoft Foundation Classes ? mmh. that stuff is still supported ? eventhough there was/is all the .NET crazyness. That's actually pretty g

by je42 9y ago

OMG. MFC ? You mean Microsoft Foundation Classes ? mmh. that stuff is still supported ? eventhough there was/is all the .NET crazyness. That's actually pretty good of MS. I guess the main question is: how do you in advance if you got a MFC-like library from MS with 20+ year support vs a library like Sliverlight where they drop support and let you alone with a migration to a different platform ?

criddell 9y ago
Maybe there's a cautionary tale about being an early adopter here. I don't know if I would start a new project with MFC, but it was a fantastic decision in 1996. In a way, I think it's harder to pick technologies today for large projects. It seems like if something isn't new and growing steadily, it's stale and fading fast. What are the tools and frameworks with a long, healthy middle age ahead of them? I'm learning Go right now because there are a couple of web services I need, but I'm not that confident that I'll be able to run the same code for the next 20 years.
- dozzie 9y ago
  Erlang, for instance? Picking up a new shiny thing and complaining that it's not something with a proven track of backward compatibility is not a rational thing to do.
- pjmlp 9y ago
  Kind of, OWL and VCL were much better technology but Borland's management...
  - criddell 9y ago
    Oh man, I remember those now. You're right - they were better. It reinforces my point about how difficult it is to choose a long-term technology. It feels a little like picking stocks.
marcosdumay 9y ago
> how do you [know] in advance if you got a MFC-like library from MS with 20+ year support vs a library like Sliverlight where they drop support and let you alone with a migration to a different platform ? If it is old, it will be supported for a long time. If it is new, the odds are mostly on it not surviving. Ever wondered why so many people insist on using outdated stuff? You get a better deal from open source. But even there you may not like the possible consequences of using non-mainstream things.
WorldMaker 9y ago
As someone that worked on migrations to Silverlight and then to UWP, I still don't understand why these are seen as such big deals. The APIs were more similar than they were different and XAML is still XAML. (The only big loss from Silverlight was being able to browser-host it, but even then that was probably worth losing for the greater good to avoid terrible plugin websites.) The only thing they really dropped was Silverlight as (an unnecessary) brand name. If they had semvered the whole thing: Avalon => UWP 0.x, WPF => UWP 1.x, Silverlight => UWP 2.x, Windows 8.1 UAP => UWP 3.x, today's UWP ~=> UWP 4.x, I don't think any developer would have blinked, I feel like we'd have a lot fewer people feeling they dropped support for things... Then again, developers like to complain when their cheese is moved, it could be just like Python 2 versus Python 3 or VB6 versus VB7.
- maxxxxx 9y ago
  You couldn't just port from WPF to Silverlight. They took away tons of features. WinRT was even worse. No idea about UWP but I don't care anymore.
  - WorldMaker 9y ago
    That's why I mentioned semver. APIs change all the time, backwards compatibility gets broken. Yes, conversions weren't always straight forward, but often were possible, and there was an evolutionary arc to it all, and a migration story to follow, even when sometimes that story was a bit rougher than anyone wanted.
    - maxxxxx 9y ago
      There was no migration story. Usually an API gets more features but in this case they took away a lot of critical stuff. A lot of us write applications that need the full power of the OS and not just a small arbitrarily chosen subset.
    - fpig 9y ago
      They couldn't have done that because these technologies are not exactly for the same things and don't have the same features. Silverlight was mainly for apps embedded in the browser. It was very limited compared to WPF and not meant to replace it. Similarly, Metro was not meant to replace WPF. It was extremely limited in what you can do. You couldn't build serious desktop apps with that. The fact that all those technologies use XAML does not mean they're newer versions of the same thing. The difference in APIs is not what matters, it's the difference in what they can actually do and how that makes them different.

by je42 9y ago

criddell 9y ago

Maybe there's a cautionary tale about being an early adopter here. I don't know if I would start a new project with MFC, but it was a fantastic decision in 1996. In a way, I think it's harder to pick technologies today for large projects. It seems like if something isn't new and growing steadily, it's stale and fading fast. What are the tools and frameworks with a long, healthy middle age ahead of them? I'm learning Go right now because there are a couple of web services I need, but I'm not that confident that I'll be able to run the same code for the next 20 years.

dozzie 9y ago
Erlang, for instance? Picking up a new shiny thing and complaining that it's not something with a proven track of backward compatibility is not a rational thing to do.
pjmlp 9y ago
Kind of, OWL and VCL were much better technology but Borland's management...
- criddell 9y ago
  Oh man, I remember those now. You're right - they were better. It reinforces my point about how difficult it is to choose a long-term technology. It feels a little like picking stocks.

marcosdumay 9y ago

> how do you [know] in advance if you got a MFC-like library from MS with 20+ year support vs a library like Sliverlight where they drop support and let you alone with a migration to a different platform ? If it is old, it will be supported for a long time. If it is new, the odds are mostly on it not surviving. Ever wondered why so many people insist on using outdated stuff? You get a better deal from open source. But even there you may not like the possible consequences of using non-mainstream things.

WorldMaker 9y ago

As someone that worked on migrations to Silverlight and then to UWP, I still don't understand why these are seen as such big deals. The APIs were more similar than they were different and XAML is still XAML. (The only big loss from Silverlight was being able to browser-host it, but even then that was probably worth losing for the greater good to avoid terrible plugin websites.) The only thing they really dropped was Silverlight as (an unnecessary) brand name. If they had semvered the whole thing: Avalon => UWP 0.x, WPF => UWP 1.x, Silverlight => UWP 2.x, Windows 8.1 UAP => UWP 3.x, today's UWP ~=> UWP 4.x, I don't think any developer would have blinked, I feel like we'd have a lot fewer people feeling they dropped support for things... Then again, developers like to complain when their cheese is moved, it could be just like Python 2 versus Python 3 or VB6 versus VB7.

maxxxxx 9y ago
You couldn't just port from WPF to Silverlight. They took away tons of features. WinRT was even worse. No idea about UWP but I don't care anymore.
- WorldMaker 9y ago
  That's why I mentioned semver. APIs change all the time, backwards compatibility gets broken. Yes, conversions weren't always straight forward, but often were possible, and there was an evolutionary arc to it all, and a migration story to follow, even when sometimes that story was a bit rougher than anyone wanted.
  - maxxxxx 9y ago
    There was no migration story. Usually an API gets more features but in this case they took away a lot of critical stuff. A lot of us write applications that need the full power of the OS and not just a small arbitrarily chosen subset.
  - fpig 9y ago
    They couldn't have done that because these technologies are not exactly for the same things and don't have the same features. Silverlight was mainly for apps embedded in the browser. It was very limited compared to WPF and not meant to replace it. Similarly, Metro was not meant to replace WPF. It was extremely limited in what you can do. You couldn't build serious desktop apps with that. The fact that all those technologies use XAML does not mean they're newer versions of the same thing. The difference in APIs is not what matters, it's the difference in what they can actually do and how that makes them different.