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.

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

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?

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.

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.

Way back in the day I used to be a Microsoft developer. I got tired of them changing the database API every other year. All the open sources platforms are much more stable. Knowledge in these other platforms doesn't decay as quickly or is at least somewhat useful even after 10 years.

In contrast, Microsoft will just go and kill whole platforms from time to time (e.g Visual Basic) rendering useless years of experience building deep understanding of a platform.

I used to be a vb.net developer and I'm glad they killed the language. C# is far more elegant and sophisticated.

Nobody mourns vb.net which is essentially a bastardized C#. Many mourn the original Visual Basic which was killed off by vb.net.

The original VB was a far worse language than VB.net ever was.

A far worse language with enormous hordes of programmers who had bet their careers on it.

"Classic" VB was the PHP of the client/server era: ugly, reasonably capable, and everywhere.

Imagine the screams you would be hearing across the Internet if the PHP core devs all decided en masse to go work on something else, and PHP was under a closed, proprietary license so nobody could fork it, and you get a sense for what it was like when Microsoft killed VB.

To be fair, ODBC is by far the most common DB API.

ODBC, which, along with every other database API released by Microsoft in the past decade, is not supported in Metro. Astonishingly, it currently appears to be easier to query a Microsoft SQL Server from an iOS app than from a Metro-style app. Presumably someone could port ODBC and a driver like FreeTDS to Metro, but it'd be made more difficult by the radically different networking APIs, and would still suffer from annoying limitations like the inability to connect to local database server instances (per Windows Store policy).

Like any other commercial vendor.

I think Microsoft is worse about it that other commercial vendors. Perhaps due to a perception (not necessarily incorrect) on their part that their customers are locked in.

If a vendor who only supplies a single product decides to torpedo the APIs that you rely on, they create an easy opportunity for you to switch to another vendor entirely. Whereas historically Microsoft could wreak havoc upon an entire development platform (Visual Basic) knowing that probably all you'll be able to do about it is huff and puff around a bit on the Internet. After all you couldn't jump ship on Windows development - all your customers were Windows users, or your entire IT department was built around Windows, or your corporate intranet is all dependent on IE6, or whatever.

Funny you say that, because Microsoft's software problems are often attributed to bending over backwards to be backward compatible while other vendors like Apple quickly kills compatibility with almost ever release, with even point releases.

Take this game bundled with Windows 95. ftp://ftp.microsoft.com/deskapps/games/public/AAS/Hover.exe

It runs even on Windows 8. Upgrading from Windows 1.0 to Windows 7.

http://www.youtube.com/watch?v=vPnehDhGa14

As I said in another comment, I still see some ASP and Visual Basic usage even after all these years, those applications are still supported in Windows 8 and Windows Server 2012. Microsoft stopped making new versions because it wanted to move on to better technology. Want to take a poll on HN about what developers think of Visual Basic and Classic ASP? A case of damned if they do, damned if they don't.

Right, but this is largely orthogonal to the problems with Metro on the desktop. Sandboxed Mac App Store apps are limited, but need not be written against an entirely new set of APIs that is not only unsupported by previous versions of the OS, but unsupported by non-App Store apps running on the current OS version. Say what you will about the Mac App Store, it at least doesn't suffer from all the problems inherent in the iOS App Store model. Metro does.

I am sure there are a lot of people who rejoiced at Microsoft "killing" Visual Basic. And I say "killing" because I see a lot of it in use, they just stopped adding new features to it, the old applications written in the early 90s still work in Windows 8. Try that with other OSes or GUI toolkits.

Fire and motion, my friend. Fire and motion: http://www.joelonsoftware.com/articles/fog0000000339.html

Yep. And like in the battlefield, fire and motion works when you already have an advantage, but doesn't when you're in an inferior position (Which Microsoft is right now in the mobile market - and are not as dominant in the desktop[1] market)

[1] by which, I don't mean they are remotely in danger of being dethroned. Just that they can't dictate application standards anymore, because most activity happens on the web.

That article was exactly what I was thinking of while reading this post. Thanks that you posted the link.

Fire and motion refers to your own forward momentum.

Using it to put developers within your own ecosystem off-balance is an antipattern.

Metro is WPF based.

Technically. In reality WinRT is missing A LOT of stuff from WPF (heck WinRT doesn't even reach parity with Silverlight). Simple stuff la x:Static, x:Array are not available.

WinRT 1.0 is basically a subset of Silverlight with a few specific controls thrown in.

> heck WinRT doesn't even reach parity with Silverlight

That reminds me: WPF is not even a superset of Silverlight; There's functionality I need in Silverlight (regarding media codecs) which is not available in WPF, and my only way to get it is to instantiate a browser, run a silverlight app inside, and somehow bridge it all underneath in my app.

Pure madness.

You can use Xaml with WinRT. But beyond that cosmetic similarity, it gets pretty different. WPF is implemented in .NET, whereas WinRT is more of a replacement for Win32.

You can still write WPF apps for Windows 8, of course, but they won't be Metro apps, they won't run on ARM tablets and, significantly for the current conversation, they won't be allowed in the Windows app store.

>Meanwhile, Microsoft zinged its mobile developers (the very ones they're so desperate to court) even harder by deciding that the new mobile platform they brought out only two years ago would not be compatible with the new mobile platform they're bringing out now.

WP7 apps will run on WP8 without any modifications or even without anything needing to be done by the developers.

>Well, it turns out that all those developers he wanted to make such a big deal of saying are such a big deal? They're are all kind of pissed off and disgruntled right now.

Citation needed and content farms like TNW who will "print" anything to drive clicks don't count.

I know it's hip on HN to rag on Microsoft, but cmon, two thousand apps for a platform that is a month away from release(only available to MSDN users right now) and everyone is predicting doomsday? Perhaps developers are making use of the last month to further enhance apps before submitting them?