Java Apps Have the Most Flaws, Cobol the Least

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

Java == Training Wheels

[Anonymous Coward]

Java is the "training wheels" of programming languages.

Applications run in a sandbox, where inexperienced programmers can't do real damage to the system.

Then again, if you don't do real damage, how do you know how to avoid it?

Memory management is hard, let Java do it for you.

Sorting is hard, let Java do it for you...

X is hard, let Java do it for you..

So we have a generation of programmers, who are really nothing more than typists, who can bang together a half way working solution, without having to worry about memory, or other "hard" things, because Java can do it for them.

No need to worry about optimization, memory utilization, algorithm choice , etc get just it minimally working.

range of capability, expression, and process

[Speare]

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

Re:Cobol is still being used?

[Lawrence_Bird]

COBOL is probably still the largest installed codebase and remains the behind the scenes 'what makes business go' Mock if you want but can you say any of the modern darling languages will have major league applications still running 30 or 40 years from now? People also mock Fortran, yet it still rocks and has been updated to include many 'modern' features and were it not for crowd bias would be a great choice for many applications.
Ref: here [javaworld.com]

Re:SQL too

[sadness203]

SQL injection affect any and all applications that are not sanitizing user input. It's not limited to PHP.

Re:COBOL

[Nutria]

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.

Re:SQL too

[S.O.B.]

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:so?

[DesScorp]

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.

The languages deserve a lot of the blame

[Shivetya]

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.

Re:Coding Practices?

[metalmaster]

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?

Re:so?

[johnlcallaway]

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

Re:SQL too

[TheSpoom]

Where do I begin?

Using mysql_real_escape_string WILL NOT PROTECT YOU from SQL injections.

Yes, it will. SQL injection means that a user input is passed on directly to the database without escaping, so a malicious user can inject (get it?) SQL by ending the string as seen by the DBMS and adding SQL afterward. mysql_real_escape_string et al escape the possible methods of breaking out of SQL user input strings, so you can't affect the outside query.

The function is made for escaping strings incase it contains a character that would break SQL. It's up to you to filter your inputs.

Yes, and this shows you're confusing SQL injection with cross-site scripting [wikipedia.org], which does require you to filter your inputs (typically by removing HTML from user inputs where it's not necessary and heavily filtering it when it is).

PHP does not inherently promote SQL injections. Stupid design patterns do.

Agreed. That said, I wish PHP would put a little more effort into educating people about best security practices (e.g. in the manual) since a lot of developers get their start on PHP due to its low barrier to entry.

Re:SQL too

[BitZtream]

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

C/C++
ASP
ASP.NET (C#)
VB6
Java
PHP

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.