Java Apps Have the Most Flaws, Cobol the Least 435
dcblogs writes "An analysis of 745 applications for violations of good architectural and coding practices found that Java applications had the most problems and Cobol-built systems, the least. Some 365 million lines of code were analyzed by Cast Software to assess 'technical debt,' or the cost to fix the violations. Java was calculated at $5.42 per line of code, while Cobol did best at $1.26. Cobol code had the least number of violations because programmers 'have been beating on it for 30 years,' said Cast. As far as Java goes, 'there are many people going into Java now that really don't have strong computer science backgrounds,' said its chief scientist, Bill Curtis."
Re:so? (Score:5, Interesting)
COBOL has older applications, and the only way to become an old application is to start with a sound architecture. So they are probably just looking at a survivorship bias issue than a language or programmer experience issue.
It would be nice to see application age and programmer experience controlled for.
Not counting waterfall programs (Score:2, Interesting)
The problem with legacy COBOL is the occasional Waterfall program. That means that you flow from the beginning of the code to the end, occasionally skipping chucks of code with branches that lead to two different GOTO statements. A good COBOL program only uses GOTO to skip to the end of the procedure it is in, not to go to any arbitrary label in the program. You can write a good COBOL program that doesn't jump around all over the place if you bracket your code with procedure names and call those procedures properly.
My COBOL is a bit rusty or I'd give examples.
Re:Java == Training Wheels (Score:4, Interesting)
So is the garbage collection mechanism of Java: memory is a shared resource.
And that is one of the 3 or so major flaws in garbage collection, especially as implemented by Java. The memory requirements of the application are not reflected in the memory footprint being requested of the OS. This can cause _SERIOUS_ performance consequences in systems where there are multiple applications (one or more not using as shared jvm).
I saw it a few years ago in an application I worked on. The load of the application varied over time, and on different machines. Invariably though the JVM would have gigs of memory allocated for a basically idle app and cause another application on the machine to be paged, when the actual footprint requirements were fairly minor. Then the java app would scale up for a few hours. The end result was pretty much throw 10x the hardware at the problem, because convincing the JVM to actually back down the memory footprints at the appropriate times required our app to be able to poll the memory situation of the host machine and make determinations about its state, which wasn't nearly as fine grained as the OS was capable of. The resulting C version of the java app, quite literally ran on a single machine vs the dozen or so the java app required.
Re:Conclusion... (Score:5, Interesting)
Much as I dislike Microsoft, I don't think that's actually the only issue. There has been many changes that would impact code quality over the years. Setting aside the differences in language construction. There has been a broadening of the pool of people who write software, and many people have learned "how to program" so they could get a job. It seems likely that in the 1970s if you were in computers and programming it was because you enjoyed it and took pride in it. Since the 90s, there has been an influx of people for whom it is "just a job". That alone would see a substantial decline in quality, however, on top of that the "newbies" are mostly being taught how to start programming in Java now. That means for most programmers, if you are learning Cobol it's not your first language. That means you can expect the average level of experience of Cobol programmers to be much higher than that of Java programmers.
Those two factors might be enough to explain most of the difference by themselves, but there are still a host of other factors that could contribute to this result, for example, hobbyist (as opposed to professional) programmers are much more likely to create Java projects than Cobol projects because Java resources (such as do-it-yourself) tutorials are more commonly available than the equivalent Cobol resources.