M$ - new API's with no new offering in terms of capability and missed out on rise of smartphones
-
How much time you wasted moving from Win32>MFC>WinForm>WPF and now Metro?!? How much time you wasted moving from raw socket>asmx>WCF? And now[^], because our apps needs to look like it runs on a tablet we need to abandon .NET and rewrite on top of WinRT? Way I see it, vendors like Infragistics/DevExpress produces values - we pay for it. M$ has fallen in love with year-on-year API overhaul which leads to nothing. They keep doing this long enuf even loyal M$ developer will jump boat. Who the hell is actually steering M$ development effort and product offering these days?!
dev
devvvy wrote:
How much time you wasted moving from Win32>MFC>WinForm>WPF and now Metro?!?
* Every programmer should know something about Win32. * If you've never done MFC work, so what, you're not missing much, if have done MFC work, most likely in C++, then it's useful to know about * WinForm / .NET is not a wasted move, it's a completely different paradigm from MFC / C++ * WPF - again, a different paradigm - it's a tool in the toolbox * Metro - well, whatever. Microsoft has ideas of what UI's should be, and my clients have ideas on what their UI's should do and look like. Often enough, there is a wide gap between what Microsoft thinks and what my client thinks. But then again, I write software mostly in a custom niche. I don't write apps to be consumed by millions of commuters wanting to forget for 20 minutes the smelly guy they are standing next to on the subway.
devvvy wrote:
How much time you wasted moving from raw socket>asmx>WCF?
Never moved past raw sockets, except for some web service work.
devvvy wrote:
And now[^], because our apps needs to look like it runs on a tablet we need to abandon .NET and rewrite on top of WinRT?
I don't see it as abandoning. Nor did I read the article that way. I saw a nice demo of W8 with WinRT a couple days ago. Looked like C# code, looked like .NET framework stuff, looked like XAML. There were some nuances in the XAML and C# code to support the built-in search feature of the OS, but other than that, it wasn't anything that couldn't be done today. So, I'm not sure what you're complaining about - if you're a dev, then it's par for the course that technologies and paradigms will change. The problem seems to me to be more that you are experiencing a resistance to those changes. Resistance is futile, haha. :) Marc
Reverse Engineering Legacy Applications
How To Think Like a Functional Programmer
My Blog -
How much time you wasted moving from Win32>MFC>WinForm>WPF and now Metro?!? How much time you wasted moving from raw socket>asmx>WCF? And now[^], because our apps needs to look like it runs on a tablet we need to abandon .NET and rewrite on top of WinRT? Way I see it, vendors like Infragistics/DevExpress produces values - we pay for it. M$ has fallen in love with year-on-year API overhaul which leads to nothing. They keep doing this long enuf even loyal M$ developer will jump boat. Who the hell is actually steering M$ development effort and product offering these days?!
dev
After 15 years of MS development. I no longer follow Microsoft APIs. I have moved to 100% Qt development. That is except for web server development (which is not a large part of my software development) where I now use ASP.NET.
John
-
Am I missing something here? but aren't the Metro (Windows Store Apps built using visual studio 2012, that is built around the 4.5 framework? the only difference that I can see is that you use the WinRT libraries rather than the Win32 API for direct calls to the operating system.
Lobster Thermidor aux crevettes with a Mornay sauce, served in a Provençale manner with shallots and aubergines, garnished with truffle pate, brandy and a fried egg on top and Spam - Monty Python Spam Sketch
-
devvvy wrote:
How much time you wasted moving from Win32>MFC>WinForm>WPF and now Metro?!?
* Every programmer should know something about Win32. * If you've never done MFC work, so what, you're not missing much, if have done MFC work, most likely in C++, then it's useful to know about * WinForm / .NET is not a wasted move, it's a completely different paradigm from MFC / C++ * WPF - again, a different paradigm - it's a tool in the toolbox * Metro - well, whatever. Microsoft has ideas of what UI's should be, and my clients have ideas on what their UI's should do and look like. Often enough, there is a wide gap between what Microsoft thinks and what my client thinks. But then again, I write software mostly in a custom niche. I don't write apps to be consumed by millions of commuters wanting to forget for 20 minutes the smelly guy they are standing next to on the subway.
devvvy wrote:
How much time you wasted moving from raw socket>asmx>WCF?
Never moved past raw sockets, except for some web service work.
devvvy wrote:
And now[^], because our apps needs to look like it runs on a tablet we need to abandon .NET and rewrite on top of WinRT?
I don't see it as abandoning. Nor did I read the article that way. I saw a nice demo of W8 with WinRT a couple days ago. Looked like C# code, looked like .NET framework stuff, looked like XAML. There were some nuances in the XAML and C# code to support the built-in search feature of the OS, but other than that, it wasn't anything that couldn't be done today. So, I'm not sure what you're complaining about - if you're a dev, then it's par for the course that technologies and paradigms will change. The problem seems to me to be more that you are experiencing a resistance to those changes. Resistance is futile, haha. :) Marc
Reverse Engineering Legacy Applications
How To Think Like a Functional Programmer
My BlogParadigm shift (and API overhaul) is fine - if it actually comes with real addition to "Platform Capability" It's a complete waste of time otherwise, why different/multiple tools for the same jobs? (WPF/Winform/MFC) - i can see Win32 to Winform a great leap forward that it simply UI development *SIGNIFICANTLY*. Same cannot be said for Winform to WPF migration. Paradigm Shift seems to suggest there's really nothing on the table.
dev
-
Same here. Ever since Vista we had nothing else than trial and error and I'm tired of wasting my time trying to keep up with this.
-
How much time you wasted moving from Win32>MFC>WinForm>WPF and now Metro?!? How much time you wasted moving from raw socket>asmx>WCF? And now[^], because our apps needs to look like it runs on a tablet we need to abandon .NET and rewrite on top of WinRT? Way I see it, vendors like Infragistics/DevExpress produces values - we pay for it. M$ has fallen in love with year-on-year API overhaul which leads to nothing. They keep doing this long enuf even loyal M$ developer will jump boat. Who the hell is actually steering M$ development effort and product offering these days?!
dev
devvvy wrote:
How much time you wasted moving from Win32>MFC>WinForm>WPF and now Metro?!?
None. Still doing WinForms, which is just a neat layer around Win32.
devvvy wrote:
They keep doing this long enuf even loyal M$ developer will jump boat. Who the hell is actually steering M$ development effort and product offering these days?!
..the old things did not go away, have you noticed it? WinForms is still available, and with all the software that people wrote, I imagine Microsoft supporting it for quite some time to come. Not everyone is using the latest gradients, opacity-effects and animations; in return, it's compatible with Mono. And no, asmx did not replace the raw socket.
Bastard Programmer from Hell :suss: if you can't read my code, try converting it here[^]
-
How much time you wasted moving from Win32>MFC>WinForm>WPF and now Metro?!? How much time you wasted moving from raw socket>asmx>WCF? And now[^], because our apps needs to look like it runs on a tablet we need to abandon .NET and rewrite on top of WinRT? Way I see it, vendors like Infragistics/DevExpress produces values - we pay for it. M$ has fallen in love with year-on-year API overhaul which leads to nothing. They keep doing this long enuf even loyal M$ developer will jump boat. Who the hell is actually steering M$ development effort and product offering these days?!
dev
I was at a Microsoft Visual Studio event yesterday and asked about the relationship between the WinRT and .NET Framework. The answer I got was that a lot of the .NET Framework was pushed down into the RT OS, and that, depending on what you were doing, you might not notice much of a difference. Clearly, though, UI will need to be rewritten. Of course, writing to WinRT is only required when you're targeting WinRT tablets. The big question for me is whether enough people will do that for the WinRT ecosystem to take off. 4k applications in Windows store is not much, especially since (per an article I read) most of them are junk and things will have to change before WinRT and Windows tablets take off.
Tom Clement Serena Software, Inc. www.serena.com articles[^]
-
Paradigm shift (and API overhaul) is fine - if it actually comes with real addition to "Platform Capability" It's a complete waste of time otherwise, why different/multiple tools for the same jobs? (WPF/Winform/MFC) - i can see Win32 to Winform a great leap forward that it simply UI development *SIGNIFICANTLY*. Same cannot be said for Winform to WPF migration. Paradigm Shift seems to suggest there's really nothing on the table.
dev
devvvy wrote:
Same cannot be said for Winform to WPF migration
Really? Raster vs. vector graphics? Because it's vector graphics based, the ability to zoom/expand a surface handled entirely by the hardware? A declarative format vs code? A declarative format that is at least somewhat consistent between desktop, Silverlight, and tablet development? The ability to easily wire up binding and converters between backing data and UI elements? These were just some of the useful things about WPF. I find it ironic that I'm even defending WPF, given that I don't even use it. But the things I've seen are impressive and significantly different from standard WinForm development. The whole reason I put together MyXaml was because I could immediately see the benefits of a declarative approach to UI development. Marc
Reverse Engineering Legacy Applications
How To Think Like a Functional Programmer
My Blog
Computational Types in C# and F# -
I was at a Microsoft Visual Studio event yesterday and asked about the relationship between the WinRT and .NET Framework. The answer I got was that a lot of the .NET Framework was pushed down into the RT OS, and that, depending on what you were doing, you might not notice much of a difference. Clearly, though, UI will need to be rewritten. Of course, writing to WinRT is only required when you're targeting WinRT tablets. The big question for me is whether enough people will do that for the WinRT ecosystem to take off. 4k applications in Windows store is not much, especially since (per an article I read) most of them are junk and things will have to change before WinRT and Windows tablets take off.
Tom Clement Serena Software, Inc. www.serena.com articles[^]
I at a Microsoft Visual Studio event yesterday and asked about the relationship between the WinRT and .NET Framework. The answer I got was that a lot of the .NET Framework was pushed down into the RT OS, and that, depending on what you were doing, you might not notice much of a difference. Really!?! That sounds musical. But remmeber Silverlight not support System.Collections (it requires that all collections be generic) - would there be similar deal breaker?! Clearly, though, UI will need to be rewritten. From here, WPF/Winform and other "Desktop Apps" should still run on Windows 8[^] - UI will not be rewritten unless you want to put it in Windows App Store. Am I mistaken?!
dev
-
that's a simple decision - Android represents 50% market share on smartphones/tablet and all tabloid enabled devices
dev
But what do your customers want? That's what you need to find out - and simple figures won't tell you that.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier
-
devvvy wrote:
Same cannot be said for Winform to WPF migration
Really? Raster vs. vector graphics? Because it's vector graphics based, the ability to zoom/expand a surface handled entirely by the hardware? A declarative format vs code? A declarative format that is at least somewhat consistent between desktop, Silverlight, and tablet development? The ability to easily wire up binding and converters between backing data and UI elements? These were just some of the useful things about WPF. I find it ironic that I'm even defending WPF, given that I don't even use it. But the things I've seen are impressive and significantly different from standard WinForm development. The whole reason I put together MyXaml was because I could immediately see the benefits of a declarative approach to UI development. Marc
Reverse Engineering Legacy Applications
How To Think Like a Functional Programmer
My Blog
Computational Types in C# and F#sorry Marc, I do appreciate ability to code up UI declaratively, I do think it's cool. This said, you can start coding Winform with almost zero learning curve. No data triggers, no data binding expressions, no dependency properties ... etc. With Winform, you just start coding on day-one! The ability for developers to focus on the issue at hand (for me, derivative risk/trading apps) carries a much higher level of precedence than yet another "Paradigm Shift".
dev
-
But what do your customers want? That's what you need to find out - and simple figures won't tell you that.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier
-
How much time you wasted moving from Win32>MFC>WinForm>WPF and now Metro?!? How much time you wasted moving from raw socket>asmx>WCF? And now[^], because our apps needs to look like it runs on a tablet we need to abandon .NET and rewrite on top of WinRT? Way I see it, vendors like Infragistics/DevExpress produces values - we pay for it. M$ has fallen in love with year-on-year API overhaul which leads to nothing. They keep doing this long enuf even loyal M$ developer will jump boat. Who the hell is actually steering M$ development effort and product offering these days?!
dev
-
sorry Marc, I do appreciate ability to code up UI declaratively, I do think it's cool. This said, you can start coding Winform with almost zero learning curve. No data triggers, no data binding expressions, no dependency properties ... etc. With Winform, you just start coding on day-one! The ability for developers to focus on the issue at hand (for me, derivative risk/trading apps) carries a much higher level of precedence than yet another "Paradigm Shift".
dev
So you're not saying that the shift to WPF wasn't major, just that the shift wasn't worth the higher learning curve? I imagine that depends on the developer. WPF is insanely powerful, and I wouldn't even imagine doing in Windows Forms the things you can do in WPF (such as this, which includes a tab control with some of the tabs containing expanders that have other controls).
-
So you're not saying that the shift to WPF wasn't major, just that the shift wasn't worth the higher learning curve? I imagine that depends on the developer. WPF is insanely powerful, and I wouldn't even imagine doing in Windows Forms the things you can do in WPF (such as this, which includes a tab control with some of the tabs containing expanders that have other controls).
-
All those technologies you listed still work. I use WinForms and raw sockets for the most part because they do what I want. If you have to move then ask questions of the people that mandate that.
-
sorry Marc, I do appreciate ability to code up UI declaratively, I do think it's cool. This said, you can start coding Winform with almost zero learning curve. No data triggers, no data binding expressions, no dependency properties ... etc. With Winform, you just start coding on day-one! The ability for developers to focus on the issue at hand (for me, derivative risk/trading apps) carries a much higher level of precedence than yet another "Paradigm Shift".
dev
devvvy wrote:
you can start coding Winform with almost zero learning curve. No data triggers, no data binding expressions, no dependency properties ... etc. With Winform, you just start coding on day-one!
Well, that's a good point - one of the reasons I haven't dived into WPF is because of the learning curve and the lack of needing to learn WPF. I would have to say though, that to do anything useful in WinForms, one has to learn about data triggers, binding, properties, etc., and so ultimately has a learning curve associated with it. Personally, some of the syntax in WPF is just bizarre, which has been an obstacle to my learning it. I've done similar things with backing classes in MyXaml, and it seems a lot more intuitive, but ultimately, it's just a syntactical difference.
devvvy wrote:
The ability for developers to focus on the issue at hand (for me, derivative risk/trading apps) carries a much higher level of precedence than yet another "Paradigm Shift".
I do hear that. A new framework / API / OS / UI presentation definitely can get in the way of "the issue at hand". I got pretty screwed many years ago when Borland made a huge change to their OWL framework, then again when I moved to MFC, waking up to the realization that my code was entangled with framework dependencies. Personally, nowadays I tend to wrap frameworks in my own API calls to get some measure of independence (and it also allows some flexibility in, for example, working with Oracle vs. SQL Server), and I definitely try to ensure a clean separation between the UI and everything else, because as you point out, the UI keeps changing! Anyways, I ramble... Marc
Reverse Engineering Legacy Applications
How To Think Like a Functional Programmer
My Blog
Computational Types in C# and F# -
devvvy wrote:
you can start coding Winform with almost zero learning curve. No data triggers, no data binding expressions, no dependency properties ... etc. With Winform, you just start coding on day-one!
Well, that's a good point - one of the reasons I haven't dived into WPF is because of the learning curve and the lack of needing to learn WPF. I would have to say though, that to do anything useful in WinForms, one has to learn about data triggers, binding, properties, etc., and so ultimately has a learning curve associated with it. Personally, some of the syntax in WPF is just bizarre, which has been an obstacle to my learning it. I've done similar things with backing classes in MyXaml, and it seems a lot more intuitive, but ultimately, it's just a syntactical difference.
devvvy wrote:
The ability for developers to focus on the issue at hand (for me, derivative risk/trading apps) carries a much higher level of precedence than yet another "Paradigm Shift".
I do hear that. A new framework / API / OS / UI presentation definitely can get in the way of "the issue at hand". I got pretty screwed many years ago when Borland made a huge change to their OWL framework, then again when I moved to MFC, waking up to the realization that my code was entangled with framework dependencies. Personally, nowadays I tend to wrap frameworks in my own API calls to get some measure of independence (and it also allows some flexibility in, for example, working with Oracle vs. SQL Server), and I definitely try to ensure a clean separation between the UI and everything else, because as you point out, the UI keeps changing! Anyways, I ramble... Marc
Reverse Engineering Legacy Applications
How To Think Like a Functional Programmer
My Blog
Computational Types in C# and F# -
So you're not saying that the shift to WPF wasn't major, just that the shift wasn't worth the higher learning curve? I imagine that depends on the developer. WPF is insanely powerful, and I wouldn't even imagine doing in Windows Forms the things you can do in WPF (such as this, which includes a tab control with some of the tabs containing expanders that have other controls).
sorry, but your link really scared me :~ but you are right saying that WPF enables things that were impossibly before, and I even learned it quickly than i learned Windows Forms... :-O
I'm brazilian and english (well, human languages in general) aren't my best skill, so, sorry by my english. (if you want we can speak in C# or VB.Net =p)
-
sorry, but your link really scared me :~ but you are right saying that WPF enables things that were impossibly before, and I even learned it quickly than i learned Windows Forms... :-O
I'm brazilian and english (well, human languages in general) aren't my best skill, so, sorry by my english. (if you want we can speak in C# or VB.Net =p)