So Last night I got around to installing VS.NET....
-
So last night I didn't have anything better to do so I installed VS.NET and I'm still left wondering where to start. I have been programming in C++ and MFC for the last 10 years or so and I just can't see the usefullness of VS.NET. I have a couple of questions that I would like to propose to everyone: 1. Can anyone suggest a product/project that MC++ or C# would be a better alternative to than VC6/MFC? 2. What's the usefullness of C#? I've been trying to figure out a project that I would use this for and I still can't come up with one. 3. Where do I even begin? I'm trying to figure out if I want to move our products/components to the VS.NET environment and I'm not sure if we should or not. Everything that we've written is in either MFC applications, MFC OCX controls, win32 DLL's and libs. Any Suggestions? 4. Has anyone else encountered these questions? and how did you deal with them? Thanks, Scott
Scott Everts wrote: 1. Can anyone suggest a product/project that MC++ or C# would be a better alternative to than VC6/MFC? 1) Web apps, other apps where need for rapid development and quick modifications trumps legacy codebase / speed concerns. I also put Java in this category. 2) See #1. 3) Determine first what class of problems might be solved by VS.NET. Then determine if you have these problems in any of your projects. 4) Sure. Still dealing...
Shog9 ---
You'd better turn back, before the frost sets in. These desert nights are for weathered men, The ones who've already given in...
-
The only real benefit (if you can call it that) is that you can still do MFC stuff with the new "improved" MFC libraries. You don't have to use .NOT .NET, managed C++, or even C#. Of course, I haven't yet installed VS.NET, so I may be talkin' through my bunghole... ------- signature starts "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 "You won't like me when I'm angry..." - Dr. Bruce Banner Please review the Legal Disclaimer in my bio. ------- signature ends
The (native) C++ compiler also has vastly improved template conformance. That is important if you use 3rd-party template libraries, such as alternate STLs. --Mike-- Ericahist | CP SearchBar v2.0.2 | Homepage | RightClick-Encrypt | 1ClickPicGrabber There is a saying in statistics that a million monkeys pounding on typewriters would eventually create a work of Shakespeare. Thanks to the Internet, we now know that this is not true.
-
You don't get much closer to a real orgasm than that. ;) -- 20 eyes in my head, they're all the same![^]
Jörgen Sigvardsson wrote: You don't get much closer to a real orgasm than that Some of us do... Maybe it will be your turn one day.;P "Your village called -
They're missing their idiot." -
So last night I didn't have anything better to do so I installed VS.NET and I'm still left wondering where to start. I have been programming in C++ and MFC for the last 10 years or so and I just can't see the usefullness of VS.NET. I have a couple of questions that I would like to propose to everyone: 1. Can anyone suggest a product/project that MC++ or C# would be a better alternative to than VC6/MFC? 2. What's the usefullness of C#? I've been trying to figure out a project that I would use this for and I still can't come up with one. 3. Where do I even begin? I'm trying to figure out if I want to move our products/components to the VS.NET environment and I'm not sure if we should or not. Everything that we've written is in either MFC applications, MFC OCX controls, win32 DLL's and libs. Any Suggestions? 4. Has anyone else encountered these questions? and how did you deal with them? Thanks, Scott
Hey, its quite easy... - .NET is the enhancement of Win32, with win32 fading over time/still being supported. Expect new or crucial functionality (security is one) of a new MS OS (longhorn?) to only being exposed by a .NET API. Also, you do not want to hear your customers say "Hey you are not using unmanaged code, are you?" (just look how BAD that sounds. Unmanaged, chaotic, insecure, unprofessional). - You can say, I do not care! I only need what win32 has to offer (and I am sure MS will not break win32). But... Your customers will use the next Microsoft OS, which will be your development target. Now since that new feature you REALLY NEED will only be exposed via .NET API, you have to use the .NET API. - Since C# is considered sexy (philosophically, technically and whatevery) AND better integrated with the IDE AND really naturally fitting the .CLR AND someday probably as performant as C++ in the context of .NET AND the political way to do it you would be a masochist to use managed C++ exclusively. - Java introduced Hype into the programming world. Programmers are customers. They want to have a nice "philosophy" of programming, best object-oriented, etc. They can really get *fanatic* upon those things. So why not feed them what they need? PRO: Programming for simple/medium apps (up to 300 000loc) made easier. CON: I wonder how Oracle will implement a performant DB server ontop of .NET. Or photoshop? Of course, this will never be an argument for a programmer like me. CON: MS has the major control over application performance (just like those java guys improving the performance because they use the so-so-fast JRockit JVM from BEA). Bottom line: customers use new MS OS that is _REALLY_ good and cool, you program for that audience, you need API functionaly, this is provided by .NET, and you are a .NET programmer. Quite simple! ______________________________ Java: The living proof Moore's law won't solve all your problems
-
Jörgen Sigvardsson wrote: You don't get much closer to a real orgasm than that Some of us do... Maybe it will be your turn one day.;P "Your village called -
They're missing their idiot."There's a difference between getting close to a real orgasm and actually having an orgasm. Both means and goal differs. It may be subtle difference, but it's still a difference. ;P -- 20 eyes in my head, they're all the same![^]
-
Hey, its quite easy... - .NET is the enhancement of Win32, with win32 fading over time/still being supported. Expect new or crucial functionality (security is one) of a new MS OS (longhorn?) to only being exposed by a .NET API. Also, you do not want to hear your customers say "Hey you are not using unmanaged code, are you?" (just look how BAD that sounds. Unmanaged, chaotic, insecure, unprofessional). - You can say, I do not care! I only need what win32 has to offer (and I am sure MS will not break win32). But... Your customers will use the next Microsoft OS, which will be your development target. Now since that new feature you REALLY NEED will only be exposed via .NET API, you have to use the .NET API. - Since C# is considered sexy (philosophically, technically and whatevery) AND better integrated with the IDE AND really naturally fitting the .CLR AND someday probably as performant as C++ in the context of .NET AND the political way to do it you would be a masochist to use managed C++ exclusively. - Java introduced Hype into the programming world. Programmers are customers. They want to have a nice "philosophy" of programming, best object-oriented, etc. They can really get *fanatic* upon those things. So why not feed them what they need? PRO: Programming for simple/medium apps (up to 300 000loc) made easier. CON: I wonder how Oracle will implement a performant DB server ontop of .NET. Or photoshop? Of course, this will never be an argument for a programmer like me. CON: MS has the major control over application performance (just like those java guys improving the performance because they use the so-so-fast JRockit JVM from BEA). Bottom line: customers use new MS OS that is _REALLY_ good and cool, you program for that audience, you need API functionaly, this is provided by .NET, and you are a .NET programmer. Quite simple! ______________________________ Java: The living proof Moore's law won't solve all your problems
Amanjit Gill wrote: Also, you do not want to hear your customers say "Hey you are not using unmanaged code, are you?" Depends on the project. Ok for new, small projects. What about application start-time? What about mission critical software? Impossible to tell TODAY because there is none in production yet. So please, don't make gratuitous claims, or make sure to narrow your experience to what is is limited to (no pun intended). Can you name a MS product made with .NET? I can name you one available on Jan next year, MS Reporting services, and god it's 100 times slower than today's mission critical report engines.
-
Scott Everts wrote: 1. Can anyone suggest a product/project that MC++ or C# would be a better alternative to than VC6/MFC? There really isn't one on the desktop. Not better at any route. To put it another way, I would not rewrite any existing client only application JUST to move it to a newer tool set, etc. However, if I was in the place to rewrite an application for other reasons or were faced with extensive modifications and additions I would definately make the move, particularly if your development is "mixed". If you are using MFC using standard DLL's and COM DLL's also written in C++ I would stick with it. MFC is still a wonderful and powerful set of API's. However, if you're using a strong mix of VB and C++ which is pretty common (usually a VB6 front end using C++ COM objects and other DLL's) then that would also push me in favor of switching. The reason is that as long as all your code is "managed" (Managed C++, C#, VB.NET) there are no arcane types to deal with, no BSTR's (CURSE YOU TO H*LL BSTR DEVIL), no weird COM threading models to deal with (STA/MTA), registration, you name it... Also, the speed of development is AMAZING. ANYONE who can program in C++ can make very short work of the .NET Framework. It's simply the easiest set of tools I've ever used. Scott Everts wrote: 2. What's the usefullness of C#? I've been trying to figure out a project that I would use this for and I still can't come up with one. C# is nothing more than a replacement for Java OR a way of trying to get C++ programmers to migrate to a VB-ish language without making them too angry about that.... The thing to remember about the .NET Framework (and one of the "joys" of it) is that the system calls are now the same for everyone, available to everyone (regarding of language), and use the same parameters with all the exact same types. The only real difference between the languages (Managed C++, VB.NET, C#) is in the semantics. Scott Everts wrote: 3. Where do I even begin? I'm I've been a C++ COM/MFC developer for several years now and have always really hated VB. However, switching to .NET has been a far better experience then I first thought. Don't switch just to switch. If you are developing major new applications with a small timeline, consider it, but realize that you will have a learning curve and a good deal of money to retool.
Matt Philmon wrote: there are no arcane types to deal with Ask Heath, he's putting code snippets all day long and, by judging the length of his posts, I would think it's not that simple. May be it's my own judgement... Matt Philmon wrote: no BSTR's (CURSE YOU TO H*LL BSTR DEVIL) No, you prefer the crude String api right? Have you figured out there is no Right(n) method available? Matt Philmon wrote: no weird COM threading models to deal with (STA/MTA), Sorry mate, last time I checked the [StaThread] is the first thing you add in a .NET app. It's visible in 100% of the apps. Just check it better. Of course, you don't see it because the wizard does it for you by default, but let's discuss about it next time you need multi-threading support. Matt Philmon wrote: ANYONE who can program in C++ can make very short work of the .NET Framework. This can be true, but is not a general rule IMHO. Can be true for projects not needing older code, especially if all the services you need are provided by the BCL. But just in case you need P/Invoke or COM you are pretty much down in the mud. Matt Philmon wrote: C# is nothing more than a replacement for Java A 100% rip-off. (old MS Java VM) Matt Philmon wrote: I've been a C++ COM/MFC developer for several years now and have always really hated VB. How much do you use Reflector. I can't think about programming against the CLR without it. So please don't pretend that the VS.NET environment, especially C# is not exactly VB-like. Unless you have the decompiler, you are pretty much stuck, like a VB guy and his drag and pray environment. My 2 cents. And if this is not obvious from me, there are good things in .NET, I am not against it.
-
The benefits to using .net on the business and data tiers are significant. (once a developer is comfortable with using the framework) managed memory/objects .net remoting/web services simplified deployment (depending on level of interaction with enterprise services) Of course anything that can be done in .net can be done the preivous version(s) of C++ but leveraging the .net framework allows for (in many cases) significant reduction of code andy
My point was that he could still get real work done without being forced into the .NET crapware. ------- signature starts "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 "You won't like me when I'm angry..." - Dr. Bruce Banner Please review the Legal Disclaimer in my bio. ------- signature ends
-
How's the arm recovering? When will you be completing the next part of the water cooled Athlon? Michael Martin Australia "I suspect I will be impressed though, I am easy." - Paul Watson 21/09/2003
Let's just say I'm done with the hospitals and therapy stuff, and I don't have full use of the hand. :( The watercololing project will be restarted after the first of the year. ------- signature starts "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 "You won't like me when I'm angry..." - Dr. Bruce Banner Please review the Legal Disclaimer in my bio. ------- signature ends
-
The (native) C++ compiler also has vastly improved template conformance. That is important if you use 3rd-party template libraries, such as alternate STLs. --Mike-- Ericahist | CP SearchBar v2.0.2 | Homepage | RightClick-Encrypt | 1ClickPicGrabber There is a saying in statistics that a million monkeys pounding on typewriters would eventually create a work of Shakespeare. Thanks to the Internet, we now know that this is not true.
That's what I meant by "improved". :) ------- signature starts "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 "You won't like me when I'm angry..." - Dr. Bruce Banner Please review the Legal Disclaimer in my bio. ------- signature ends
-
My point was that he could still get real work done without being forced into the .NET crapware. ------- signature starts "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 "You won't like me when I'm angry..." - Dr. Bruce Banner Please review the Legal Disclaimer in my bio. ------- signature ends
-
So last night I didn't have anything better to do so I installed VS.NET and I'm still left wondering where to start. I have been programming in C++ and MFC for the last 10 years or so and I just can't see the usefullness of VS.NET. I have a couple of questions that I would like to propose to everyone: 1. Can anyone suggest a product/project that MC++ or C# would be a better alternative to than VC6/MFC? 2. What's the usefullness of C#? I've been trying to figure out a project that I would use this for and I still can't come up with one. 3. Where do I even begin? I'm trying to figure out if I want to move our products/components to the VS.NET environment and I'm not sure if we should or not. Everything that we've written is in either MFC applications, MFC OCX controls, win32 DLL's and libs. Any Suggestions? 4. Has anyone else encountered these questions? and how did you deal with them? Thanks, Scott
There is no way that .NET ever beating the speed of C++. You will see problems when you were to do some complicated and low end stuff using .NET. Of course, if that was your point of interest. Sonork 100.41263:Anthony_Yio
-
Let's just say I'm done with the hospitals and therapy stuff, and I don't have full use of the hand. :( The watercololing project will be restarted after the first of the year. ------- signature starts "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 "You won't like me when I'm angry..." - Dr. Bruce Banner Please review the Legal Disclaimer in my bio. ------- signature ends
John Simmons / outlaw programmer wrote: Let's just say I'm done with the hospitals and therapy stuff, and I don't have full use of the hand. :( Do the doctors fell you will regain full use of the hand? (If your not comfortable talking to me about this tell me to pull my head in) John Simmons / outlaw programmer wrote: The watercololing project will be restarted after the first of the year. Look forward to the updates on the website. Michael Martin Australia "I suspect I will be impressed though, I am easy." - Paul Watson 21/09/2003
-
My point was that he could still get real work done without being forced into the .NET crapware. ------- signature starts "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 "You won't like me when I'm angry..." - Dr. Bruce Banner Please review the Legal Disclaimer in my bio. ------- signature ends
-
Matt Philmon wrote: there are no arcane types to deal with Ask Heath, he's putting code snippets all day long and, by judging the length of his posts, I would think it's not that simple. May be it's my own judgement... Matt Philmon wrote: no BSTR's (CURSE YOU TO H*LL BSTR DEVIL) No, you prefer the crude String api right? Have you figured out there is no Right(n) method available? Matt Philmon wrote: no weird COM threading models to deal with (STA/MTA), Sorry mate, last time I checked the [StaThread] is the first thing you add in a .NET app. It's visible in 100% of the apps. Just check it better. Of course, you don't see it because the wizard does it for you by default, but let's discuss about it next time you need multi-threading support. Matt Philmon wrote: ANYONE who can program in C++ can make very short work of the .NET Framework. This can be true, but is not a general rule IMHO. Can be true for projects not needing older code, especially if all the services you need are provided by the BCL. But just in case you need P/Invoke or COM you are pretty much down in the mud. Matt Philmon wrote: C# is nothing more than a replacement for Java A 100% rip-off. (old MS Java VM) Matt Philmon wrote: I've been a C++ COM/MFC developer for several years now and have always really hated VB. How much do you use Reflector. I can't think about programming against the CLR without it. So please don't pretend that the VS.NET environment, especially C# is not exactly VB-like. Unless you have the decompiler, you are pretty much stuck, like a VB guy and his drag and pray environment. My 2 cents. And if this is not obvious from me, there are good things in .NET, I am not against it.
Stephane Rodriguez. wrote: Ask Heath, he's putting code snippets all day long and, by judging the length of his posts, I would think it's not that simple. May be it's my own judgement... Alot of my experience in integrating the ATL COM world with VB6 and ASP forced me to learn a LOT new things and types. It was a huge hassle when needing to be able to write a COM component that could work in a MFC application, a VB6 application, AND be useable in both VBScript and Javascript for use in ASP. The types required to cover all your bases, particularly when dealing with arrays of data... even more so multidimensional arrays was a nightmare of arcane types and strange conversions and tracking down memory leaks in your SAFEARRAYS and BSTRS. I hated every moment of it. Never mind that VBScript can't even deal with multidimensional VARIANT (ugh) arrays unless you flatten it all out and make it nearly unusable. Some might think this isn't a big deal but any time you pull large amounts of data together to display on a web page (large tables) and aren't dealing (necessarily) with a database and ADO you'll quickly find out how much a pain it is. Stephane Rodriguez. wrote: Sorry mate, last time I checked the [StaThread] is the first thing you add in a .NET app. It's visible in 100% of the apps. Just check it better. Of course, you don't see it because the wizard does it for you by default, but let's discuss about it next time you need multi-threading support. STA/MTA is hideous. Yes, I know the wool has been pulled over my eyes a bit on how .NET manages all this but to tell you the truth... I really don't care. Go try to write a COM object sometime that MUST be an STA (VB and ASP require it) but ALSO must be multithreaded AND be able to process Windows messages. Trust me, it's not an easy feat. You have to get down deep into the bowels of marshalling and creating your own message pumps, dealing with things you don't even wanna know about and it's a COMMON problem. If you live in a world of pure MFC and C++ it doesn't make a huge difference.... but nowadays we're all saddled with supporting lots of VB users. Stephane Rodriguez. wrote: This can be true, but is not a general rule IMHO. Can be true for projects not needing older code, especially if all the services you need are provided by the BCL. But just in case you need P/Invoke or COM you are pretty much down in the mud. Yes I agree with you... which is why I said that you
-
Amanjit Gill wrote: Also, you do not want to hear your customers say "Hey you are not using unmanaged code, are you?" Depends on the project. Ok for new, small projects. What about application start-time? What about mission critical software? Impossible to tell TODAY because there is none in production yet. So please, don't make gratuitous claims, or make sure to narrow your experience to what is is limited to (no pun intended). Can you name a MS product made with .NET? I can name you one available on Jan next year, MS Reporting services, and god it's 100 times slower than today's mission critical report engines.
NONE in production yet. You are completely right. Native Apps rule, As you said MS products are still running natively. "Unmanaged" C++ still has the ultimate edge in my eyes - Just think about games. What I wanted to say is this: We are mostly application developers, some are doing system development (performance, scalability) etc, but most of us are application developers - look at the apps we build every day for our living (which probably aren't RDBMS)? So basically we are consuming APIs which provide most of the functionality. If you need a functionality which is provided by a .NET API *ONLY*, you probably have to develop "for .NET". Just think about a high-end gfx card, which contains whatever new Rendering /Radiosity/whatever functionality to you. Now if you are an OpenGL programmer, you probably need GL Extensions rovided by the manufacturer to efficiently use the features of your gfx card. Now if your gfx card functionality is only exposed by DirectX API, you just _have_ to develop with DirectX or you cannot use that functionality. (or the opposite). ______________________________ Java: The living proof Moore's law won't solve all your problems
-
Amanjit Gill wrote: Also, you do not want to hear your customers say "Hey you are not using unmanaged code, are you?" Depends on the project. Ok for new, small projects. What about application start-time? What about mission critical software? Impossible to tell TODAY because there is none in production yet. So please, don't make gratuitous claims, or make sure to narrow your experience to what is is limited to (no pun intended). Can you name a MS product made with .NET? I can name you one available on Jan next year, MS Reporting services, and god it's 100 times slower than today's mission critical report engines.
BTW: - I do MFC/C++ for a living right now - I am not doin .NET at all, and will only use it if I have to. ______________________________ Java: The living proof Moore's law won't solve all your problems
-
My point was that he could still get real work done without being forced into the .NET crapware. ------- signature starts "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 "You won't like me when I'm angry..." - Dr. Bruce Banner Please review the Legal Disclaimer in my bio. ------- signature ends
John Simmons / outlaw programmer wrote: My point was that he could still get real work done without being forced into the .NET crapware. You can get work done writing everything in assembly... or COBOL, PL/I, RPG, or whatever. It's you choice. You'll eventually see the light... or be left behind.
If Java had true garbage collection, most programs would delete themselves upon execution - Robert Sewell
-
Stephane Rodriguez. wrote: Ask Heath, he's putting code snippets all day long and, by judging the length of his posts, I would think it's not that simple. May be it's my own judgement... Alot of my experience in integrating the ATL COM world with VB6 and ASP forced me to learn a LOT new things and types. It was a huge hassle when needing to be able to write a COM component that could work in a MFC application, a VB6 application, AND be useable in both VBScript and Javascript for use in ASP. The types required to cover all your bases, particularly when dealing with arrays of data... even more so multidimensional arrays was a nightmare of arcane types and strange conversions and tracking down memory leaks in your SAFEARRAYS and BSTRS. I hated every moment of it. Never mind that VBScript can't even deal with multidimensional VARIANT (ugh) arrays unless you flatten it all out and make it nearly unusable. Some might think this isn't a big deal but any time you pull large amounts of data together to display on a web page (large tables) and aren't dealing (necessarily) with a database and ADO you'll quickly find out how much a pain it is. Stephane Rodriguez. wrote: Sorry mate, last time I checked the [StaThread] is the first thing you add in a .NET app. It's visible in 100% of the apps. Just check it better. Of course, you don't see it because the wizard does it for you by default, but let's discuss about it next time you need multi-threading support. STA/MTA is hideous. Yes, I know the wool has been pulled over my eyes a bit on how .NET manages all this but to tell you the truth... I really don't care. Go try to write a COM object sometime that MUST be an STA (VB and ASP require it) but ALSO must be multithreaded AND be able to process Windows messages. Trust me, it's not an easy feat. You have to get down deep into the bowels of marshalling and creating your own message pumps, dealing with things you don't even wanna know about and it's a COMMON problem. If you live in a world of pure MFC and C++ it doesn't make a huge difference.... but nowadays we're all saddled with supporting lots of VB users. Stephane Rodriguez. wrote: This can be true, but is not a general rule IMHO. Can be true for projects not needing older code, especially if all the services you need are provided by the BCL. But just in case you need P/Invoke or COM you are pretty much down in the mud. Yes I agree with you... which is why I said that you
Matt Philmon wrote: even more so multidimensional arrays was a nightmare of arcane types and strange conversions and tracking down memory leaks in your SAFEARRAYS and BSTRS. I hated every moment of it I understand. Before committing in this, you have to read the right book first. For that matter, the MSDN doc is just not the right documentation. A lot of troubles could have been avoided but, eh that's thing of the past right now.;) Matt Philmon wrote: If you live in a world of pure MFC and C++ it doesn't make a huge difference.... but nowadays we're all saddled with supporting lots of VB users. Ironically, I think it's a good signal that a lot of veteran consultants that know how to handle that kind of stuff will make the money from now on, just because : 1) the new generation of developers barely know this 2) the old MSDN doc is being silently retired 3) the MSDN doc is not up-to-date and anyway has never been sufficient to allow knowledgeable people to solve that kind of issues by just reading a few articles. So yeah, great news, if you consider you stay in that middle-nowhere. But if you choose to go the higher-level language way, well you know that's the land of free bananas. Matt Philmon wrote: and a COM object is easily referenced in a .NET project. Yes and no. Let's focus on the no. Importing the type library is restricted to a few rules. Today's tlbimp.exe/aximp.exe don't import everything, so unless you write a truly simple COM stuff, you'll lose the stuff in-between (there is a commercial replacement for tlbimp, I'll dig the url for you if you are interested). And on the negative side, you have the performance issues, and the memory leaks. In other words, the way we are today from the .NET point of view regarding RCWs is just the exact same point of view than reusing commercial ActiveX controls with your VB or C++ app. It's full of memory leaks, bugs and can't sustain one hour without failing miserably. Matt Philmon wrote: and a COM object is easily referenced in a .NET project. Another con, did you know the full path to the com component is hardcoded in the csproj file? You won't believe they would have done that. But...they did. You can certainly guess the consequences. Matt Philmon wrote: I'm not pretending anything. I always hated VB. I love VB.NET. It's more robust, I can create full classes that are type safe across the f
-
NONE in production yet. You are completely right. Native Apps rule, As you said MS products are still running natively. "Unmanaged" C++ still has the ultimate edge in my eyes - Just think about games. What I wanted to say is this: We are mostly application developers, some are doing system development (performance, scalability) etc, but most of us are application developers - look at the apps we build every day for our living (which probably aren't RDBMS)? So basically we are consuming APIs which provide most of the functionality. If you need a functionality which is provided by a .NET API *ONLY*, you probably have to develop "for .NET". Just think about a high-end gfx card, which contains whatever new Rendering /Radiosity/whatever functionality to you. Now if you are an OpenGL programmer, you probably need GL Extensions rovided by the manufacturer to efficiently use the features of your gfx card. Now if your gfx card functionality is only exposed by DirectX API, you just _have_ to develop with DirectX or you cannot use that functionality. (or the opposite). ______________________________ Java: The living proof Moore's law won't solve all your problems
Amanjit Gill wrote: So basically we are consuming APIs which provide most of the functionality. If you need a functionality which is provided by a .NET API *ONLY*, you probably have to develop "for .NET". In the long run, people who write core libraries (file format converters for instance) will still be over the edge compared to developers who from now on are more and more "simple users" of APIs. If migrating to .NET allows those that really know how the stuff works together be over the edge and gain advantage over others (job, income, ...) then be it. So far, this has not yet happened. Only hope it will.