Software Development

Poll: Are Microsoft's development tools headed in the right direction?

Justin James thinks that much of Microsoft's recent efforts in the way of new development tools, technologies, and languages aren't really what developers need right now. Do you agree?

In the last couple of years, Microsoft has come out with a plethora of new technologies, tools, techniques, languages, paradigms, and frameworks for developers. To see what I mean, compare the .NET stack in version 2 to version 4: Silverlight, WPF, ASP.NET MVC, F#, Parallel Extensions, Workflow Foundation, Entity Framework, WCF, and others come to mind.

I think a lot of these Microsoft tools and technologies have real, tangible value for your average developer. WCF, for example, is very well done. WPF (and Silverlight) can put together some great UIs. And I think that F# is a step in an interesting (albeit, probably not useful for most folks) direction.

But some of these technologies are either half baked (Entity Framework) or really do not address the fundamental issues that developers face (ASP.NET MVC). So from my perspective, much of Microsoft's recent efforts, while good intentioned, aren't really what developers need right now. What do you think? Please take the poll and shared your thoughts in the discussion.

J.Ja

About

Justin James is the Lead Architect for Conigent.

5 comments
apotheon
apotheon

I'm not sure that's a question I can reasonably answer as it was asked. Microsoft's approach to serving developers is -- and to some extent, has been for a couple decades -- kind of schizophrenic. Microsoft is all over the map, and even each of its specific subframeworks contains some tension between things going in the right direction and things going in pretty much the opposite direction. Part of the problem is, I think, Microsoft's tendency to try to reinvent everything it runs across that seems like it might be a good idea.

Sterling chip Camden
Sterling chip Camden

that Microsoft seems to be showing some evidence of panic in the way they're pursuing "running across" things. They know that the days of their hegemony are numbered as the desktop becomes less relevant, and they know that a few others have the jump on them elsewhere. Their traditional approach to recruiting developers has always been "we own the desktop, so you need to learn how to use our tools." They have to change that approach, but they don't yet know how.

Mark Miller
Mark Miller

What you're saying reminds me of how Microsoft put Windows PCs on the internet. Of course, they weren't the first to do it (third party products were putting PCs on the internet earlier), but the way they did it was just to add a TCP/IP stack (winsock) and a web browser (IE) to Windows, and call it done. I'm sure the way they thought about it on a technical level was, "It's a peer-to-peer architecture, so it's no different than putting a PC on a LAN." Oh boy is it different! What they presented was "a desktop PC that can now surf the internet." They didn't look at if that design made sense at all. All that mattered was getting in front of the trend, "leveraging" their existing technology as much as possible. It would be like if Microsoft were a car company in the early 20th century, and they discovered that airline travel was a hot new trend, so they decided to mass produce cars that had foldout wings, and propellers so they could fly as well. Granted, in the real world there were companies who tried to do this! They didn't succeed as well as Windows did, though. This attitude damaged the internet's potential quite a bit, because all of the flaws in the "desktop PC on the internet" design were revealed, and the industry's response was to restrict what people could do on the internet, using the web medium, which was already restricted. They didn't realize that the design was flawed to begin with, and they should get to work on a better one. They followed that mistake with others. Their first attempt at an application platform for the web was Active Server Pages (ASP), using COM on the back end. It was the same strategy. "Leverage" a technology designed for the desktop (COM) and put it on the internet. That was kind of a disaster, from what I understand, because COM didn't handle multi-threading all that well, plus it had the same versioning issues that COM/ActiveX had on the desktop. They eventually got something in a reasonable direction with Microsoft Transaction Server (MTS), which incorporated late binding into COM, and set up a separate COM runtime and server for marshaling them. It was similar to CORBA. This is what eventually became COM+. Some say that .Net was really the next generation of this technology, but I disagree. I think it was Microsoft's admission that the COM architecture was not going to work on the web, and so they decided to switch their architectural strategy wholesale to what Java was doing on the internet, except with less flexible framework APIs. I'd say that what Java was doing was not all that great either, but it made more sense than COM.

apotheon
apotheon

> What they presented was "a desktop PC that can now surf the internet." They didn't look at if that design made sense at all. I'd be interested in reading/hearing about your speculations as to alternative models that would be better. Buried amidst the rest of your commentary as this is, I suppose it is easy to skate past it to other (perhaps more concrete) statements, but I think this is the Big Deal in what you said. (edit: formatting)

Sterling chip Camden
Sterling chip Camden

It turns out that .NET is a special case of COM internally. You can even fudge hosting .NET components within a COM wrapper using undocumented interfaces (at least we did it a few years ago). But in a sense you're right from an external perspective. The published interfaces are all modeled on Java's.