Hacker News Reader

Comment by xradionut | Hacker News Reader

"A lot of us haven't even gotten far enough to figure that out. Microsoft just switched us all over to a new UI toolkit (Windows Presentation Foundation) with the release of .NET 3 five or so years ago. We've invested a lot of time and money into getting up to speed with this new technology. And now we're already being asked to migrate away from it and onto yet another Next Big Thing."

Bingo! Talked about disrespecting your developers/users by changing the rules of the GUI every couple of years. Only the hardcore fans, pioneers and draftees are jumping into Windows 8. (The rest of us are keeping it locked up in virtual machines.) There's enough work in the Windows development universe, a developer can ignore Metro till it grows up or decent third party tools come out. For f--ks sake, Redmond, I've got real apps, (both web and desktop) to write.

View on HN

I guess a lot of the people here are too young to remember - but it's always been this way with Microsoft, and admittedly, with most other infrastructure companies out there (Sun had an era like that, NetScape did too). MFC, ATL, ADO, DAO, ...; Win8 might be breaking new ground in how "out of place" your app will be if you don't adopt the latest and greatest, but if you wanted nice modern menubars and toolbars ("Coolbar"), you had to switch from Win32 to MFC in the past. You had to go through hoops to get somethings done with COM without using ATL (with quite a few things working through ATL but not if you try to use COM directly; because no one in Microsoft ever tried to use them NOT through ATL).

And for a long time, it made everyone happy - because jumping on the new thing kept you employable, and actually shipping working products mattered less.

Microsoft did not change its ways. The world did.

True most young lads, have this notion that only Microsoft keeps changing the thechnology stack, when actually all companies do the same.

As anyone noticed how many MacOS X APIs have been deprecated since the early days?

Or the API changes in Android?

Every corporation plays this game, as you point out.

I still remember the early COM days, where the only API was C based, and COM was called OLE.

"Or the API changes in Android?" At least Google releases the support library to overcome that

Really?!

That is why you have to import android.support.* versus android.app. Which forces you to have some form of preprocessing in the Java code.

Plus the API for the action bar is still missing from the support library.

The support library allows you to use features of newer system releases on older systems. See also GDI+ for Win98/NT4 or Windows feature packs for example.

The API changing game is another problem - it does not allow you to use existing application with newer system. As far as I know, this does not happen on Android (for now).

There already a few deprecated API, which so far have not be removed, but until when?

Linux/Unix are just like this as well.

Except that the old widget sets never die. Xt, Athena, Motif, Lesstif, Tcl, gtk, Qt. Even swing and related tools if you include Java.

And so ... they're still in use. While significant new apps may not be getting developed with these tools, plenty of old ones are maintained, and the toolkits are largely serviceable -- they may be used if desired.

They actually provide a bit of useful visual feedback (if you're versed in Linux/Unix history), in that the style and design of an application gives you some idea of how it's going to work and what its quirks may be.

Consistency? We've heard of it.

After so much on MFC,OLE,COM/DCOM=>ATL, ADO, DAO, c#,.net,silverlight and now html5, I am not MS fan any more and has zero interest in any MS stuff.

Name one single technology company that does not keep changing the developer tools all the time.

edit: typo

The Linux Foundation, the Apache Project, et cetera.

Those are not commercial vendors.

Still, if you want I can post all the Linux kernel ABI changes.

The changes done in Apache during the 1.x to 2.x transition.

Or many other examples, as they are quite easy to find.

compared to the differences between win32 and WPF those are trivial. Also, the kernel ABI is considered an "internal" ABI, for better or for worse, the kind you wouldn't be able to access without an NDA and signed contract in the commercial world. The kernel's stable interface is its system call interface, which is remarkably stable.

Go tell that to the guys coding device drivers, so now device drivers API are private?!

Nice to bend the reality to fill into your argumentation.

Companies give out NDA's like candy, so that's hardly private.

I've written Linux device drivers. They're easy to write, and API changes are not a concern at all.

> Companies give out NDA's like candy, so that's hardly private.

private as "private/internal API" nothing to do with secret.

> I've written Linux device drivers. They're easy to write, and API changes are not a concern at all.

The whole point is that it changes! So it is ok for Linux to change the Kernel ABI, but for companies not?!

And which one of those doesn't work anymore?

In Metro-style/Windows Store apps? MFC, ATL, ADO, DAO, and Silverlight, large parts of .NET, and COM components not written against the subset of Win32 supported by Metro.

Those kits still do work for the platform they were built for though.

New platform, new kits. Same as any other company.

Reply on news.ycombinator.com