Why MSDN publishes more Managed Code than Native Code Information
From time to time, I get queries like “Why is Microsoft forcing managed code on us?” or “Why is Microsoft abandoning native code?” and so on. As MSDN is a key Microsoft public interface to developers, I thought I’d answer that from my own perspective.
Being a Program Manager at MSDN offers me a unique position within Microsoft as my specific job (Content Strategist) is to publish content that balances the needs of marketing and the technical product teams with our own knowledge of the target audience and the technologies involved while aligning with Microsoft’s overall business goals. Needless to say, the job can be quite challenging and at times more political than I’d prefer as I’ve been a programmer since the early 80’s and sometimes long for the days of being lost in low-level code as opposed to endless meetings. However, at the same time, I do enjoy my job very much as it enables me to see the business from many different vantage points and to have a basic understanding of why we do some of the things we do. One of those issues is the whole “managed code vs. native code” issue regarding why we promote the former much more than the latter.
To start with, I submit to you that there is no black and white here. We’re talking about the amount of information on managed code and managed code tools relative to native code information. In terms of native code, there are over 7,000 new APIs in the Windows SDK and every two weeks, we publish a new chapter to the Windows Vista Developer Story – a 600+ page collection of information on native SDK development. In addition, as we get closer to releasing the Windows Vista and the new Windows SDK, you’ll begin to see even more native code articles. However, most of the native code information is centralized on the Windows Vista and Visual C++ Developer Centers with the majority of information being published by MSDN being focused on managed code. Hopefully, this post will explain why – at least from my point of view.
Marketing –At Microsoft we have hundreds of products, but it’s no surprise that the reason we remain the most profitable software company in the world is by virtue of selling two main products - Windows and Office. In addition, it’s critical for the long-term stability of Microsoft that we also have a major impact on the Web.
Everything else (especially development tools) is simply a means of accomplishing those goals. An example is the Windows SDK. It’s completely free to anyone that wants to download it as it serves the greater purpose of getting developers to write Windows applications, which in turn sells more copies of Windows. In addition, you frequently see us hold training seminars that, at best, break even and might even lose money. Once again, the goal isn’t making money from these products or functions. The goal is to get information into the hands of developers so that they write Windows applications – or Web applications using Microsoft technologies.
There are many more examples – such as the free Visual Studio Express products, free training, free technical articles on MSDN and so on, but you get the point. The focus is always things like, “What can we do to the O/S to enable developers to create the apps they want for their customers?”, “How can we make the development tools easier to use to lower the cost of delivering that software in a timely fashion?”, etc.
Having said that, the latest technologies that accomplish the goals of selling Windows, pushing the Web and making it easier for developers to write Windows applications, are things like Windows Presentation Foundation, Windows Communication Foundation, Windows Workflow, etc.
Therefore, most conversations between marketing and MSDN deal with focusing on these newer technologies – in the form of publishing technical articles and whitepapers written by evangelists, promoting training and seminars, providing demos and hands-on labs and so on.
Product Teams – This is an easy one as most likely if you’re reading my blog, you’re also a developer and realize that most developers want to work on the latest, coolest thing. Our dev teams are no different. Therefore, internally when our product team developers write for MSDN they’re generally writing about the latest technologies. In addition, the various levels of management for these product teams also focus on requesting that we more heavily promote the latest innovations and features of their products.
Target Audience – If you ever want the definitive answer for why we at Microsoft do something, follow the metrics. The Visual Studio and .NET Developer Centers are – by far - the two most popular Dev Centers (in terms of traffic and users). They are followed up by Windows Vista (which is gaining rapidly despite still being in beta) and VB.NET. The meaning is clear. Developers come to MSDN looking for information about managed code and Windows Vista.
Therefore, one way of answering the question of why we post so much managed code content (relative to native code) is via the old adage, "We don't make the news; we only report it." Like any other company we stay in business by meeting the needs of our customers. If customers weren't asking for and responding favorably to this, we’d be going in a different direction. Therefore, it’s simply inaccurate to say that we’re forcing anything on anyone. We’re the ones reacting to what the masses have requested and right now that’s managed code and tools for developing advanced UIs in the fasted time possible.
Comments
- Anonymous
March 25, 2006
Wow. I had no idea the things you mentioned about native code regarding Vista and the Windows SDK. I guess I didn't dig deep enough on the website to see that stuff. This certainly does educate my perspective on the issue.
You have me seeing it 99% differently now. The remaining 1% is still angry that Avalon is available ONLY to managed code.
Best Regards,
Rich - Anonymous
March 25, 2006
Rich: I'm glad I could answer your questions/concerns.
One of the main reasons that Content Strategists blog is to "raise the window shades" (no pun intended) and let customers know that there's real people and real reasons behind the decisions we make and that customers are ultimatelly our key stakeholders with our success being measured by our ability to respond to your needs and goals - Anonymous
March 26, 2006
The comment has been removed - Anonymous
March 26, 2006
Great post. Thanks for the insight. - Anonymous
March 26, 2006
You refer to web traffic concerning new technologies but you should always expect people who are on the ball to at least take more than a quick peek at any new technology to see if it has anything useful to offer. This does not mean every hit means another convert.
www.tiobe.com has a similar flawed thinking when they rate the popularity of a language based on search engine hits. MSDN has most of what people need without the need to "google" for it 80% of the time so this would bias the Tiobe rating against your products (languages). Languages that get more hits may just mean the help system is flawed and users need to reach outside the manufacturers resources to get assistance.
I have bought books on .NET, C#, and Java. Took tons of classes on Java but I still use Visual C++ Native code for everything I produce privately and at work. I came here today to check out what all the hype was about concerning WinFX but now I'm affraid to even investigate it as you folks will incorrectly assume I'm here because I'm subscribing to a new technology.
Win32 remains so well documented and seasoned professionals will rarely need to stray outside their local copy of MSDN for standard production needs. My web traffic or book purchasing patterns do not even remotely represent what technologies are making it to market in my world. My web usage is merely me trying to make sure I don't miss something that solves a problem I DON'T already have a solution for. Your data is skewed if you think all the traffic is anything but simple curiousity because of your massive marketing efforts. I would guess most people who have a foothold in a technology already, will likely only compare and contrast the new vs. old. Your likely to get the newbies to jump on board because they don't already have investments in current technologies.
I've only found GDI+ to provide some enhancements that I think I'd prefer not to live without. Anyway, I appreciate the fact that your in your position hopefully looking out for the rest of us and I appreciate the fact that you took the time for the post. My reply is only intended to suggest a more cautious response to the statistics and numbers being thrown around up there. - Anonymous
March 26, 2006
hej,
prowokujący tytuł, nieprawdaż? :-)
czy ktoś z Was dziś jeszcze pamięta sztuczki i kruczki z C/C++?... - Anonymous
March 27, 2006
I think one of the keys to understanding this issue is in the the question itself. When native code developers ask themselfs "Why does Microsoft force managed code on their developers?" I think what they really want to ask themselfs is "Why can't Microsoft be more like us and push native code on their developers?".
The reasons for promoting the managed code base are rather obvious in my oppinion, not only from a marketing / economical perspective but also from looking at where Microsoft is going with the whole .NET platform.
To sum it up, I think most of us understand why ms does promote managed code, but not why ms doesnt give enough attention to native code.
hmm maybe I'm being a tad bit too philisophical about the whole matter, anyhow thanks for a good post. - Anonymous
March 27, 2006
I want to know how to develop Operating system using VC++, Any ideas to me?
chenxinyi1978@hotmail.com - Anonymous
March 28, 2006
I suspect the reason many developers ask about "Why so much managed code?" is that they are flummoxed by the Vista "relaunch" and the decision to use Windows 2003 Server as the code base. With Avalon and Indigo now being "add-ons" rather than "pillars" of Vista, people are confused about whether to write to the .NET API or stick with MSFC / Win32. Seeing so much managed code on MSDN, yet being told that the code base will remain unmanaged for at least the next 10 years, leaves developers in a state of uncertainty about how best to proceed. IMHO, of course... - Anonymous
March 28, 2006
I am developer WEB of applications and I use technology ASP.NET 2.0. After first acquaintance with WPF, I have understood, that I should be reoriented on new technology WPF, besides many official sources Microsoft write that Avalon and XAML functionalities which in hundreds times surpass DHTML give! In connection with that, that XAML applications can be integrated very easily with WEB, I believe, that would be more correct to build applications for WEB on XAML. But here there is one problem:
Existing technologies, such as HTML, DHTML, JavaScript - are WEB standards which are supported by all browsers and are indexed by search engines: Yandex, Google, Rambler, etc. In this connection there is a question on availability of mine XAML a site in a global web.
Question:
Whether undertakes what that measures Microsoft, on standardization XAML, how WEB the standard like HTML?
Thank. - Anonymous
April 01, 2006
The comment has been removed - Anonymous
April 01, 2006
dfg - Anonymous
April 02, 2006
The comment has been removed - Anonymous
April 03, 2006
My company currently has no intention of using managed code... - Anonymous
April 03, 2006
To me it is like a child opening the fridge to find the cheeze wizz, and absolutely not having any idea of what it contains or how it got there in the first place. AHHH yes but someone really knows! Knows what? It dosn't matter, the kid is over there and still smiling!
Thanks for the topic - Anonymous
April 04, 2006
Hi Tom,
I am working on medical instrumentation software that acquires and displays data from medical hardware. Sampling rate is 4 packets per ms.
What managed code? Not everybody is working on WEB apps (that will work only under IE 7?). There are different applications out there that require appropriate solutions and tools. There are different software developers out-there too. You should remember Tom, you have been there with us.
On the topic:
Thanks for attempt to articulate position of MS that you (as a MS employee) are not allowed to articulate.
I think developers who've been around will agree that position of MS is not only to help developers to create applications for Windows, but for Windows only. It started with VB many years ago and still continues with C#. It was always war against Apple, Unix, Linux, IBM OS/2, Oracle, Java, PHP, Open Source, Free Software, you name it. Now it is AJAX war with Eclipse platform and others.
I am not blaming MS, but this is how it always was.
BTW: If you remove all references to native API from your website, will you still consider people who are looking for it browsing through countless managed code articles as MANAGED DEVELOPERS? (or should we say MANAGED BY MS DEVELOPERS?:-)
Thanks for the topic,
Best Regards,
Alexei - Anonymous
April 04, 2006
I work on real time trading apps at a large company. We have to handle thousands of price updates per second. Many of these updates require some significant computations be updated as well. If we fail to keep up we can loose thousands of dollars within seconds. Furthermore, there's still a lot of Unix dinosaurs around here and they're not going away so whatever we do has to communicate with them. This doesn't even touch on what would most likely be a truly huge porting effort if we were ever to dive into .NET in a big way.
I think we'll be on native code for the forseeable future. In fact, if MS ever failed to adequately support native code there would be a strong push to move to a non-Windows OSes.
We use .NET where we can around here but that isn't many places. Typically small apps for updating the database which could have been written with VB or C++/MFC if .NET weren't available. However, the heavy hitting mission critical apps (at least those that run on Windows) are in good old C++/Win32 and this will continue.
.NET certainly has it's place. I personally write .NET/C# code whenever I can and I love the C# language. I have probably accounted for many of those hits you were seeing. However, around here it can't be used everywhere or even in most places. My company could operate quite well without .NET if we had to. Without native code we'd either have to shut down or switch to a non-Windows OS.
As a previous person pointed out, not everyone writes web apps. People who want to learn about .NET are doing it for many reasons and many (most?) are not using it as their primary development platform. You need to remember that. - Anonymous
April 05, 2006
Ken: Thanks much for the input. I agree with you that we do need to remember all of our customers. Hopefully, the fact that the SDK team has created 7,000+ new APIs clearly indicates to everyone that we are not in any way abandoning Win32/native programmers. Quite the contrary. We're continuing to strengthen our offering to them with every release. - Anonymous
April 06, 2006
I think the way we program applications has changed a lot. Now a days programming is more of designing and configuring things rather than typing actual code, .net marvels at this, but unfortunately there is a huge performace bottleneck for using these things, also the way the memory is being handled is a mess; in our organization we 'wrote' thousands of lines for a web app and the final result- a too hopelessly slow product that fiinds it difficult to manage even dozens of users, i donno what will be the future but I believe the word will definately take a U turn and the demand for native code will return. - Anonymous
April 13, 2006
In many ways, I think this post just misses the mark entirely, especially with regard to the statement "We don't make the news, we just report it."
MS absolutely made the news with regards to managed code; once they decided that it represents a "better way" to do things, native code became an afterthought. Every one of the MS marketing machines (of which MSDN Magazine is a part, though in many ways a good part) became almost entirely focused on managed code. They have deliberately done everything possible to make it sound like you're "missing the boat" if you aren't moving to this newer technology.
The problem with this strategy is that it forgets a very important point. Almost every modern ISV with applications of any relevance whatsoever have written their code in C++. We have to deploy these applications to our customers, we have to support them, and guess what - we have to improve them.
But MS decided to stop helping us to reach those goals. What's new for C++ in VS2005? Honestly, the truth is nothing. But MS did re-work things in such a way that deploying MSVC++ applications became much harder than it should be (I won't get into the details here).
Meanwhile, thousands of commercial applications out there continue to use C++/MFC/STL to reach their customers, and stuggle mightily as Microsoft turns their backs on us with no improvements to the technologies or libraries.
At the end of the day, managed code is just a higher level abstraction. It's right for many things, but not everything. To Microsoft, every code base suddenly looks like a nail, and their favorite hammer is managed code. - Anonymous
April 13, 2006
The comment has been removed - Anonymous
April 18, 2006
Actually - my question isn't why is there so much managed code - I think Managed is the way to go.
My question is: why is there so much ASP.NET? ASP.NET solves one very specific problem, but most of us still want to use desktop applications, and most of us want to make and sell them.
That's not likely to change any time soon, contrary to the views of many pundits. Like - this is the year of Unix, which they've been saying since 1972, this is the year of the Web App is another one that I think will fill specific niches but not be "the" solution.
I'd like more focus on desktop apps or "SmartClients" as they're now called.
And while we're at it - Windows Mobile/WinCE - and Smartphones. .NET CF is one of the more painful things to try and work through using MSDN. - Anonymous
April 19, 2006
The comment has been removed - Anonymous
April 25, 2006
我覺得就是一種商業策略 實際上整個.NET也是一種商業策略下的產物 它不是必需的 用VC++還有什麽不能實現的？沒有。現在的Windows和VS.NET爲了這種策略改得亂七八糟。比如VC6的IDE風格對於MFC/ATL開發者是再合適不過了，但是爲了統一使用一种風格，M$不惜犧牲了6的那個科學方便的IDE，改用那種VB式的愚蠢的風格。說實話這讓人覺得噁心，我和許多人一樣現在仍然使用6，也許我以後必須忍受那個令人生厭的IDE，但如果真到了那天我想我會儘快轉到UNIXBSDLinux。 - Anonymous
April 25, 2006
I find it difficult to understand why so many developers are so hostile to new technologies such as .NET. If more developers would stop listening to all the negativity coming out of the camps who can't cope with change or progress, they just might find out that .NET does provide for better, more efficient, secure, and rapid application development.
I have seen numerous posts just here in this blog talking about how native code would live long after .NET was dead and gone. People have to come to the realization that we aren't living in the 80s or 90s when vendors could take 3-4 years to ship a product. If you do that today you'll be left in the dust.
Productivity is ultimately where .NET will win. Productivity equals profits, which equals adoption by business executives, which will eventually force developers to do what they should be doing in the first place. Current projects may not need to be ported, but for any new projects I can't find a good reason not to use .NET if you're developing on the Windows platform. It cuts development time in half at least, but that's a conservative estimate.
Stop fighting progress and upgrade your skills for the 21st century. Those who don't will truly be left behind. - Anonymous
April 27, 2006
Hello Microsoft management, you reading any of this?
Thanks for answering this question Tom. I also don’t buy the “Reporting the news” metaphor. I’ve noticed not many people have responded with “right on, I only care about .NET”
I personally really like .NET and managed code. The richness of functionality in the .NET portfolio saves huge amounts of time over constantly re-inventing the wheel with WIN32. I have spent so much time trying to glue together different libraries that have different ideas about object management, allocation and deallocation in Native Code. With managed code all this becomes so much simpler. (Good riddance ATL) I can now pass data between applications and not worry about who owns it.
.Net has some really great attributes, but the (assumed) bloat and performance problems make it unusable for many applications.
What is the guideline for knowing when .NET / Managed code is usable? What is the performance penalty versus the equivalent (well coded) native implementations? Is the only solution for each developer to just try it? Is the JIT compiler for C# much better than we think? (and this isn’t as bad of a problem as we all think it is)
Assuming managed code performs as bad as rumor has it. I have a prediction:
The main stream is all going to mottle about (like me) and all reach the same conclusion. Managed code is really great for passing objects between large blobs of code developed by different groups and .NET is really great for its rich set of functions, but you still need unmanaged code for speed. So most devs will decide they want C++ with managed extensions. I can now switch between managed objects and unmanaged data as much as I want. I can code “inner loop” type functions using unmanaged data types all day long
So why am I reading the C++ with managed extensions is being deprecated for CLR? CLR doesn’t look like C++ to me. - Anonymous
April 27, 2006
The guy above just highlited the biggest short comming of managed code ... speed. Managed code is all fine for productivity for business applications where performance isn't paramount and rapid development times are crucial but it doesn't suit all applications. Applications that require performance just wont get the same level as what they would get with native code and often may not even get the required level of performance. I am not against managed code but I am against it being pushed on us when it can't possible cover every applications needs. - Anonymous
April 30, 2006
The comment has been removed - Anonymous
May 03, 2006
The comment has been removed - Anonymous
May 03, 2006
just make sure you tell me when you plan to stop supporting unmanaged code on msdn, it will be the last day i visit the site. - Anonymous
May 04, 2006
The comment has been removed - Anonymous
May 04, 2006
MS support for .NET vs public opinion,is a primary error that needs to be debugged not by MS but by developer's.
MS does that in which is to their best intrests,as in opposite to developer's whom do not need any managed code.
It's clear that there is more of a fear element that is felt by hard coder's of something theyve done for years if not decade's may eventually fade into oblivion.
Small subtile changes,with a little less information,and learning tools,and functionality that will prevent it from being ported,or integrated,adds to that dismay,some may call it misinformation.
Further developments require a certain set of basic rules,even if a user sees the rules as instructions,(really no differance).
Of course I would fear that it may make development easier,and quicker,but also take away a certain quality of a product of which elements of flooding the market with cheap but less functional applications,will change public opinion,causing the masses to purchase more applications from MS than from third parties.
Now thats what you call marketing! :) - Anonymous
May 04, 2006
Bloat? Performance problems? Can these allegations be quantified? No doubt, in some kinds of applications (e.g. those requiring realtime response), a badly timed garbage collection could cause an application to fail. As for bloat, if the library is properly constructed, only necessary code should ever be loaded into memory. Large physical memories and paging should make even bloated code work well. - Anonymous
May 09, 2006
The comment has been removed - Anonymous
May 11, 2006
The comment has been removed - Anonymous
May 16, 2006
The premise behind the question, "Why do we have to change" infers that change is something to be feared or avoided. Change is precipitated by ideas which spawn technological innovations. The Microsoft .NET Framework is one such idea that has spawned technological change. Change is not to be feared but embraced with enthusiasm. But while embracing change, never forget that your customers vote with their pocketbooks. One customer's idea of acceptable change is another's unbearable nightmare.
While it is partially true that we work in environments we are comfortable with, it is more accurate to say we work in the environments that are productive, and provide the tools to effectively satisfy our customer's demands. The real issue is: What is important to your customers? For example, avionics software requires the highest level of accuracy and performance possible. Would you replace real-time operating system, kernel-level code with a JIT-Compiled, virtual machine like the .NET Framework? Perhaps, but in these cases, embedded systems programming and real-time operating systems rule - and for good reason. Thus, customer preferences and application requirements play a huge role in the chosen development environments.
One final point: If everything in your toolbox is a hammer, you will only build what a hammer can build. While C# is the lingua france of choice, it is not suited for everything. It is not yet suited for real-time operating systems development, embedded programming, CMOS programming, or performance sensitive applications.
Would you use Adobe Photoshop if it were written as a managed application? Adobe tried converting some of their products to C#, but the performance limitations of a virtualized environment made it an absolute performance sloth. Thus, they returned to C++. In essence, they chose the right tool for the right job. They recognized their customer demands and responded with the correct technology to meet that demand - C++.
Personlly, I think C# is a great language. I respect its strengths and its weaknesses. However, it is not yet truly ready for the mainstream, commercial software world. P/Invoke and COM-Interop are great tools in the interim, but what will come next is anyone's guess.
Be careful when you make assertions that C++, Delphi or any other "older" languages are relegated to the technology landfill. COBOL is still around. Perl is in full force use, and Python is gaining a resurgence in popularity. Microsoft made the language choice irrelevant within the .NET Framework Managed Environment - but unmanaged code will never really go away. I suspect that the C++ Language Specification will continue to evolve as most languages do. And I suspect that virtualization will be relegated to just a corporate fad within 10 years. After all, 88 million baby-boomers don't care about virtualization. They care about sending and receiving e-mail, and basic computer operations. Youth care about the latest gadgets, VoIP Technologies, IM and Text Messaging. Different technologies for different generations but the same overriding principle: customers vote with their pocketbooks. The value proposition is any language or technology is directly proportional to how well you meet the customer's expectation of what they think your technology will do for them.
Who will win? it won't be the company "greasing" it's wheel with profits. It will be the company that most effectively and accurately meets it's customer's needs. Profit follows principle - the principle of meeting customer demand. And what's wrong with profit anyway? That's a good thing. :-) - Anonymous
May 19, 2006
The comment has been removed - Anonymous
May 20, 2006
Great post Tom. I don't think microsoft has every really let the unmanaged community down at all.
I think some people fail to see the value of managed code in enteprise applications - specifically because they have never been involved in writing applications on an enterprise scale where real-time like code performance is not neccessarily the critical factor in delivering business value. This is especially the case in large distributed business applications whereby performance considerations are rarely measured at the applications code level, but more so at the level of communications channels (eg Web service v remoting) or at a database level. (database optimisation). In this sense, i think Microsoft's position is still very well balanced - especially considering that most developers will be writing these sorts of systems. (imho)
I certainly don't see Microsoft telling everyone to write real time medical software or trading platforms in managed code. Of course it can be done, but those of us with a little bit of imagination know that there are cetain things that need to be done in the unmanaged world. Which is why .net allows you to interoperate with unmanaged code. Write the low level stuff unmanaged in C++ and the other stuff in C#. As you have mentioned there is still a huge wealth of unamanged resources available and more to come with Vista. I really don't see what anyone in the unmanaged world would have to worry about? :) - Anonymous
May 27, 2006
The comment has been removed - Anonymous
June 03, 2006
Well, overall I can understand the frustration, because I would prefer the power and complete control of native code.
However, being in the IT field at a college, I have had to deal with many computers running native code apps that had either compatability issues or that were so poorly managed (memory management that is) that when you would close the app, it would continue to consume memory. Dealing with students, of whom the majority had left over P1 machines running windows 98, I had many trying to get me to fix their computers when the software they installed was shotty itself. Overall, I think for smaller software companies and those who aren't really adept at computer programming, plus those who are hobbyist or newbies, the .NET thing kind of makes me feel a little safer in that some aspects are protected from their ignorance, and at most will simply not work the way intended, but not as likely mess up the computer. - Anonymous
June 05, 2006
The comment has been removed - Anonymous
June 09, 2006
It's waaaaaaay simpler than all that.
Native code articles have been published by the tens of thousands for 20 years.
Managed code articles only date back 3-4 years. They have a LONG way to go to catch up! - Anonymous
June 10, 2006
I make a point of reading the sort of discussions which appear on this blog. Reading though I wonder if anybody has looked at the RAD tool Omnis Studio? - Anonymous
June 10, 2006
I came here to learn something more about Visual Studio role in my program development. Might there be a better place for me to learn more? Right now I am hitting walls which are non-intuitive. When I Google for the messages I get hits so I am not the only one hitting the walls. Speaking of productivity, just how valid is the message that I should be using these productivity 'enhancers'. - Anonymous
June 11, 2006
Well, for years you are saying that .NET is better, easier, more productive, and as fast as native (within 10%) and you wonder why are people so "thrilled" about it. Of course most of those marketing propaganda are all lies. For example benchmarks are childish. I mean you take one simple loop and few calculations and say, see its only 2% slower. Or DirectX app in which 99% is done in HW and says just 3%. But if we look at real world apps NET is at least 3 times slower than Native. Why? Because NET libraries make a lot of "cheap" objects and when you use 100000 net classes, which you do in any app, millions of "cheap" objects are generated under the hood, that's why for example even Microsoft made SQL Server management tool is unbelievably slow since they made it in NET. While it was native it run instantly. Any app you run you immediately see it’s made in NET or Java, for example Eclipse, Zend, etc. Why doesn’t Microsoft make Office in NET, or why are Photoshop, 3dsmax, etc all native. I recently converted some database code from VB6 to C#, and guess what VB6 runs MUCH faster for the same functionality.
Also "you need hundreds of lines in c++, and in NET its 3 lines of code" philosophy is for dummies. Of course if you do everything from scratch and don’t use STL, BOOST, etc. you need hundreds of lines of code, but if you did everything from scratch in NET it would also take "hundreds of lines of code". You could just as easily take ONE OF MANY libraries in c++ for the same task and make same thing in 2 or 3 lines of code, depending on library.
Anyway its obvious that Microsoft pushes .NET because they don’t like idea of QT, wxWindows, etc. which make perfect multiplatform tools. That was big problem for Microsoft because anyone could make quality products for both Windows and *nix-es, which had to be dealt with. .NET is perfect solution, because it forces people to depend on Microsoft libraries, and people are unable to make portable apps (Mono is a joke). Also with putting so much abstraction in people's heads (and forcing them to forget real programming), they are sure no one will be able to make serious product which competes with some of their products which are all native (serious ones). However they risk a lot here because software on *nix-es will be of much more quality, since its native, and companies may consider shifting there instead of buying additional hardware to support slow running .NET apps.
As a programmer, I hate open source movement, and I hope Microsoft will realize its mistake and continue to support native code not only "legacy" support, but also with sincere marketing, like "c++ is 17 times faster than C# in typical serious app, but its harder to learn".
Dreams, dreams.... - Anonymous
June 12, 2006
Since when are templates non-type-safe? - Anonymous
July 07, 2006
PingBack from http://www.menasoft.com/blog/?p=15 - Anonymous
July 13, 2006
The comment has been removed - Anonymous
July 18, 2006
The comment has been removed - Anonymous
July 20, 2006
Nice discusson.
I used to write database apps in vb6 (60%) and other type of apps in vc/vc++(40%). But now I write even database programs in vc++. Rapid application depends on one's command over a tool and language. Now I deliver better and faster database apps in vc++ very fast as compared to vb6. GUI is rich and much user friendly and very much in my control.
Now I have turned 100% VC/VC++ ONLY and I do not regret my decision.