Well, luckily, software projects are like rock climbing:
<a href="http://www.codinghorror.com/blog/archives/000830.html">http://www.codinghorror.com/blog/archives/000830.html</a>
So no matter what pit you end up in, you should be able to get out.
I just donāt see why the length of time it takes to learn a language is related here.
C++ does take years to master, and I believe about 1-2 years of real effort and experience to be competent in. I donāt see a problem with this. It takes years to become an accomplished rock climber. It takes years (beyond actual studying) to become a good doctor. It takes years to become an accomplished plumber, I am sure, instead of the guy that SAYS heās a plumber but can only fix the 5 most common problems and has no idea how plumbing works.
I donāt want people who arenāt competent to fix my car, my teeth, my plumbing. Would you like to cross a hanging bridge designed by a new architect who just finished school, built by a company thatās new in the business (but donāt worry, they use a new method of building that takes less time to learn!)
I shall also link to Peter Norvigās (you might have heard of him) article, which bemoans a related phenomenon:
http://norvig.com/21-days.html
On of the points he makes is that according to some researches it takes about 10 years to become an expert in anything.
On a different note, does anyone know if Office 2007 is written in C# or C++ (I think we can rule out Java 
I just wanted to throw in my two cents. Iāve been programming for about 25 years, 13 of which professionally. C++ is my favorite language, I like the low-levelness of it, reminders that there is actual hardware underneath it all that is being manipulated. My go to language for something that needs to be done now (and I mean more in the one-off utility type of programming then an application one might sell and maintain) is C#. Unless of course I need to parse gigs and gigs of text in which case I reach for PERL. I guess what Iām getting at is, my goal is to use the right tool for the job (as many of your readers have eluded to.)
I agree with the 10 years to become an expert. Some tools just arenāt for beginners (and I mean to the language, not the ability to learn one)
Cheers!
Argh, I forgot to say:
I do agree whole-heartedly with the concept of setting yourself up for success, which I think this post was originally about
Mathematically speaking, using a tool that is easier to use and teach to use, youāve got better odds. But as you notice, it takes the human out of the equation, which contributes quite a large difference.
Itās a little weird that youāre comparing an old language with a new one. This is a bit like comparing assembler with C.
Then again, back in the old days I enjoyed assembler coding. There was a purity that seems lacking today. I am such a nerd.
āThe problem isnāt applications getting killedā¦ā - tcliu
Wow, congratulations on missing my point so perfectly.
If my point was the target you managed to shoot the instructor behind you (I can use inappropriate metahors too).
Still the finest, most elegant, most readable, most maintainable, most Vista enabled, best community support least prone to memory leak, buffer overrun way to develop unmanaged Native Win32 apps at the present time is Delphi (Object Pascal).
How C++ and the ilk ever became popular is incomprehensible. However finding a job in Delphi is another matter. Many excellent software has been written in it e.g Skpe. If you want to struggle on with **++ thats your choice
I love the C# pit of success.
First they erect the inpenetrable barrier of garbage collection to prevent anyone falling into the pit. Then they write MSDN articles explaining why one algorithm is fast and another algorithm is slow (even though both produce identical output) because one works in harmony with the garbage collectorās implementation and the other works against the garbage collector - thus being less efficient.
And then someone goes and does some experimental work on new garbage collection algorithms and invents a betetr system - only the previously referred to article isnāt quite applicable any more.
Abstractions are essential to any successful project (because the alternative is hand-coded machine code, given that even āassemblerā is an abstraction, if not a very high-level one) yet no abstraction is a guarantee of eternal bliss and success.
Next some idiot will claim that Java and C# are wonderful because they ādonāt have pointersā - but Iāve seen the disasters that people can create in āsafeā languages when they donāt understand things as simple as the difference between pass-by-reference and pass-by-value.
Ok, itās not the pit of success I love. Itās the look on peopleās faces when they discover those 6-foot thick 18-foot tall concrete and steel safety walls were actually just wallpaper over a frame made from jello.
Yes, C++ has many varied flaws. We know. C# also has many varied flaws. Deal with it.
Iāve been around for a while and Iāve used my share of languages and Iāve found my pit of success. Itās AutoIt.
I started programming for fun by learning C++, and I moved to Java and then to C# with .Net 1.0. I really enjoyed the switch to Java and then even more the switch to C#. But with the changes to C# in .net 2, 3 and 3.5 it started to grow more complicated by having little bits of source code all over the place. So I stopped and had some kids.
For work we needed to automate the data migration from old computers to new computers for 5000 users an I thought about using C# or VBScript when a coworker mentioned I should look at this scripting language called āAutoItā ( www.hiddensoft.com ).
Wow, talk about a pit of success, itās small powerful and easy to use, has itās own IDE with code completion, can do COM automation if needed and has a very effective and comprehensive help file. In a week we had the data migration script written tested and ready for deployment. That was last year, and now with Vista looming weāll need to do another migration soon, so we dusted off the script and gave it a go, it worked first try! What was going to be a week or two effort instead turned out to be a day of testing, awesome!
The memory footprint of AutoIt is quite small as well so itās appropriate for making small applications that run in the systray. For example if you are a weewar.com player then you may have seen weewarify written by Bruce Kroeze, itās great and it works but it consumes about 63Mb of RAM. 63Mb (30 in RAM and 33 in virtual memory) is a pretty heavy tax for something that just checks a web page every 5 or six minutes and add to that an apparent memory leak of about 100kb per hour itās even worse. Weewarify is written in Adobeās AIR which I think is why it has such a big footprint.
I figured I could do better with C# and I thought that this would be a great opportunity to get back into the C# saddle and figure out the split source file business. After a few days and about 45kb of source files I gave up, looked at my AutoIt Icon on my desktop and smiled. That same night I had my Weewar notifier working (7kb of source in 199 lines) and it only takes 504kb of ram and around 8-10mb of virutal memory, so about a 1/6 of weewarify and no memory leak.
Thanks for being my pit of success AutoIt.
Iām always amused by C++ developers that always claim theyāre āgood programmersā. I guess the bad C++ developers are sequestered away somewhere without internet access. Iāve worked with a lot of arrogant C++ developers that claim theyāre āgoodā and man, the shit code Iāve seen from them makes me shudder.
C++ is the way it is because itās very popular, very useful and old. One day C# will also be old. And it will also contain all sorts of stuff superseded by other stuff and all sorts of features that supplant other features and 1000 ways to do something, instead of the 500 ways you can do it now, with two of those ways the āproperā way and the compiler will give you warnings for the other 998.
I'm always amused by developers that always
claim they're "good programmers". I guess the bad
developers are sequestered away somewhere without
internet access. I've worked with a lot of arrogant
developers that claim they're "good" and man, the shit
code I've seen from them makes me shudder.
I think thatās true regardless of what language youāre talking about. Are you a good programmer? Who says?
I find that guys that stick with C++ for the long term tend to be better programmers and the guys who canāt really hack it, go for the flavor of the month languages. Iām pretty sure that 20 years from now C++ will still be in use. C# Iām not so sure about. Itās pretty tightly tied to .Net, right? C++ isnāt tied to anything except the general concept of a machine with addressable memory.
I progam in C daily and I canāt remember the last time I had any of the memory issues you talk aboutā¦itās called experiance also the fact that you code a simple memory manager and it detects any would be problems for you.
There isnāt much excuse for poor memory management in C++ these days with STL collections and reference counted pointers.
Iām working on a reasonably large C++ project (around 10,000 lines to date) and there isnāt a single raw pointer in it.
Quote Jim : āitās called experiance :)ā
Actually itās called āexperienceā, but i agree with you.
Assembly is a fine, very fast and efficient language that is perfectly safe when used properly by a knowledgable and skilled developer.
And of course people who canāt code in assembly are idiots and kid programmers.
I am ashamed people who donāt think about how processor, interrupt, cache, memory, bus, DMA etc. works all the time they code are calling themselves programmers.
Of course I hate any kind of abstraction which simplify the job that needs to be done.
It is unfortunate that US programmers are somewhat snobs about using C
++ or you arenāt a real programmer. I have run into a couple of Java programmers that feel the same way.
Delphi is without a doubt the most productive native compiled tool on the market. It is unfortunate that Codegear hasnāt come up with a way to deploy there code to the web in a robust manner ala Java and ASP.Net.
One person discussed the issue with memory leaks. Delphi is set up with objects having owners. The owner of an object automatically cleans up its own children objects. There a just a few object types that donāt support this, so it is very difficult to write a memory leaky program in object Pascal. Free Pascal really opens up the world of multi-platform support.
Things are getting back on track for Delphi and Object Pascal.
Thomas:
āOne person discussed the issue with memory leaks. Delphi is set up with objects having owners. The owner of an object automatically cleans up its own children objects. There a just a few object types that donāt support this, so it is very difficult to write a memory leaky program in object Pascal.ā
Not quite true from my Win32 Delphi experience. TObject has no ownership concept. Only when you get to TComponent do you get ownership, and then only of other TCompnents and inherited classes. And the typical VCL container, TList, is not typesafe as it holds pointers to TObject. As TComponent is mostly used in the visual side of the VCL, you only get automatic cleanup of form objects.
Ownership, reference counting and object control is built into the depths of .NET and is far more automatic in prevention of memory leaks.
A similar thing can be done in C++ using the Qt framework. QObject can own lists of other QObjects and will get rid of the children when the destructor is called.
As for .NET and associated languages, Iām not impressed. I write high performance C++ applications and made that decision 10 years ago after finding out Delphi just didnāt have the speed I needed (and was also very hard to interface to third party libraries, just like C++ Builder). I can fully understand why many using C# need to resort to GC.Collect. The second link at the top of the following page helps explain it. Kind of funny how C# and .NET fanboys will defend it to the death even when it clearly has problems.
Wowā¦so many topics in one comment chain, where to begin?
I started programming in VB when I was 14, C++ when I was 16, and .NET when I was 21 (I am now 25). Most of my professional experience has been in .NET, but in terms of personal experience I have more in C++ than .NET. Perhaps I am not what you would call a āsenior developerā in any language, but I do have a considerable amount of experience in both. My general take is that, yes, its slightly easier to shoot yourself in the foot with C++ than .NET, but not excessively so. However, .NET definitely has a shorter ā0 to productiveā learning curve. Regardless, I wholeheartedly agree with Joel Eidsath that āā¦smart programmers can create good products in any language and crappy programmers can create crappy products in any language.ā
As far as the concept of the āPit of Successāā¦its a nice concept, and there are some things in C# regarding that concept that I like (having to mark override methods to guard against ābrittle base classā, for example). In fact, this concept is my biggest argument against dynamic languages, whose ādo whatever you want to however you want toā ideology is a recipe for disaster. However, my biggest concern is that the concept can be taken too far, to the point where the attempt by the language to protect me from myself just gets in my way. VB.NET is the worst example of the problem that I have ever seen; and .NET in general seems to suffer from Microsoftās arrogant assumption that they can know more about my situation from the castle in Redmond than I do sitting at my desk.
I also agree with Joel and Webview that the single biggest advantage of any programming language/platform is library support. The .NET BCL is the single biggest reason why I chose to begin my professional career as a .NET programmer instead of a C++ programmer. As old as C++ is, there are a lot of libraries written for it, for just about every conceivable function. But these libraries have almost nothing in common, and knowing one library does almost nothing to help you learn the next one. With .NET, I know that no matter where I go, I have access to the BCL; and I also feel like third party libraries written in .NET are more consistent with each other than C++ libraries (probably because many .NET programmers will intuitively pattern their own libraries after the BCL, so there is a common point of reference). Yes, C++ has the STL, but it is pretty limited in scope, and although it uses classes, it is not really object-oriented, and therefore doesnāt fit very well into an object-oriented environment (Stepanov, the co-creator of the STL library, has said āI find OOP technically unsound.ā; http://www.stlport.org/resources/StepanovUSA.html).
Finally, regarding GC.Collectā¦James, the link you reference was written by someone who admittedly did not understand how garbage collection works, and most of what he said was based on wrong information and faulty assumptions. The fact is, the VAST MAJORITY of the time, GC.Collect will not help, and can in fact make things worse by disrupting the GCās auto-tuning functionality. However, it exists for a reason, and if you can demonstrate that your app doesnāt work without it but works with it, then no one has any right to argue with you. However, if you find yourself in this position, I would encourage you to open a dialouge with Microsoft; I am fairly certain that they would take a significant interest in a situation in which GC.Collect is preventing OutOfMemoryExceptions (contrary to all of their published material on the subject).
I am the maintainer and team leader for a 300k+ loc C++ project. If it works itās not because of the language, itās because the tests we run. If it fails, itās not because of the language either, itās because the tests we havenāt run.
I donāt believe that a software product will be more reliable just because itās written in a higher-level language. Itās reliable and stable because almost all of its functionality has been tried or even stress-tested.
Lets just face it, the āopennessā of C++ has made it into a general purpose, all-features language, adopting multitudes of bad practices, including the above mentioned glitches.
The are other better planned languages out there, such as Delphi.
In fact, I often complain that I canāt compile very bad bugs in Delphi!
Oh right, most āgurusā/developers out there think it is a toy language, well go on, make life harder for yourself.
Kind regards.