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."
so? (Score:5, Insightful)
Technical Debt (Score:5, Insightful)
Conclusion... (Score:5, Insightful)
this is no assessment of Java vs Cobol, but of seasoned programmers vs half-skilled newbies.
COBOL (Score:5, Insightful)
Java apps are probably most widespread (Score:5, Insightful)
There are very few good team leads and architects who actually stand their ground and demand both quality from developers and resources to do quality work from their managers... And there are probably fewer managers who understand that quality needs time & resources...
--Coder
Coding Practices? (Score:5, Insightful)
1) Does the program work
2) Can the program be maintained
3) Can a normal developer understand your program
4) Is your program acceptably bug free
When you start breaking down coding practices into line formatting and variable names and etc... etc... etc.... your no longer programming your doing document management and personally I'm not going to write my embedded systems firmware in word so let me program.
Re:COBOL (Score:5, Insightful)
Re:COBOL (Score:5, Insightful)
Re:Java == Training Wheels (Score:2, Insightful)
By this logic we assume we shouldn't automate memory or cpu management. That's akin to asking me to create every nail, hammer, axe, and grow each tree, for me to build a house.
What the programs do... (Score:5, Insightful)
If we were to one for one recreate those COBOL apps in Java without anything new. I will bet those Java Apps will run just as well.
Re:Java == Training Wheels (Score:5, Insightful)
Good metric (Score:3, Insightful)
(..) assess 'technical debt,' or the cost to fix the violations.
Sounds like a very useful metric: the cost of fixing a bug. Or perhaps even more useful: the cost of a bug as it's released into the wild. That is: the total cost of stumbling on that bug, reporting it, discussing it, devising workarounds, producing & testing a patch, bandwidth / system maintainers' time for checking whether to apply it, actually doing so, cost of a site hack resulting from that bug, etc, etc, all of that vs. no bug in the first place.
With that as a metric I suspect even minor bugs have a massive cost if you're talking mass-used software like popular OS or the embedded software that runs smartphones etc. And considering that massive cost, it might make sense to invest massive effort trying to find bugs before software is released. At least for popular and/or mission-critical software...
SQL too (Score:5, Insightful)
Re:Conclusion... (Score:4, Insightful)
Re:so? (Score:5, Insightful)
COBOL also is very inexpressive and requires more lines of code to do the same thing, so saying "dollars per line of code" is not very useful.
In fact if you ever hear the words "per line of code" you can just assume that you're talking to someone who doesn't actually write code.
Re:Interpreted languages? (Score:5, Insightful)
Here are the languages and numbers of applications submitted for assessment.
Java EE 339
Oracle Forms 39
Oracle CRM 12
Visual Basic 14
dotNET 51
ABAP 59
C 14
C++ 9
COBOL 80
Other 11
____
total 745
339 Java, 14 C, 9 C++???
The sample size and distribution renders all statistical conclusions meaningless! Just another piece of corporate bullshit...
huh??? Wake up!!! (Score:3, Insightful)
Beside server-side, start by showing me COBOL codes that can play music, MIDI, animation, display web contents (HTML), VNC, VOIP, text chat, audio chat, video chat...
Do those also on cell phone, PDA, tablet... ... then maybe I would agree to talk seriously about some grueling comparison between COBOL and Java
As somebody who's worked in COBOL and Java shops.. (Score:5, Insightful)
As somebody who's worked in COBOL and Java shops (within the same company), let me say "Duh!".
It's not so much the language as the typical environment it's used in, combined with the experience.
People working on Cobol are usually working on mission-critical applications, Java applications are typically less mission critical.
In practice I find that the cost of a bug is usually a pretty good measure of the quality of code; I've worked on code where an hour of downtime literally costs over a million dollar and I've worked on code where a full day of downtime means some user might have noticed it and had to wait a day. There are people working on code where a few seconds of downtime means death. Want to guess what code will be the best quality?
Re:SQL too (Score:5, Insightful)
Re:so? (Score:2, Insightful)
COBOL also is very inexpressive and requires more lines of code to do the same thing
Wait, are you comparing Cobol to Java, or Lisp? Because last I checked, Java still required more lines of code to do the same thing than in more expressive languages such as Ruby or Python. The one thing nobody (who had familiarity with languages other than C/C++) ever accused Java of is being expressive.
Re:Java == Training Wheels (Score:4, Insightful)
Knowing how to do hard things doesn't mean I need to do it on a day by day basis.
I can know about a dozen sorting algorithms, it doesn't mean I shouldn't use the sort() provided by the standard library of whatever language I'm using. In fact, I'd be a retard not to use it.
True, but that only works for smart programmers like you. There's still a fair point with "if you make it too easy, riff-raff comes in".
Re:Coding Practices? (Score:5, Insightful)
And, as a developer who has done code reviews for a long time ... I've had to tell other developers the exact same thing. Because it was too fscking terse.
In our shop, you needed a comment before your function describing what it was for, magic numbers were strictly verboten, and we expected function/variable names to actually have some descriptive value so we can tell what they're for, and anything non-obvious needed a comment.
We'd still get functions with three-letter names which were meaningless, variables like "b1" and "b2" which conveyed no information whatsoever, and generally crap code. Those guys didn't last long because they couldn't understand why their code was unusable in a production codebase.
Maybe because there was no irony? I've seen a bunch of young coders who claim that their code is so elegant and obvious as to be easily maintained. I've also shoved the same code back in their face after 3 months and said "fix this", which got me a "what's it do"?
If you think there should have been irony in his statement, maybe your code isn't very good.
Always assume that someone half as clever as you think you are is going to be fixing that code with great time pressures and in the middle of a bad day ... because quite likely, even if it's your own code and you fixing it, that will be true. People who act otherwise are likely a liability in the long run.
I have seen far too many coders who thought they wrote clever code, but after six months couldn't follow their own logic in order to be able to debug it. If the original author can't debug it, WTF is anybody else going to do with it besides rewrite it? (Something I've had to do before.)
Re:so? (Score:4, Insightful)
That COBOL code has been maintained for like 30 years, it would naturally be rock solid by now.
OTOH Java is a much more recent language based on those 30 years of experience and we're supposed to have learned how to do things better.
I think it's more likely that more experienced people are working on those COBOL programs, not know-it-all grad students fresh out of education.
Re:SQL too (Score:4, Insightful)
PHP is C-like just like Java but the path the two syntaxes take would bring them further apart than closer together.
For example in PHP you would never see something like this:
final Class d = mContext.getApplicationContext().getClassLoader().loadClass(mContext.getPackageName() + ".R$" + subClassName);
It makes me sad that Google chose Java as Android's main language considering how much of a rats nest Java really is.
It's sad that it takes 16GB of RAM just to compile a build of Android. And the funny thing is it kills the whole point of Android being "open". What person has 16GB of RAM on the off chance that they might wanna compile an Android build?
Re:SQL too (Score:5, Insightful)
Oh, the irony of seeing this...
*headdesk*.
Trying to filter your inputs is a losing battle. Not commingling code and data in the first place (and thereby avoiding the underlying problem -- that things intended to be data can be treated as code when reparsed) is the simple, simple win that avoids needing to fight that battle in the first place.
Incidentally, this is the same reason why using $foo rather than "$foo" in shell scripts is so evil -- things which would otherwise be data get parsed and processed (through not just string splitting but also glob expansion), leading to unforeseen results when abused.