Hacker News Reader

Comment by sergiotapia | Hacker News Reader

I used to smirk at people who claimed Microsoft constantly did this but I now see the light.

First silverlight, now this.

Why should I invest in the Microsoft stack? I'm done. Microsoft is no longer a platform I will work on and I will recommend open source products and frameworks from now on.

Can you imagine spending 5 years learning XNA and becomming a guru, only to have them yank the rug from under you?

Oh you have experience in XNA? You might as well have experience in Visual Foxpro.

F-U Microsoft - from thousands of XNA devs worldwide (including myself)

View on HN

I don't understand why people complain about Microsoft killing Silverlight because Silverlight wasn't killed by Microsoft, it was killed by a changing market. And it doesn't make sense for a company like Microsoft to continue to push a platform that nobody wants or uses. However, Microsoft didn't abandon the software developers who used Silverlight. The languages, techniques and tools that are used to work on Silverlight are the same languages, techniques, and tools that are used to create Windows 8 and Phone apps. If anything, Microsoft gave the developers of a doomed platform an easy transition path to a new one.

But yes, it sucks about XNA. But MonoGame has you covered.

it was a catch-up attempt at flash in the first place - they were very late to the game. i know people will say this is hindsight, but... silverlight wasn't around until 2007, and by 2009, when MS started pushing it hard, it was pretty apparent that flash/richui toolkits were on the way out.

silverlight shouldn't have been something they bothered with in the first place.

I have thought for a while Microsoft would have been smart to latch on to Google's Native Client. .NET was something they did reluctantly to combat Java in the enterprise space: Their heart and soul has always been in native code (if you don't count the p-code in Office). And .NET has always produced native code out the back, anyway.

NaCl in Internet Explorer and later in mobile devices would have let them leverage much of their existing code base and developer tools, all with an "industry standard" imprimatur from Google. And where it wasn't supported (i.e., Firefox), you ship a plugin, which is no worse than Silverlight.

I think the risk then would have been to have it branded by others as "New Active X" and all the bad publicity associated with such a moniker.

But it is a matter of hindsight. Microsoft was indeed very late to the game with Silverlight, but back then nobody knew that Flash was on it's way out. We knew that we hated full Flash websites but that's about it. Take a look at the following timeline.

2005 - Youtube was created. Adobe purchases Macromedia.

2006 - Kongregate was released. (Semi random example of a popular Flash gaming website.)

2007 - Microsoft releases Silverlight. Netflix starts streaming video online.

2008 - Hulu launches publicly

2010 - Apple releases the iPad, pushing Flash to the side. (Yes, the iPad was released just 3 years ago.)

And if we take into account the fact that Silverlight wasn't built in a day we could probably say that Microsoft started working on Silverlight before Youtube was born, during Flash's heyday, before HTML5 video was even an option, and half a decade before mobile devices started making Flash obsolete.

And let's not forget the fact that Silverlight is an extension of .NET and as a result it was a great competitor to technologies like Java Web Start.

Silverlight was dead on arrival because of the market penetration of Flash and it was killed a little later by tablets and by HTML5 and JS. But back then, for a short period of time, Silverlight made all of the sense in the world.

While I agree with your main point that the eventual failure of the browser plugin model wasn't as obvious in 2007 as it is now, I could pick different dates and show the opposite.

The video tag was invented in 2007, the same year the iPhone was released. Android followed in 2008, and it was becoming clear that the mobile web wouldn't play well with browser plugins. At the time, there was also a general trend to move away from proprietary standards (ODF was standardized in 2007), and it was obvious from the very beginning that Silverlight would be a closed-source, hard-to-reimplement, patented, Microsoft-supported-platforms-only thing.

In the end, it probably boiled down to developers not wanting Microsoft to gain control of the web ever again.

"a great competitor to technologies like Java Web Start."

Java Web Start was never widely adopted - trying to come up with a 'competitor' to that was stupid. Not even in hindsight - that was a stupid reason in 2007.

MS should be defining the future, not playing catch-up to out of date software. Their continued failure to do so is contributing to their decline in relevance.

"MonoGame has you covered"

I don't really know if I agree with this. It's just about the worst-documented thing I've ever worked with. Their example code for porting things to MacOS doesn't even work. It's a major headache for anything but iOS/Android.

I'd rather use Unity.

Not defending Microsoft, but the same thing has happened many other places:

  * Adobe Flex and Adobe Flash
  * Mac OS X Carbon
  * Symbian
  * JavaFX and Java Applets
  * etc.

Just to shed some light on this. Carbon to Cocoa was a nice transition. Not as bad as how Microsoft has handled it. I got in when it was still supported, but obsolete.

Several of these had a good long life before they went out to pasture. Not so of XNA.

Nobody is suggesting Microsoft is the only company that deprecates and drops development technologies.

But Microsoft is a chronic, habitual offender. It's a point of routine at MS rather than an occasional occurrence.

When they're not innovating, it's a problem. When they're throwing things against the wall to see what sticks, it's a problem too. I feel like they really can't win here. Is XNA really that far off from other Microsoft platforms anyway?

It's not. You can transition to DirectX in a couple of weekends. You can transition to OpenGL (which I would call a better move) in a week or two.

The principles are all the same, everywhere you go. The names change and the exact implementation details differ, but it's the same stuff with a different hat.

> When they're not innovating, it's a problem. When they're throwing things against the wall to see what sticks, it's a problem too. I feel like they really can't win here.

There's perhaps some truth to that, but they could handle things so much better.

Some of these technologies should perhaps be in perpetual beta or something, until they decide they're going to support it long-term. The problem is that Microsoft flogs them as the blessed platform, puts out the rallying cry for all developers to come running and use this cool new thing, and then drops them like a bad habit.

There are always winners, losers and progress. It's fair to be skeptical about MS's future but it's only habitual because they've been at it 3 decades.

" Microsoft is a chronic, habitual offender"

I actually can't think of a case as bad as Apple axing the Xserve line and telling people to use mac minis and mac pros in a rack.

Much worse: LINQ to SQL.

Long story short: Microsoft realized that Entity Framework was taking longer than expected. But they really wanted an ORM to ship with LINQ. So they took a smaller mini-ORM project that was really written for testing LINQ and was never intended for production, hastily dressed it up, and pushed it onto the market as a stopgap. Entity Framework was still happening, mind you - Microsoft never actually planned to support LINQ to SQL long-term.

But they never really mentioned that was their plan. So a great many developers had already written data access layers based on it by the time Microsoft announced they were going to stop supporting it approximately 11 months after it was initially released.

Carbon isn't really a fair comparison. It was always clear that it was merely a transitional API and that Cocoa was the future.

No it wasn't. For a while it was up in the air which API set would become the dominant platform.

Here's Steve introducing Mac OS X for the first time, describing running applications against Classic, Carbon, and Cocoa:

http://www.youtube.com/watch?v=Ko4V3G4NqII&feature=playe...

It certainly seems clear to me (and seemed just as clear to me at the time) that Cocoa was being presented as the API of the future. Sure, Carbon is on the same slide, but so is Classic!

I could see them downplaying it early on - wasn't it the case that they only reluctantly introduced it in the first place? i.e. Rhapsody was originally envisioned with just the NeXT stuff, and it wasn't until they heard from developers that they decided to make some subset portable to the new environment.

I also seem to recall (though I'm not an expert and I certainly don't have inside knowledge) that in those first few releases both Cocoa and Carbon were evolving, sometimes at different rates in different areas. Then I remember when Core Foundation and similar C-only APIs became a thing that people talked about, which as an onlooker of the platform kind of confused me at the time - was it an admission of some inadequacy of objc?

Exactly. As I have heard it, they originally tried to sell their big developers (e.g. Adobe) on total rewrites for Rhapsody/NS/Cocoa and were more or less laughed out of the room. Carbon was a compromise.

I don't think the evolution of C vs ObjC APIs was a good proxy for the future viability of Carbon vs. Cocoa. If an API was intended for Carbon apps, it had to be C. If it was exposing core OS services already implemented in C, it was more likely to be C. Even fairly new APIs like Grand Central Dispatch have both C- and ObjC-intefaced components, based on the level of abstraction.

Yeah, developers like to bash Microsoft for this behaviour, but all commercial companies do the same.

I have been experiencing this since the mid 80's from all kinds of vendors.

Surely people older than me even have similar experiences from before.

Carbon was a stopgap measure for two big companies (Microsoft and Adobe). It was very clear from Apple's actions with other technologies these companies didn't use (e.g. OpenDoc) and its messaging to developers that Carbon was not a permanent solution. Why people were surprise in the 64-bit conversion to see Carbon absent was beyond me.

Now, Apple has a whole hoard of technologies that Adobe and Microsoft didn't use that did not make the jump from OS 9.0 to OS X. OpenDoc is most famous for the youtube video where the angry developer questioned Steve Jobs. I suppose you could add Newton OS to that list, but it is more the closing of a whole platform.

In more modern times, if you started using GC, then you had to convert to ARC pretty soon thereafter.

The issue, as I see it, is that many developers in the Microsoft ecosystem consider Microsoft to be a trusted benefactor and are detached from the realities around software engineering today. Such developers often won't touch concepts and implementations which have been proven outside of Microsoft until they get the blessing from Redmond with a Microsoft-built implementation.

The net result is that for at least a decade or more, many Microsoft developers have lost the independent judgement needed to filter solid technologies from the over-hyped ones.

The truth is, Microsoft is a business like every other. And they have changed with the times in that they experiment a little more and admit failures a little sooner. The challenge for Microsoft is that they are still viewed as the "safe bet" by many in their own community and they have to reconcile this reputation among their base with their own ability to evolve.

I suspect that a deeper issue here is that Microsoft developers believe that Microsoft is as permanent as things get in software, and by extension that everything Microsoft releases will last forever.

Realistically, most EOL'd Microsoft development platforms had been in their period of being officially supported for no less time than it takes an open source platform to go from being the hot new thing to something that's barely worth mentioning on your resume anymore. And Microsoft still offers a lot of continuity - XNA and Silverlight may be dead and WPF might be on the way out. But those C# skills you learn on the old platforms are still usable all over the place, including in Unity (for game developers) and with Xamarin (for mobile). And those XAML skills will still hopefully be useful with WinRT. By contrast, it'll probably be a much bigger deal to switch platforms when Ruby finally becomes passe. For one, it'll take learning a whole new programming language.

Before I get jumped on, I should hasten to say that my intent isn't to criticize any open source for anything. It's to criticize the Microsoft community for developing an attitude of complacency and perhaps even entitlement.

Adobe Flex and Flash are far from dead and getting better and better. There have been quite a few new developments lately, like a brand new ActionScript compiler or the insanely cool Adobe Scout profiler (http://vimeo.com/54808142), new releases of Flash player with version 11.6 in beta right now. Visit http://flashdaily.net/ to find out how "dead" Flash is right now.

Also, JavaFX Script is dead, but JavaFX the library is doing quite well (http://www.oracle.com/technetwork/java/javafx/overview/faq-1...).

Well, they killed off the non-Chrome Linux flash player, and then they completely killed off Linux AIR support out of nowhere (too bad if you bought into the whole cross development AIR platform, have fun porting your mxml to a different language and framework!), and just recently they even killed off development of "Flash Player 'Next'". They also decided to require license keys per deployment to unlock the client player if you were using stage3d and the alchemy compiler in a single app (and then they changed their minds again just a few months later).

So building products and applications on the flash player these days is quite the gamble.

>So building products and applications on the flash player these days is quite the gamble.

It's not that much of a gamble as long as W3C and HTML/JS are still around.

Same trouble here and I'm getting pissed off with it.

We got fucked by Windows Workflow and Silverlight, both of which were canned. The former was rewritten completely but didn't support our use cases any more.

The main thing for me is that I have to relearn every damn API every 6 months to keep up.

Not for nothing but Windows Workflow was always a go nowhere tech, to be honest. The best thing is to have a good foundation in fundamentals and don't get so bogged down in API. If a tech has an extremely complicated API and it is not doing something specialized like control a space shuttle then it might be best to look elsewhere. Anyway, I just feel like Windows Workflow was something only the most Microsoft infused government programming firm could love.

Workflow is one of those great examples of Microsoft building and ditching platforms/technologies. They've gone through almost as many cycles there as they have with data access technologies.

It's actually pretty nice.

We have some cool stuff deployed with it (long term service correlation, long running background processes, custom workflows for business processes), but you are right about it being complicated. We're in the financial sector so workflow and process management is king to us.

The API is there for us to not have to do all the legwork. Do you know how complicated it is to produce a workflow engine and do you know how many companies have their own half broken workflow engines?

Just curious how you got fucked by Workflow Foundation? We use it in our app. We haven't moved to .NET 4.5 yet, so not sure if this some looming issue not on out radar, or perhaps you used it in a specific way no longer supported?

We built a massive state machine based workflow in WF3. It has limped along until .Net 4.0, but we've hit a brick wall now as they have killed the following assemblies in .Net 4.5 (all legacy WF3/3.5 assemblies basically):

    System.Workflow.Activities.dll
    System.Workflow.ComponentModel.dll
    System.Workflow.Runtime.dll
    System.WorkflowServices.dll
    Microsoft.Workflow.DebugController.dll
    Microsoft.Workflow.Compiler.exe
    Wfc.exe

Our 4.5 upgrade prospects are going to be problematic I think as we've got to port everything to the WF4 process model and runtime before we can drag everything up.

I've heard a lot of poeple say "just leave it as 4.0", but we've been there since day one with .Net 1.0 and I'll tell you it's not fun being on the support trailing edge when you have to do a massive port.

To be fair you are not immune from this by using OS projects.

I have made extensive use of projects in the past that have had active repos and mailing lists only to have them slowly turn into a ghost town because one of the major maintainers stopped working on it and nobody else stepped in.

At least you can fork it internally though and support it if need be. The same is not the case with something like XNA which is so tied into the OS that when they drop it, you're up shit creek.

True, thought it is important to be realistic about your ability in terms of time/skills to do so.

For OSS I like for one of three things. Either "too big to fail" (i.e Linux , Rails). Interchangeability , i.e something built on top of an open protocol like an SMTP server. Or something with < ~10KLOC in language I am familiar enough with that I would feel comfortable folding the entire thing into the codebase as a whitebox.

pretoriusB, you appear to be hellbanned. Not quite sure why - I don't see anything offensive in your comment history.

Quite a few of his comments have a slightly antagonistic tone but I don't see anything in his recent history that would obviously justify a hellban.

> The same is not the case with something like XNA which is so tied into the OS that when they drop it, you're up shit creek.

While you can't fork XNA and support it, it's not even remotely tied to the OS. It's a content pipeline and a thin wrapper around DirectX's various components. There's really nothing magical there, and certainly no low-level pieces.

Try shipping it with your product in about 5 years...

Uh, how exactly is DirectX not tied to the OS?

XNA != DirectX. XNA is a very thin wrapper over DX, but it's not tied into the OS itself by any means.

Yes but you and a lot of other people have the source. Moreover you and a lot of other people can fork the project. At the very least, there will be bug fixes on going. That makes a huge difference.

The thing increasingly forcing me away from Microsoft isn't the adoption of new frameworks -- I'm spry and can roll with the changes. What kills them for me is the constant change in frameworks plus little to no support for forward compatibility on existing systems (they used to be much better at this part of it, but have totally dropped the ball on it more recently).

Typical modern Microsoft:

"Okay guys, now we're doing everything in API-Y which is quite different than API-X. And API-Y apps don't run on Windows version I which 90% of the market is running, they only run on Windows version J and higher, which 4% of the market is running."

Yeah, that's not cool, especially if you're doing this just about every time a new Windows version comes out.

Luckily that XNA experience transfers over to MonoGame and the general principles of basic game programming are quite universal. A lot of aspiring game developers have got their feet wet thanks to XNA.

Yeah, XNA was great, Microsoft handling it, less so.

Well said. I came to the same conclusion back in 2000 after we worked with Microsoft on BizTalk (of all things, this should bring hoots of derision from a few readers). Luckily Linux was on the rise in the server market so I jumped ship to start writing Java and later Python and never looked back.

This has always been one of my primary reasons to avoid putting time in Microsoft technologies. Luckily with MS becoming increasingly more irrelevant over the years it is easier than ever to ignore them.

At least some of that investment should be reusable with Mono/MonoGame/MonoTouch|Droid/Unity3d.

Ah man, I feel bad. I've yet to experience that to happen. Most tools I started to pickup when learning are still here, and new additions.

I hope things get better for you.

My experience too. I'm stuck with the .net stack for many years and none of the technologies I got familiar with became obsolete.

That said, I'm starting to be skeptical on trusting them after all of these.

I'm going to point out that managed game programming is not dead for the XBox/PC. Remember that XNA was a replacement for Managed DirectX, which was killed off shortly before MS introduced XNA.

In other words, XNA is dying, but the C# and the managed game programming paradigm is not. It will be replaced by something, just not XNA.

Technology changes and Microsoft can't be tied down to wrong decisions (wrong relative to the new world, but perhaps right at the time). We get paid to know and leverage this stuff, so just adapt or...as the saying goes...die.

Having said that, despite working in the Microsoft sphere for the bulk of my career, I've managed to sidestep these issues. XNA, Silverlight, XAML, WPF, Azure, even Winforms -- there have been a lot of solutions and technologies that were clearly of limited longevity or probability of success from the outset, so I moved in other directions.

Any hints that give you an idea that a new tech is destined to die quickly?

It's always a gamble and it depends on a lot of specifics. I thought XNA would've stuck around a little longer, especially given the new console that Microsoft is supposed to be releasing this year, I felt it would've been prudent for them to keep it around so that people can write the newest Xbox games right away.

In the case of Silverlight, I remember thinking to myself about how I would wait on it to see how it fared given the saturation of Flash everywhere else, and see how widespread the adoption was going to be. If I decided to dedicate myself to learning Silverlight I'd be very disappointed.

My gut feeling is that Durango will be able to play Windows Store games, possibly with a recompile to a slightly different platform target. So I expect there will still be a pathway.

There's still the expectation that people use C++/CX, which is terrible, but I think the "indie" path will be pretty well-formed.

Reply on news.ycombinator.com