Opinions on C++ .NET
-
Kevin McFarlane wrote: I'd say it's going towards greater productivity rather than greater ease of use as such. C#, Java and VB .NET are all getting more complex over time. But they'll still be more productive than C++. I don't agree with this. C++ is more complex and harder to learn than C#/Java/VB, but a skilled C++ programmer is often more productive than his C#/Java/VB counterpart.
Nemanja Trifunovic wrote: I don't agree with this. C++ is more complex and harder to learn than C#/Java/VB, but a skilled C++ programmer is often more productive than his C#/Java/VB counterpart. Discovery consist of seeing what everybody has seen and thinking what nobody has thought -- Albert Szent-Györgyi Name the greatest of all the inventors: accident --Mark Twain
-
ASM/C/C++ will always be around for low level development. There are 2 main areas I see where C/C++ is and will be needed: systems programming and performance-intensive applications. You're right to think that C++ is dying, but it is only dying in applications development. Why spend so much time writing large chunks of MFC/ATL code in C++ when one could do it in half the time and half the code using C#, Java, or VB.NET? That's the only place C++ is dying; outside of that, C/C++ will be around for a long time to come. As far as Longhorn goes, WinFX itself will not be reliant on Win32 in the same sense System.Windows.Forms is. Currently, managed apps use Win32 behind the scenes due to the reliance on GDI, Windows Common Controls, and some low level functionalities found only in the Win32 API. Point being, while virtually all our (managed devs) reliance on Win32 is due to using GUI apps, MS.Avalon will abolish this requirement; there will no longer be a need for controls to implement WndProc message pumping under the hood. (yay!) That said, from my understanding, the Longhorn WinFX will be available to C++ developers, but this time it will be an managed API exposed to the unmanaged world, rather than the reverse of that we have now. #include "witty_sig.h"
Judah Himango wrote: As far as Longhorn goes, WinFX itself will not be reliant on Win32 in the same sense System.Windows.Forms is. Currently, managed apps use Win32 behind the scenes due to the reliance on GDI, Windows Common Controls, and some low level functionalities found only in the Win32 API. Point being, while virtually all our (managed devs) reliance on Win32 is due to using GUI apps, MS.Avalon will abolish this requirement; there will no longer be a need for controls to implement WndProc message pumping under the hood. (yay!) That said, from my understanding, the Longhorn WinFX will be available to C++ developers, but this time it will be an managed API exposed to the unmanaged world, rather than the reverse of that we have now. Thats really interesting. If you have a few links to share I'd to read on that. I think what you're saying is true, but what does this mean to the future of computing. LongHorn looks cool, but it doesnt really sway much from windows does it. If we're just throwing together quick code, who gets to make the "next big thing". Discovery consist of seeing what everybody has seen and thinking what nobody has thought -- Albert Szent-Györgyi Name the greatest of all the inventors: accident --Mark Twain
-
C++ won't die but, over time, it will get more specialised. It will be confined to tasks such as writing operating systems, games, high-performance computing and so on. But typical business-oriented apps. will be written in more productive languages. C++ will be confined to tasks where nothing else will do - to tasks where, if you can't do it in anything else, you can do it in C++. I think C++ currently has too wide a usage. It is used for tasks where simpler languages suffice. Kevin
I agree with parts of this statement. At my company we have done an app or two with the .nyet methodology and we have learned enough that we will do everything possible to avoid it in the future. We did not find it to be more productive in the slightest and our quotes in the future will reflect that. __________________________________________ a two cent stamp short of going postal.
-
Kevin McFarlane wrote: I'd say it's going towards greater productivity rather than greater ease of use as such. C#, Java and VB .NET are all getting more complex over time. But they'll still be more productive than C++. I don't agree with this. C++ is more complex and harder to learn than C#/Java/VB, but a skilled C++ programmer is often more productive than his C#/Java/VB counterpart.
Nemanja Trifunovic wrote: C++ is more complex and harder to learn than C#/Java/VB, You can say that again! Nemanja Trifunovic wrote: but a skilled C++ programmer is often more productive than his C#/Java/VB counterpart. What do you mean by productivity? I mean factors such as speed of development and robustness of application. I am primarily a C++ developer myself. I don't yet have heaps of experience of C#. However, I do know at least a couple of advanced C++ developers who now have considerable experience of Java and they tell me that it's more productive. You also say that "a skilled C++ programmer is often more productive than his C#/Java/VB counterpart." It's interesting that you have to be very skilled in C++ to achieve equivalent productivity according to your criteria. I find that on C++ maintenance projects I spend about 40% of my time wrestling with plumbing issues - obscure runtime crashes, etc. - instead of solving business logic issues. Kevin
-
Nemanja Trifunovic wrote: C++ is more complex and harder to learn than C#/Java/VB, You can say that again! Nemanja Trifunovic wrote: but a skilled C++ programmer is often more productive than his C#/Java/VB counterpart. What do you mean by productivity? I mean factors such as speed of development and robustness of application. I am primarily a C++ developer myself. I don't yet have heaps of experience of C#. However, I do know at least a couple of advanced C++ developers who now have considerable experience of Java and they tell me that it's more productive. You also say that "a skilled C++ programmer is often more productive than his C#/Java/VB counterpart." It's interesting that you have to be very skilled in C++ to achieve equivalent productivity according to your criteria. I find that on C++ maintenance projects I spend about 40% of my time wrestling with plumbing issues - obscure runtime crashes, etc. - instead of solving business logic issues. Kevin
Kevin McFarlane wrote: What do you mean by productivity? I mean factors such as speed of development and robustness of application. Me too. I have programmed in several languages, including C#, VB6 and Java, and found out that in most cases I am more productive in C++ - I finish the job sooner, with fewer bugs, and my code is easier to maintain. Kevin McFarlane wrote: However, I do know at least a couple of advanced C++ developers who now have considerable experience of Java and they tell me that it's more productive. Do they compare Java vs C++ (languages), or maybe Java libraries vs whatever library they use in C++? IMHO, libraries and IDE make much more influence on productivity than language itself, and many people don't make that distinction. Anyway, the single most influential factor when it comes to productivity is the process used in an organization, not programming language or tools, or even the skill level of developers. Kevin McFarlane wrote: It's interesting that you have to be very skilled in C++ to achieve equivalent productivity according to your criteria. I find that on C++ maintenance projects I spend about 40% of my time wrestling with plumbing issues - obscure runtime crashes, etc. - instead of solving business logic issues. You don't have to be a rocket scientist - you just need to be disciplined and to know your tools and libraries. It is fairly easy to avoid "obscure runtime crashes", memory leaks etc. if you stick to some good development practices. By using well known idioms, such as smart pointers, RAII, Standard containers and algorithms, it is often easier to quickly develop robust applications and libraries with C++ than with some "RAD languages". There are situations though, where I wouldn't normaly use C++. Web applications are the first thing that comes to mind (C# or Java), and also ad-hoc scripts with lots of text processing (Perl X| ).
-
ASM/C/C++ will always be around for low level development. There are 2 main areas I see where C/C++ is and will be needed: systems programming and performance-intensive applications. You're right to think that C++ is dying, but it is only dying in applications development. Why spend so much time writing large chunks of MFC/ATL code in C++ when one could do it in half the time and half the code using C#, Java, or VB.NET? That's the only place C++ is dying; outside of that, C/C++ will be around for a long time to come. As far as Longhorn goes, WinFX itself will not be reliant on Win32 in the same sense System.Windows.Forms is. Currently, managed apps use Win32 behind the scenes due to the reliance on GDI, Windows Common Controls, and some low level functionalities found only in the Win32 API. Point being, while virtually all our (managed devs) reliance on Win32 is due to using GUI apps, MS.Avalon will abolish this requirement; there will no longer be a need for controls to implement WndProc message pumping under the hood. (yay!) That said, from my understanding, the Longhorn WinFX will be available to C++ developers, but this time it will be an managed API exposed to the unmanaged world, rather than the reverse of that we have now. #include "witty_sig.h"
Where I see the actual growth in C++ use is on the CE platform where speed still matters and in real time programming.
-
Judah Himango wrote: As far as Longhorn goes, WinFX itself will not be reliant on Win32 in the same sense System.Windows.Forms is. Currently, managed apps use Win32 behind the scenes due to the reliance on GDI, Windows Common Controls, and some low level functionalities found only in the Win32 API. Point being, while virtually all our (managed devs) reliance on Win32 is due to using GUI apps, MS.Avalon will abolish this requirement; there will no longer be a need for controls to implement WndProc message pumping under the hood. (yay!) That said, from my understanding, the Longhorn WinFX will be available to C++ developers, but this time it will be an managed API exposed to the unmanaged world, rather than the reverse of that we have now. Thats really interesting. If you have a few links to share I'd to read on that. I think what you're saying is true, but what does this mean to the future of computing. LongHorn looks cool, but it doesnt really sway much from windows does it. If we're just throwing together quick code, who gets to make the "next big thing". Discovery consist of seeing what everybody has seen and thinking what nobody has thought -- Albert Szent-Györgyi Name the greatest of all the inventors: accident --Mark Twain
Check out the PDC slides/video that is available on MSDN. Also, check for websites like www.longhornblogs.com[^], look for articles in MSDN on longhorn, particularly the longhorn development center, which's been around for the past six months or so. Here are some links, http://msdn.microsoft.com/Longhorn/[^]
-
I agree with parts of this statement. At my company we have done an app or two with the .nyet methodology and we have learned enough that we will do everything possible to avoid it in the future. We did not find it to be more productive in the slightest and our quotes in the future will reflect that. __________________________________________ a two cent stamp short of going postal.
Are you guys trying to do some driver development in .net or what, first time I'm hearing someone saying .net is not productive :) I'm sure there are certain set of apps. which are better developed with some low level languages, but for business app development I would certainly think .net is the way to go.
-
Kevin McFarlane wrote: What do you mean by productivity? I mean factors such as speed of development and robustness of application. Me too. I have programmed in several languages, including C#, VB6 and Java, and found out that in most cases I am more productive in C++ - I finish the job sooner, with fewer bugs, and my code is easier to maintain. Kevin McFarlane wrote: However, I do know at least a couple of advanced C++ developers who now have considerable experience of Java and they tell me that it's more productive. Do they compare Java vs C++ (languages), or maybe Java libraries vs whatever library they use in C++? IMHO, libraries and IDE make much more influence on productivity than language itself, and many people don't make that distinction. Anyway, the single most influential factor when it comes to productivity is the process used in an organization, not programming language or tools, or even the skill level of developers. Kevin McFarlane wrote: It's interesting that you have to be very skilled in C++ to achieve equivalent productivity according to your criteria. I find that on C++ maintenance projects I spend about 40% of my time wrestling with plumbing issues - obscure runtime crashes, etc. - instead of solving business logic issues. You don't have to be a rocket scientist - you just need to be disciplined and to know your tools and libraries. It is fairly easy to avoid "obscure runtime crashes", memory leaks etc. if you stick to some good development practices. By using well known idioms, such as smart pointers, RAII, Standard containers and algorithms, it is often easier to quickly develop robust applications and libraries with C++ than with some "RAD languages". There are situations though, where I wouldn't normaly use C++. Web applications are the first thing that comes to mind (C# or Java), and also ad-hoc scripts with lots of text processing (Perl X| ).
Nemanja Trifunovic wrote: Me too. I have programmed in several languages, including C#, VB6 and Java, and found out that in most cases I am more productive in C++ - I finish the job sooner, with fewer bugs, and my code is easier to maintain. That's surprising. It's not obvious to me what features of C++ would make it easier to maintain than the other languages. Nemanja Trifunovic wrote: Do they compare Java vs C++ (languages), or maybe Java libraries vs whatever library they use in C++? One of them doesn't use a Java IDE. Nemanja Trifunovic wrote: IMHO, libraries and IDE make much more influence on productivity than language itself, and many people don't make that distinction. Yes, you have a point there. But then the languages arn't much use without the libraries. However, I think the complexity of C++ just makes it harder to do things. And it means that the average developer tends to create more havoc than they do in the other languages. That's my experience anyway. C++ can be clear and well-written but it requires a lot of effort. Nemanja Trifunovic wrote: You don't have to be a rocket scientist - you just need to be disciplined and to know your tools and libraries. Yes, and the problem is that the average programmer is not disciplined enough. You can get away with this in the other languages but not with C++. One of the major problems with C++ is that too many C++ programmers don't seem to have heard of modern C++. Though this is really a problem with programmers than with C++. However, some of the newer features do appear quite difficult to master. Nemanja Trifunovic wrote: There are situations though, where I wouldn't normaly use C++. Web applications are the first thing that comes to mind (C# or Java), and also ad-hoc scripts with lots of text processing (Perl ). Yes, at the end of the day we should use the most appropriate tool for the task in hand, rather than thinking C++ (or .NET, or Java) is the best tool for all situations. I see you hate Perl!:) We have something in common then. I've used to some extent the following languages: C, C++, VB (all variants), Java, JavaScript, C#, Pascal, Fortran, Eiffel, Python and Perl. Perl is the only one I truly hate! Kevin
-
Just curious since i am a new programmer to the field with a real "love Jones" for the C++. With C# and VB.NET, C++ developement is dying a little. As I know that it is impossible to kill the C++ language, what do you think is it s future. Just thought i throw around some food for thougt, and i am also very curious to see what people say. Discovery consist of seeing what everybody has seen and thinking what nobody has thought -- Albert Szent-Györgyi Name the greatest of all the inventors: accident --Mark Twain
First, if you are talking C#/VB.NET, you are talking .NET frameworks. You will not run C# without .NET, so that isolates the question to .NET programming. Currently in .NET, it is a pain to write code in C++. MS is helping to make life easier in thier next Visual Studio and .NET V2.0 for those that do not wish to move to another language and still use C++. After being a C/C++ programmer for about two decades, it was nice to hear there is still hope for C++ in the .NET world. That said though, I do not expect a large number of developers to be writing .NET applications using C++. The code is more steamline and easier to maintain in the other langauges (read as C# for me ;) ) and spending the extra time to build C++ application on .NET is not worth it for the types of applications you would build with .NET. As for jobs, on Windows based systems, C++ offers will be few and far between. Mainly drivers or games but usually not dealing with .NET. Some will argue, but so far the employment outlook of upper salary positions is the greatest with C#. The main concern is that you know the .NET frameworks, the langauge can be picked up in a few weeks, but the framework is huge! As for productivity, even after about 20 years of C/C++, I can build more robust stable applications in .NET/C# than I would have built in C++/MFC/Win32 and do that in a fraction of the time. Maintaining code is better and debugging is reduced to practically nothing. Anyway, the main question is your target. If you are looking into the crystal ball for C++, it will probably be Linux/Unix, or device drivers, games and CAD for Windows. If I were a new programmer coming into the field and desired a MS platform, I would be C#/.NET in a heart beat and never look back! Rocky <>< www.HintsAndTips.com www.GotTheAnswerToSpam.com