Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Bug Businesses Java Programming The Almighty Buck

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."
This discussion has been archived. No new comments can be posted.

Java Apps Have the Most Flaws, Cobol the Least

Comments Filter:
  • so? (Score:5, Insightful)

    by masternerdguy ( 2468142 ) on Friday December 09, 2011 @12:42PM (#38315764)
    That COBOL code has been maintained for like 30 years, it would naturally be rock solid by now.
    • Re:so? (Score:5, Funny)

      by laejoh ( 648921 ) on Friday December 09, 2011 @12:54PM (#38315898)
      COBOL is written ALL CAPS. That's why it's more stable. The characters don't fall down so easily when they are ALL CAPS. Java has to many funny characters like { and }. They have no stable base and tilt over to easily. Compare { with PERFORM and } with END-PERFORM and you know enough!
      • SQL too (Score:5, Insightful)

        by tepples ( 727027 ) <tepples@gmail.BOHRcom minus physicist> on Friday December 09, 2011 @01:00PM (#38315980) Homepage Journal
        SQL is also traditionally written in ALL CAPS, yet look at all the SQL injection vulnerabilities that have been used to break into high-profile web sites.
        • Re:SQL too (Score:5, Funny)

          by toadlife ( 301863 ) on Friday December 09, 2011 @01:03PM (#38316014) Journal

          SQL injections typically affect php apps, and php has syntax somewhat similar to java. Therefore the GP's theory remains solid footing.

          • Re: (Score:2, Informative)

            by sadness203 ( 1539377 )
            SQL injection affect any and all applications that are not sanitizing user input. It's not limited to PHP.
            • Re:SQL too (Score:5, Insightful)

              by CastrTroy ( 595695 ) on Friday December 09, 2011 @01:25PM (#38316308) Homepage
              The mysql_escape_string, mysql_real_escape_string, mysql_i_mean_it_this_time_escape_string thing probably has a lot to do with the sql injection vulnerabilities, not to mention that before mysqli, you couldn't even use prepared statements. That and the number of php "tutorials" on the web that don't even mention mysql_real_escape_string or prepared statements, leads to PHP being particularly bad. Add that to the fact that PHP is what is avaiable on cheap web hosts, and that it's the language of choice for many newbie programmers, and you go a recipe for disaster. The SQL injection problem isn't limited to PHP, but PHP probably has the biggest problem with it.
          • Re:SQL too (Score:5, Informative)

            by S.O.B. ( 136083 ) on Friday December 09, 2011 @01:19PM (#38316228)

            SQL injection attacks can affect any web based application in any technology so long as user input is not escaped or is used non-prepared statements.

            PHP is no more or less vulnerable.

            • Re:SQL too (Score:5, Funny)

              by tbannist ( 230135 ) on Friday December 09, 2011 @01:35PM (#38316448)

              Well, I have never even seen any vulnerable Cobol web applications, have you? There are probably millions of vulnerable PHP applications.

              And I'll have none of your crypto-fascist "percentage" nonsense. We only deal in hard FACTS. The kind that use only capital letters. Although, it is true that PHP is more secure than Java by deisgn. Since PHP has 3 capital letters and is symmetrical, although they should probably change it's name to BHB for true symmetrical redundancy.

            • Out of the box, PHP's mysql interface makes you concatenate/interpolate strings yourself to compose the SQL, and you have to manually escape parameters. In short, it requires extra work for programmers to do things right. All of those "Teach Yourself PHP in 24 Hours" books aren't going to help, either.

              In contrast, almost all other programming languages make it easy to do the right thing. For example, Perl DBI and JDBC both encourage you to use '?' placeholders, which are automatically filled in by parame

          • Re:SQL too (Score:4, Insightful)

            by DigitalisAkujin ( 846133 ) on Friday December 09, 2011 @02:33PM (#38317182) Homepage

            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, Informative)

              by BitZtream ( 692029 ) on Friday December 09, 2011 @04:00PM (#38318300)

              I've developed applications which have > 10k users in the following languages:

              ASP.NET (C#)

              While my prefered language for getting 'real work' done is C/C++. Over the years I've learned that the only real reason Java applications suck is because Java is easy to deal with (Like VB) so it brings in a metric fuckton of really shitty managers who think they are developers ... who write REALLY REALLY REALLY shitty apps.

              Until about 3 years ago, you would not catch a shitty PoS java app on my machine, slow bloating piles of crap ...

              Then I was forced to write a java servlet because I needed a good SVG renderer, and Batik is about the only one that doesn't suck ass.

              From that experience I learned that Java indeed IS nice, and the JVM (on Windows and OS X at least) is pretty damn impressive (not perfect, but still impressive). I quickly learned that writing fast, quick to load Java apps is really trivial. In fact, they only way I can make a Java app suck is by doing things that I would never allow to be committed to a revision control system I'm in charge of. I am currently incapable of writing a 'slow bloated java app'. It takes me EFFORT to make Java suck. When you see a shitty Java app, you are seeing truely inexperienced programmers who have done things SO AMAZINGLY wrong that you really shouldn't consider them programmers. They aren't, they are just people who wrote some java code.

              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?

              So Open Street Maps isn't Open because I only have 5 gigs of ram in the machine I want to use to process their massive map database into image tiles? I'll have to let them know, here I was, I thought it was just mean for not meeting the requirements of processing a REALLY LARGE complex system that requires extensive optimization in order to actually be useful.

              I'm sorry, this is just silly. Open doesn't mean you can use it, it means there are no arbitrary exclusions or inclusions. Open doesn't mean 'meant for everyone and everything for 0 cost'. I'm sorry you're idea of open has been tainted by GPL fanboys, but reality is a little different than what you think it is. Its not my fault you don't have enough RAM to build a system as complex as Android. I say that as what I can only describe as an 'android hater'. I REALLY want to use it for a couple projects, but its just not up to my requirements for lag free operation ... none the less, its really fucking retarded to call it 'not open' because you can't afford the build requirements.

              Finally, its fairly trivial to build on less than 16GB of ram, as long as you don't mind waiting a while ... you do know what swap is for, right? I'm sorry you don't understand how things work in the real world, but you don't actually have anything to complain about here.

              • Rule of thumb: anybody who writes as if C/C++ was a programming language does not understand C++ and probably not C very well.

      • Are you sure about that? Java has a lower center of balance.
      • Re:so? (Score:4, Funny)

        by Adrian Lopez ( 2615 ) on Friday December 09, 2011 @02:20PM (#38317028) Homepage

        Java has to many funny characters...

        One of your o's fell off, which proves your point.

    • Re:so? (Score:5, Interesting)

      by ErroneousBee ( 611028 ) <neil:neil h a n c o c k . c o .uk> on Friday December 09, 2011 @01:00PM (#38315984) Homepage

      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.

      • Good point. I would also add that any new COBOL programs at going to look like the old programs, but only the ones that survived.

        The average COBOL programmer is also much older than the average Java programmer.
    • A Gartner report back in 1990 or thereabouts said that something like 100 billion lines of corporate COBOL existed. By 2010, that had doubled to about 200 billion.

      That's not surprising, as many core industrial, financial, commercial and government computing systems are written in COBOL and run on mainframes. The number, size, and importance of those systems is not decreasing but rather sharply increasing.

    • Re:so? (Score:5, Insightful)

      by Anonymous Coward on Friday December 09, 2011 @01:06PM (#38316046)

      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: (Score:2, Insightful)

        by Anonymous Coward

        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: (Score:3, Funny)

        by sycodon ( 149926 )

        No everyone thinks it's a good thing to write a entire program in one huge line:

        import sys,os,re,fileinput;a=[i[2] for i in os.walk('.') if i[2]] [0];[sys.stdout.write(re.sub('at','op',j)) for j in fileinput.input(a,inplace=1)]

        Now, that's what I call maintainable!...cough.

    • by v1 ( 525388 )

      That COBOL code has been maintained for like 30 years, it would naturally be rock solid by now.

      I don't think they were comparing mature cobol apps with new java apps. Or if they were, they shouldn't have been. There are still new apps being written in cobol. There are still some companies running emulated cobol two or more levels deep due to hardware changes where they wanted to continue using some existing apps, and those companies are still requiring fresh new code to be written for them, in addition t

    • Re:so? (Score:5, Informative)

      by DesScorp ( 410532 ) <DesScorp.Gmail@com> on Friday December 09, 2011 @01:26PM (#38316314) Homepage Journal

      COBOL is a good language for what it's intended for... business software... but Comp Sci people didn't like it because it wasn't "elegant", which is pretty much an argument of style, anyway. I liked COBOL just fine in college, and it made sense for its intended purpose. I find that most of the people that mock COBOL have never coded in it. It's a solid language, well-liked by those that use it. If you're a programmer and you don't like it, well, then I'd advise not taking a job programming it. Plenty of other C/C++/Java, etc jobs out there.

      • Re:so? (Score:5, Informative)

        by johnlcallaway ( 165670 ) on Friday December 09, 2011 @02:07PM (#38316856)
        I wrote COBOL code for 15 years, and agree 100%. I could churn out complex multi-level reports in half a day that WORKED because I had been doing it so long and had a method. My only complaint with COBOL was that it didn't support recursion or dynamic arrays. Most complaints were that you had to type a lot, but what most people didn't realize is that good data design up front allowed for the use of commands like 'move corresponding' and 'add corresponding' to make the actual program code simpler. I've noticed with modern coders some of the same tendency to make the data definitions fit the code instead of the other way around.

        I now write in Java, and spend most of my days rewriting very poorly written C++ into Java. Not because C++ isn't a good language, but because the people that wrote the code had no idea how to write code, let alone C++. Overly-complex designs for simple tasks, using flags instead of try/catch blocks for error handling, and using codes (i.e. if flag = 1) instead of enumerators or constants to make it legible.

        I also know that my code three years ago is nowhere as 'good' as the code I write now. It's easy to teach someone how an if..else statement works, or the difference between static and class objects. But to help them to understand principles, like when to use static or class methods or objects, they really need to write code for awhile and get a grasp on the concepts. And as I write more and more, I learn new little things. Plus the language itself advances. After about 10 years of coding in Java, I'm pretty decent at it now. But I'd say my first 2-3 years resulted in some pretty bad code, and the next 5 some that was OK, but could be improved. I still look at code I do today with a critical eye, always wondering what I could do to make it easier to write and maintain and more efficient.

        I had a financial engineer come up to me a few months ago that didn't understand why he just shouldn't use static methods and objects for everything. He read the book, he knew how to write code. What was all the fuss about anyway?

        I just sighed and did my best to explain to him in 15 minutes what I have learned over the last decade. I think he understood as he walked away, but his boss is not my boss, and I don't have to support his code. The rest of the financial engineers use SAS, so I probably should care since I'm sure I'll be the one to support it when he leaves....

        But it's probably easier for me to fix it then than to try and beat good coding practices into him now. I've got my own schedules to keep....
        • by s73v3r ( 963317 )

          using flags instead of try/catch blocks for error handling

          It was my understanding that, at least up until recently, try/catch blocks, and exceptions in general, were not well supported in C++, and did not work well. Has this changed in the long while since I looked, or was I just misunderstood?

          • using flags instead of try/catch blocks for error handling

            It was my understanding that, at least up until recently, try/catch blocks, and exceptions in general, were not well supported in C++, and did not work well. Has this changed in the long while since I looked, or was I just misunderstood?

            No, you're right. I'd say the present state of affairs is that they're well-supported by major tools... but that the fundamental design of exception handling is fraught with subtle pitfalls, and as a result many (most?) C++ shops still avoid them.

            One example is that there is basically no way to safely write a destructor that may throw an exception, but if your destructor does anything at all of substance (and RAII means many of them do), then you may not even know whether your code may throw. You can wr

    • Re:so? (Score:4, Insightful)

      by Joce640k ( 829181 ) on Friday December 09, 2011 @01:55PM (#38316706) Homepage

      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.

  • by Anonymous Coward on Friday December 09, 2011 @12:44PM (#38315786)

    So... masturbation makes you a better programmer? That explains a lot about guys living in their moms' basements.

  • Technical Debt (Score:5, Insightful)

    by Nittle ( 1356899 ) on Friday December 09, 2011 @12:45PM (#38315794)
    In today's agile world, who gets time to maintain technical debt. How does paying technical debt ever give your app that new feature that your marketing department is pushing for -- to have out by tomorrow. I think the rules have changed in how companies push their software development organizations to deliver software. That may be the biggest reason that quality is different than it was. That and the other programs have been worked on forever.
    • It's simple - you add up the cost of outages (revenue and reputation), ops overhead (support staff and time lost using clunky UI's) and correcting mistakes caused by errors in the code, then you compare it against the cost of resolving the technical debt. If you're constantly getting told it's not possible then there are either good financial reasons for it, or the project manager needs to start writing business cases which don't suck.
    • Used by people who don't understand what debt is.

      This is just a vanilla resource allocation problem. Do you spend a dollar to write bug free code or do you add an extra feature. There is only so much money, only so many developers, testers and only so much time.

      The number of places where bug free is the choice are small and they are specialised. Most places features win. Features means sitting on top of huge bloated frameworks which are also chock full of bugs.

      So, the languages just represent the environmen

  • Conclusion... (Score:5, Insightful)

    by Anonymous Coward on Friday December 09, 2011 @12:45PM (#38315796)

    this is no assessment of Java vs Cobol, but of seasoned programmers vs half-skilled newbies.

    • Re:Conclusion... (Score:4, Insightful)

      by TheRaven64 ( 641858 ) on Friday December 09, 2011 @01:04PM (#38316030) Journal
      That's more or less what I thought. Most COBOL programmers these days have been doing it for decades, or have learned COBOL after learning half a dozen other languages and realising that the skill shortage means anyone who can stomach writing COBOL is massively overpaid. In contrast, schools and universities are churning out Java 'programmers' in vast quantities. You can get a cheap person who kind-of knows Java very cheaply. There aren't many programmers who kind-of know COBOL, you get either either experienced COBOL programmers or experienced programmers who can easily learn COBOL.
      • I disagree. This is a comparison of good programming techniques (structured and modular code as taught in the '70s) versus the newbie approach, sponsored by Microsoft, of just throwing stuff together and seeing if it works.

        The bad code of today is a far higher percentage of the code than it was in the '70s and '80s. All you have to do is read The Daily WTF [thedailywtf.com] to see that. I looked at some "new" code the other day and it was riddled with GOTOs. I was taught GOTOless programming in the early '70s and still use
        • Re:Conclusion... (Score:5, Interesting)

          by tbannist ( 230135 ) on Friday December 09, 2011 @01:49PM (#38316654)

          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.

        • by Jeremi ( 14640 )

          The bad code of today is a far higher percentage of the code than it was in the '70s and '80s. All you have to do is read The Daily WTF to see that.

          Yes, it's amazing that almost all of the code posted The Daily WTF is bad code. Who would have guessed?

  • COBOL (Score:5, Insightful)

    by LtGordon ( 1421725 ) on Friday December 09, 2011 @12:47PM (#38315810)
    I would imagine that the reason Cobol code has so few bugs is because the vast majority of it was written years ago and any bugs that might have been there have been fixed already. I'd be more interested in a study that compares only new code that hasn't had the benefit of years of maintenance and eyeballs.
    • Re:COBOL (Score:5, Insightful)

      by laejoh ( 648921 ) on Friday December 09, 2011 @12:52PM (#38315876)
      Let me, an old Cobol fart, just answer by repeating: "As if requirements never change".
    • Re:COBOL (Score:5, Insightful)

      by tajribah ( 523654 ) on Friday December 09, 2011 @12:55PM (#38315922) Homepage
      Besides, if you have a 1000-line Java program and a 10000-line COBOL program doing the same task, which is going to have less bugs per line? :-)
      • Re:COBOL (Score:5, Informative)

        by Nutria ( 679911 ) on Friday December 09, 2011 @01:17PM (#38316190)

        Having programmed both in COBOL and C, it's my experience that COBOL is less buggy since it doesn't encourage Cleverness, but has rich features like 88 Level conditionals and built-in sorting and reporting. Not to mention structured programming that haters think don't exist.

      • Yeah or a 100 line Rails app..

        Forget that the Rails framework still carries a very high bug load - but your 100 lines can be virtually bug free!

    • I would imagine that the reason Cobol code has so few bugs is because the vast majority of it was written years ago and any bugs that might have been there have been fixed already.

      That turns out not to be the case. A Gartner report back in 1990 or thereabouts said that something like 100 billion lines of corporate COBOL existed. By 2010, that had doubled to about 200 billion.

    • I would say not only that, but anything that was written in COBOL that was buggy trash has been thrown away and replaced with newer software. The stuff that still exists has stood the test of time, and there is no business reason to get rid of something that already works.

      If you did the same analysis 20 years ago, the numbers of COBOL would look similar to the numbers of Java today. I'd bet money, in another 20 years, something else will inevitably replace Java, and Java will look as bug free as COBOL doe

  • "Java EE, Cobol, .Net, C, C++ and other programming languages". Really doubt that PHP applications were checked there.
    • by Anonymous Coward on Friday December 09, 2011 @01:08PM (#38316078)

      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...

  • by coder111 ( 912060 ) <{moc.liamrr} {ta} {redoc}> on Friday December 09, 2011 @12:48PM (#38315822)
    If you look at enterprise world (which is what they analyzed) you'll see that either Java or C# are most widely used. Which means most new/inexperienced/crap developers get to work on these projects in Java and C#. Which again means most mistakes & hacks & silliness. All the speciality stuff using exotic languages gets better people. And cobol applications in use today are either really mature and good quality or discarded years ago.

    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...

    • Every manager knows that quality needs time & resources. It's just that managers may have different priorities than developers: "give me 80% of functionality tomorrow, rather than 100% in 6 months".
      • I do understand the wish to shorten time-to-market as much as possible. I do agree with the concept. Problem with this way of thing however is that missing 20% is never done. Technical debts keep piling up and they are never really repaid. Or worse, someone starts a Version 2 rewrite disaster, which takes 5x more time and resources and ends up a worse project.

        That's why I'd agree to rushing Version 1 release. But after that is out, spend at least 20% of the resources on refactoring/tidying up old rubbish
      • Every manager knows that quality needs time & resources.

        I'm not sure they all do know that ... some of them are completely ignorant of 'quality' as a concept so don't see why we spend time testing ... some feel that it comes from small budgets, short timelines, and a lot of howling about why it's not ready yet ... some think they can just demand a flying car today and have it by Wednesday.

        I once said to a PM that 9 women couldn't have a baby in a month, and he didn't understand what I was telling him.

    • by Shivetya ( 243324 ) on Friday December 09, 2011 @01:28PM (#38316354) Homepage Journal

      If I put a room five JAVA/C# developers on doing a particular task I am most likely to end up with four if not five different implementations. With the five COBOL (or similar "old school" language) I might end up with two, on the outside three.

      I always though the big feature of certain "object oriented" language was their re-usability but even in house far too many roll their own and have a litany of excuses as to why what they did was better than someone else. Don't even get started on libraries. Standards do reign people in but they don't hit at the other problem, just doing simple work with files is no fun compared to the simplicity it is in COBOL or other business languages. Hell, dealing with money, forget it, COBOL and business languages do that very well. I can search for handling decimal positions and such math for other languages and I wince at all the "try this" I get back.

      One team at my friend's shop has a person whose entire job is fixing values in the data base because the "web" guys keep screwing up simple things. His words, not mine. However it still comes to languages which don't provide simple solutions but instead give you so many solutions you actually end up with worse off.

  • by Speare ( 84249 ) on Friday December 09, 2011 @12:48PM (#38315824) Homepage Journal
    Sure, it's easy to conclude that teams writing COBOL programs have more development discipline, but there's also something to be said about the overall complexity of the languages. There are huge differences in the range of capability in the core language, the range of different expressions to solve the same problem, and the range of handling different modes of process (serial, concurrent, federated, etc.).
    • by King_TJ ( 85913 )

      Exactly! The first thing that came to mind when I read this is; What does your typical COBOL program actually do? What does your typical Java program do?

      Is anyone even working with graphics and/or sound via COBOL? An awful lot of potential bugs crop up that have nothing to do with the core logic in an application (the math calculations it does, the text string it searches for in a file, etc.). It seems to me like COBOL gets to take a pass on ANY of these bugs, since it's going to be running in basically

      • Indeed. The SIZE of the problem domains is apples and oranges, too. Then there's the notion that most Java programs are going to be event driven (at least to some extent), while the Cobol programs are mostly going to be batch oriented.
      • by DarkOx ( 621550 )

        Does CICS count as graphics? If so yes certainly. There is also Fujitsu COBOL.NET out there so if there are any actual users I suppose people might be using just about any of that massive library from COBOL.

  • Coding Practices? (Score:5, Insightful)

    by Murdoch5 ( 1563847 ) on Friday December 09, 2011 @12:48PM (#38315830)
    The only real coding practices that mean anything are:

    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.
    • I SWEAR I'm not making this up: a manager once criticized my code as being too terse: "people have to read and understand it before they can modify it". He saw no irony in that statement.
      • by gstoddart ( 321705 ) on Friday December 09, 2011 @01:41PM (#38316530) Homepage

        I SWEAR I'm not making this up: a manager once criticized my code as being too terse

        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.

        "people have to read and understand it before they can modify it". He saw no irony in that statement.

        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:Coding Practices? (Score:4, Informative)

      by metalmaster ( 1005171 ) on Friday December 09, 2011 @01:33PM (#38316424)

      line formatting and variable names fit into code maintenance.

      If you write a blob of code without descriptive variable names how do you expect to maintain it? How do you expect someone else to quickly read and decipher it?

  • by jellomizer ( 103300 ) on Friday December 09, 2011 @12:57PM (#38315938)
    Most COBAL applications while do a lot of processing they are not required to do much in terms of advanced coding. We expect more out of Java Programs then we do with Cobal. Java Apps need a cool fancy UI that handles every users whim. While the COBOL app has a menu you type that Item fill those fields and the record and hit process and wait.

    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.
    • by DarkOx ( 621550 )

      There are just as many JAVA apps that do essential no-ui at all and are just web backends. That might even be the majority of java code now.

  • Good metric (Score:3, Insightful)

    by Alwin Henseler ( 640539 ) on Friday December 09, 2011 @12:58PM (#38315948)

    (..) 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...

  • by gman003 ( 1693318 ) on Friday December 09, 2011 @01:01PM (#38315990)

    Java is one of the languages currently used by students (along with VB.net and sometimes C++ or C#). I would not be surprised if the high relative bug count is due primarily to the number of inexperienced programmers working in Java.

  • I'm not terribly surprised that Java ranks so low. I myself write in Java a lot, and greatly enjoy it's syntax, (although I don't have as much respect for it as I do for C, C++ & Objective-C. Maybe it's just psychological, but that JVM will always make me feel like the outcome is inferior). Java has exploded over the last decade, and is used by many who would not call themselves Programmers. They program in Java, but they lack the mindset, and passion of a true computer Programmer. I still have a l
    • You don't need a JVM, you can go directly to machine code [gnu.org].

      Otherwise I agree, I've felt that a lot of Java code I read is equivalent to scripting (think WSH / VBScript). Or it has been built point-and-click style via Eclipse with little thought to what actually needs to happen. Some is good, it's just that a lot isn't.

  • The say most viruses are for windows, yet when you consider the amount of windows machines vs any other, for sure there will be more chances that someone wants to hack it vs. a less used system. The same can be said for a language that is less used then any other...the more language you use the more likely someone can make an error in the syntax.....so for 1 billion lines of code in java vs. the million lines of code in cobol...guess what....apples and oranges...

  • huh??? Wake up!!! (Score:3, Insightful)

    by Anonymous Coward on Friday December 09, 2011 @01:18PM (#38316210)

    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

    • by geekoid ( 135745 )

      I've done all that with COBOL., except the portable stuff. Not that I couldn't.

      http://www.netcobol.com/cobol-compiler-for-net/ [netcobol.com]

      Anyways, you comparison doesn't matter. It's not which is a better language, or which can be used to build more shit.

      The shit that's out there, COBOL has fewer bugs...which is too be expected.

      It doesn't mean Java is useless.

      "Beside server-side,"
      yeah, I like how to try to move the goal post to fit your statement.

  • by mwvdlee ( 775178 ) on Friday December 09, 2011 @01:18PM (#38316218) Homepage

    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?

  • by Anonymous Coward

    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 procedur

  • by luis_a_espinal ( 1810296 ) on Friday December 09, 2011 @01:43PM (#38316560) Homepage

    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."

    This is indeed true, but, as a Computer Scientist, I don't necessarily agree that one truly needs a CS background for most enterprise computing related tasks. What a person needs is technical depth, analytical skills and, mucho importante, organizational/spatial skills that allow a person to design and/or work with large amounts while coping - efficiently - with rapid code change (read as "can write code of sufficient quality under pressure, combined with an ethic of never delivering shit without sacrificing deadlines"). People with MIS and Computer-based Art degrees have also done well without a CS background... and there are people with CS backgrounds that should never be allowed to be near a keyboard.

    I would change Mr. Curtis statement to the following: many people going into Java (and .NET and PHP and most other stacks related to Enterprise Computing), for one reason or another, end up lacking the technical depth necessary to be a good programmer/software engineer. Combine that with the ever changing face of modern enterprise computing and you can see why the greater technical debt cost per line of code.

  • by HighOrbit ( 631451 ) on Friday December 09, 2011 @03:57PM (#38318280)

    While COBOL supposedly got OO capability in 2002 acoording to wikipedia, I would bet most COBOL is rather straight forward procedural code that is easy to follow and understand. The 'java way' on the other hand is to encourage over-abstration to the point of absurdity. There is a joke hello world at http://foreigndispatches.typepad.com/dispatches/2008/09/hello-world-in-java.html [typepad.com] that really isn't far from the truth about how java programs are actually implemented by some coders. I seems some java coders think: Why just print a string when you could instead instantiate a new string-writer class implementing an abstract string writer factory with a text-writer interface? And instead of hardcoding a constant value, use an xml configuration file, even if you will never actually change the value.

If graphics hackers are so smart, why can't they get the bugs out of fresh paint?