Development platform going forward?

Then I am an extreme exception to your rule at 51, old man. I can't shake headhunters off fast enough.

Likewise, man. Headhunters see the resume and burn up my phone line. Contract work I could get, but permanent work...they seem to see the hiring cost and pass.

"The platform" is also driven by your clientele. I'd like to recommend Windows 8 apps, and Windows Phone apps...but if your company only has VS2005 and runs Access 2003/SQL 2000, it's kind of hard to make that push to modern application development. To grow takes investments in money and in people.

@evildictaitor:

c) that's due to the OS, isn't it? Those technologies have no hard dependencies on Win32 API, unless I am mistaken.

b) I would not stake my business on that, personally, I believe hard dependencies on OS dlls are obsolete technology, philosophically, and I'd seek remedy if possible -- re: WPF, etc.

a) XAML beats the dog snot out of the UI in Winforms, it is a much better programming model.

My perspective is optimistic. Changes to WPF, Silverlight, WinRT are responses to community demand and technological best practices. Every single iteration of deliverables are welcome here. I will state that most of my own pain working around these type changes were due to poor code designs on my part and not from API modifications. That's my experience with .NET and it is not the same experience I had with other languages.

Ah, you have dirt under the rug... to wit: "as long as tablets aren't important"... ah-hem. Obsolete!

I do appreciate your perspective, but I'm not sharing it.

17 minutes ago, JohnAskew wrote

c) that's due to the OS, isn't it? Those technologies have no hard dependencies on Win32 API, unless I am mistaken.

b) I would not stake my business on that, personally, I believe hard dependencies on OS dlls are obsolete technology, philosophically, and I'd seek remedy if possible -- re: WPF, etc.

It seems like the bulk of RT is tons of metadata glue that wraps around all of the APIs that are needed to provide the RT API set. Whether they be native or managed, the developer doesn't need to know or care. Microsoft can make whatever changes they need to the underlying APIs, up to and including getting rid of Win32, and RT applications wouldn't need to know about it.

a) XAML beats the dog snot out of the UI in Winforms, it is a much better programming model.

QFT

My perspective is optimistic. Changes to WPF, Silverlight, WinRT are responses to community demand and technological best practices. Every single iteration of deliverables are welcome here. I will state that most of my own pain working around these type changes were due to poor code designs on my part and not from API modifications. That's my experience with .NET and it is not the same experience I had with other languages.

I've been optimistic about this process too. I don't see the death of WPF, Silverlight, or any technologies. What I'm seeing is that each iteration has brought them all closer together, and they are finally merging into one cohesive stack. The process is a bit messy, but I don't see any reason somebody would say it isn't necessary.

2 hours ago, evildictait​or wrote

*snip*

A) WinForms is a set of APIs that could be repurposed if the Win32 API changed - see Mono for an example of WinForms that sits on top of fopens etc instead of CreateFiles.

It really can't, or at least not easily and reliably without mimicking a lot of Win32 too. Many of the assumptions in WinForms are inherent to Win32 and the underlying design tend to leak through a lot. Couple that with the fact Microsoft have already declared it dead and I'd try to steer away from it.

Well that, coupled with the fact it's horrendously buggy in places, mostly because the controls are very light wrappers around the Win32 provided controls but with different (and often incompatible) semantics. It's enormously easy, for example, to create a data-bound combo box that corrupts data simply due to the order properties are set on it (and it's really not obvious what the correct way is).

By contrast, WPF keeps itself well clear of Win32 and the fact it happens to be implemented on top of it is largely irrelevant.