SlowMan said:
Well, I haven't experienced it. Actually there was an issue one time(.NET garbage collection is worse than Java garbage collection), but memory profiling tools make fixing the problems easy.
Now try to memory profile C applications; it's a nightmare. I know, because I went through that hell.
Well, having years of experience with C-based languages and Java, on the desktop, server, embedded and mobile platforms, I can tell you I have.
Java profiling and debugging tools have historically been crude in comparison to their C counterparts. A reasonable example is the process for profiling an Android application vs. profiling an iOS application. The quality of the tools is a night and day difference. Several years ago when J2ME, Brew, and Symbian were popular it was pretty much the same thing, though the Brew toolset was not very good at all. It was still better than the J2ME tools available. J2ME made a number of problems very obvious, as the VM could be dramatically different between devices. For example, some devices had compacting garbage collection, while others did not. On mobile and embedded devices, this can matter - A LOT. In those days - and today with Android - to profile and troubleshoot some problems you need tools that simply do not exist and have to be written from scratch (yes, sometimes in C).
I profile applications in both Java and C regularly. The quality of the tools for C is often considerably better. I do not know why it would be a "nightmare".
SlowMan said:
The schools don't even teach C++ anymore. The new breed of coders only know managed code.
I am not clear what you mean by "managed code" here.
SlowMan said:
I can testify that writing garbage collected code is 4~5 times faster than writing C++ code.
Your definition of productivity seems to be different than mine. You seem to be measuring productivity by the amount of code written or something similar. To those who may be a little lost here, in computer environments that do not support the concept of "garbage collection", the software engineer must allocate memory before using it, and then free that memory when done. Garbage collected environments allow some component of the system to do this on the engineer's behalf, taking those "allocate" and "free" steps off the engineer's plate. The garbage collection system can work a number of different ways, if you are interested in learning more you can check out the wikipedia page mentioned below. C-based languages typically do not have garbage collection, while java does (it's more complex than that, as garbage collection is a runtime rather than language feature, but anyway...).
I would measure it by the amount of defect free code, or by a metric based on the cyclometric complexity of the resulting code - more code is not better, less complex code is better. Quality rather than quantity.
The F-35 program has instituted practices and processes with the software engineering institute to cut down on the complexity of their code while improving quality, so they may agree.
But I do not see what garbage collection has to do with the software on the F-35.
Lack of garbage collection impedes programming speed. In the modern development scene speed is everything, you have as little as two months to get something out.
There are many, many issues with using garbage collected environments for embedded/RT systems and life-threatening applications. The wikipedia page for garbage collection summarizes some of them:
http://en.wikipedia.org/wiki/Garbage_collection_(computer_science)
Garbage collection is not typically deterministic, which is a major reason it is not used for these kinds of applications.
Two months would be a luxurious amount of time for a complex software system. I would envy that team.
Though again, I am not sure how this pertains to the F-35.