Hacker News Reader

Comment by xradionut | Hacker News Reader

When you work with the Microsoft stack, except for a few core technologies, you have no idea if the "hot" API or current solution Redmond is pushing will be supported or abandoned in a couple of years. Combine that with stapling Metro, a tablet/phone API to the side of the desktop in Windows 8, many developers I know are tired of being thrashed and burned.

As a developer/analyst/admin that works primary in the MS application/data realms, I'm bummed out that MS can't communicate with developers and seems very disfunctional vision-wise. But as someone who also uses OSS software and OSS OSes, I'm not tied to their whims. Neither are a growing number of my clients...

View on HN

This is in Microsoft's DNA. The more you're re-writing your apps "because everyone will have feature X of platform Y" the more you're not writing web apps that will ultimately make their platform irrelevant.

By iterating on non-compatible releases, you're forced to run on the upgrade/rewrite hamster wheel to take advantage of that feature the last version didn't quite have but should've.

Joel Spolsky coined it "fire and motion" http://www.joelonsoftware.com/articles/fog0000000339.html

"Think of the history of data access strategies to come out of Microsoft. ODBC, RDO, DAO, ADO, OLEDB, now ADO.NET - All New! Are these technological imperatives? The result of an incompetent design group that needs to reinvent data access every goddamn year? (That's probably it, actually.) But the end result is just cover fire. The competition has no choice but to spend all their time porting and keeping up, time that they can't spend writing new features"

Now they are heading back to making ODBC the primary data access API... Sigh...

What are your alternatives? OSX, where Apple has no qualms about abandoning technology, hardware or software, within a matter of years (the iPad 1 was EOL'ed just shy of two years old, I believe).

XCode and (Snow) Leopard? No such luck.

Now, you do mention the Linux alternatives, which seem to be the most stable... if you can get around any infighting of QT... Gnome/KDE... etc et al.

But it doesn't seem particularly "fair" to imply that this is something of a risk when you choose Microsoft.

The Apple situation's slightly more complex than that: they're certainly ruthless with their hardware, but it's a bit of a stretch to claim they have commitment issues with their software technologies - ObjC, Foundation and AppKit's been around since the late 1980s from NeXT without serious architectural changes; UIKit'll be around for a while yet; let nothing come between them and their investment in the Apple Compiler Group. (The upshot is that they've sufficiently abstracted hardware away anyway, so hardware changes aren't showstoppers.) If anything, they're more conservative with tossing out the SDKs than most: OpenGL support, for example, is still absurdly piss-poor, even if they're getting better with their GPU driver support. But it does net you compatibility all the way down their HCL - at the bottom end, for example, is the mid-'07 iMac with the ATi 2600 PRO.

They do give not-so-subtle hints to hand over to them the cha-ching, though, when they EOL old versions of XCode - but that's usually the most you're going to encounter. So works Apple in general.

> The Apple situation's slightly more complex than that: they're certainly ruthless with their hardware, but it's a bit of a stretch to claim they have commitment issues with their software technologies - ObjC, Foundation and AppKit's been around since the late 1980s from NeXT without serious architectural changes

And if you happened to bet on those technologies instead of Carbon, you're probably very happy with that. Well, unless you were writing Cocoa apps with Java, which was pushed as a peer to Objective-C in much the same way that Carbon was presented as a peer to Foundation and AppKit. Those technologies all got killed pretty viciously, even though Apple at various points actually seemed to be promoting them over Objective-C/Cocoa.

Apple axes stuff faster than Microsoft is even capable of moving. Looking directly back from their current technology stack, it looks like mostly smooth sailing, but that's because you're not looking at the wreckage to the left and right.

(Bonus points: Remember when Apple were all about Garbage-Collected Objective-C until they weren't and suddenly ARC was the new hotness?)

    XCode and (Snow) Leopard? No such luck.

You can compile for Leopard and Snow Leopard by dragging the appropriate SDKs into /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/

But you can't run Xcode on Snow Leopard any more (well, the current version). Admittedly not as much of an issue, as it seems Mountain Lion solves at least some of Lion's pain points.

Apple obsoletes older technology, but it doesn't introduce dozens of redundant technologies only to drop them. There's a difference between keeping up with a linear path of progress and jumping from API to API without any clue as to which one is the "right" one.

For example?

What are you wanting an example of?

I think Apple's foundational technologies have been fantastically stable since OS X came along. It's been pretty much the same solid core since 2001, from OS X 10.1 through iOS 6.

The only major piece to go away was Carbon, which was pretty much just for OS 9 backwards compatibility to begin with.

I use many of the same classes and techniques in iOS today that I did in the very beginning of learning OS X programming.

> What are your alternatives?

Option 1. Use a third-party abstraction library to make the same code work on every platform. Unity [1] is a popular commercial solution. FOSS solutions include jMonkeyEngine [2] (oriented toward PC games) and libgdx (with a focus on mobile) [3].

Option 2. Instead of writing for Windows, write for Wine. If your program runs in Wine, it should run in Windows (the reverse, alas, is not necessarily true). And you also get support for any platform Wine runs on, including not just Linux, but apparently Intel Mac [4].

[1] http://en.wikipedia.org/wiki/Unity_(game_engine)

[2] http://en.wikipedia.org/wiki/JMonkeyEngine

[3] http://libgdx.badlogicgames.com/

[4] http://wiki.winehq.org/MacOSX

What do you mean by "abandoned"? Isn't pretty much everything Microsoft releases supported on its original platform for at least 10 years? With OSS software and OSes, do you get better support guarantees?

Thats a bonus for existing applications, but not when choosing a technology for a new one. If your technology gets shelved, you won't be able to grow with underlying framework. Now new interesting stuff for you, except if you rebuild.

Apple for example takes a different route: they have shorter support spans, but rarely invalidate whole technology stacks. Cocoa is still alive and kicking after all those years.

What "whole technology stack" has Microsoft invalidated?

How is Cocoa still alive and kicking? How is that different from something like VB6?

Silverlight? You would never start a new project in it nowadays, would you?

Cocoa on the other hand is still the foundation of almost all OS X and iOS programs.

The iPad killed Silverlight, not Microsoft.

I have no problem targeting Silverlight because Silverlight is not the "stack" in that case. XAML and .NET are, both of which are viable for the foreseeable future. Any other examples?

Since being renamed from OpenStep, Cocoa has gotten hardware-accelerated graphics, two new (one since-deprecated) semi-automatic memory management schemes, 64-bit support, a hardware-accelerated animation system, a new fine-grained security model, closure-based concurrency, and cloud storage support. And yet it's still largely compatible with and recognizable as the framework with which the first web browser was built. And it's still a first-class citizen that Apple uses to write their own apps - it's not just being kept around in maintenance mode.

Silverlight, MFC, ATL, Active Server Pages (pre-ASP.NET), MSN Messenger, Windows 7 desktop gadgets, Windows Phone 7, Windows 8 RT (wait, I got ahead of myself - give it a few more months).

WebObjects, Java Bindings, Garbage Collector, Quicktime 2/3D, Java Quicktime API, AudioDeviceIO, Carbon....

> Apple for example takes a different route: they have shorter support spans, but rarely invalidate whole technology stacks.

Carbon programmers beg to differ.

(Full disclosure: I was always a Cocoa guy, so this isn't sour grapes. But if you were paying attention to the OS X development scene as a whole, it was really shocking how fast Carbon went from being more actively developed and having support for more things than Cocoa to being thrown straight into the dumpster.)

> When you work with the Microsoft stack, except for a few core technologies, you have no idea if the "hot" API or current solution Redmond is pushing will be supported or abandoned in a couple of years.

The situation is no different for other software vendors.

That is how commercial software works.

Reply on news.ycombinator.com