×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Java Apps Have the Most Flaws, Cobol the Least

Soulskill posted more than 2 years ago | from the pretend-to-be-surprised dept.

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

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

435 comments

so? (5, Insightful)

masternerdguy (2468142) | more than 2 years ago | (#38315764)

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

Re:so? (5, Funny)

laejoh (648921) | more than 2 years ago | (#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 (4, Insightful)

tepples (727027) | more than 2 years ago | (#38315980)

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 (5, Funny)

toadlife (301863) | more than 2 years ago | (#38316014)

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

Re:SQL too (1, Informative)

sadness203 (1539377) | more than 2 years ago | (#38316182)

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

Re:SQL too (5, Insightful)

CastrTroy (595695) | more than 2 years ago | (#38316308)

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

S.O.B. (136083) | more than 2 years ago | (#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 (1)

fotoflojoe (982885) | more than 2 years ago | (#38316330)

Thus proving the absolute dominance of ALL CAPS formatted languages over those which use the much weaker mixed-case!

Re:SQL too (1)

Anonymous Coward | more than 2 years ago | (#38316032)

Technically, the vulnerabilities are in the implementations that generate the SQL code.

Re:so? (4, Interesting)

ErroneousBee (611028) | more than 2 years ago | (#38315984)

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.

Re:so? (1)

Maximum Prophet (716608) | more than 2 years ago | (#38316290)

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.

Re:so? (2)

Archtech (159117) | more than 2 years ago | (#38316044)

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? (5, Insightful)

Anonymous Coward | more than 2 years ago | (#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:so? (2, Insightful)

Anonymous Coward | more than 2 years ago | (#38316370)

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:so? (1)

v1 (525388) | more than 2 years ago | (#38316052)

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 to the maintenance on the existing apps.

I'd also argue that just because an app is 30 yrs old doesn't mean it's clean and bug-free. It may be gigantic hairball of hacks added in layer after layer over the years.

Re:so? (1)

Relayman (1068986) | more than 2 years ago | (#38316220)

Mainframes and Power Systems computers from IBM support COBOL natively. There is no emulation.

Re:so? (-1)

Anonymous Coward | more than 2 years ago | (#38316372)

Like it really even matters anyway. COBOL sucks. End of discussion.

Re:so? (3, Funny)

luis_a_espinal (1810296) | more than 2 years ago | (#38316442)

Like it really even matters TO ME IN MY BASEMENTanyway.

There. Fixed that for'cha.

COBOL sucks.

Be that as it may, it does the job, and that's all that really matters.

End of discussion.

Oooooooooooooooooo </hands waving in macabre fashion>

Re:so? (5, Informative)

DesScorp (410532) | more than 2 years ago | (#38316314)

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.

Cobol programmers "beating on it for 30 years" (5, Funny)

Anonymous Coward | more than 2 years ago | (#38315786)

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

Technical Debt (5, Insightful)

Nittle (1356899) | more than 2 years ago | (#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.

Re:Technical Debt (2)

OneMadMuppet (1329291) | more than 2 years ago | (#38316018)

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.

You'd be very wrong about that (0)

Anonymous Coward | more than 2 years ago | (#38316020)

Marketing zombies have always been hungry for a fast release and to the devil with the quality/stability of a product. Even in the early days of COBOL this was so.

Conclusion... (5, Insightful)

Anonymous Coward | more than 2 years ago | (#38315796)

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

Re:Conclusion... (3, Insightful)

TheRaven64 (641858) | more than 2 years ago | (#38316030)

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.

Re:Conclusion... (2)

Relayman (1068986) | more than 2 years ago | (#38316320)

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

Re:Conclusion... (1)

Anonymous Coward | more than 2 years ago | (#38316240)

There is no way to compare the quality of two languages without using the same set of programmers (seasoned and unseasoned) on both languages and then create an implementation. Both languages have their merits, but what many Java coders fail to do is to be strict about their coding. However there are tools to help Java coders - Eclipse is fairly extensive in compiler warnings and you can add the Findbugs [sourceforge.net] plugin too and you will catch more errors and get a very stable system.

But it is also a difference between a programming language that is easy to extend and a language that is harder to extend. One more difference is that Java has the potential for memory leaks which Cobol doesn't. That is one of the traps Java has, but an experienced programmer can easily circumvent those traps.

And then - Java is flexible and has a lot of supporting functions (Corba, JMS etc) that Cobol lacks - or if it has them are limited to a certain environment at an expensive license which means that it's easy to interact with other systems with Java while Cobol almost always requires the other systems to adapt.

But if you think that Java is bad, then you can also look at C# - where the type-safety is crippled and you are more or less locked to a single environment. The potential for bugs in C# is bigger than for Java.

Going for Ada instead would be better, but the community support for Ada is weak.

Re:Conclusion... (0)

Anonymous Coward | more than 2 years ago | (#38316280)

That's what you get when you create a language for idiots. Shit code.

COBOL (4, Insightful)

LtGordon (1421725) | more than 2 years ago | (#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 (5, Insightful)

tajribah (523654) | more than 2 years ago | (#38315922)

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

Anonymous Coward | more than 2 years ago | (#38316038)

neocommunist unioner...

Chasing rainbows & comparing apples to oranges (1)

Anonymous Coward | more than 2 years ago | (#38316058)

Cast Software should have evaluated 'defects per function point' - not 'defects per line'.

http://www.qsm.com/resources/function-point-languages-table
http://www.castsoftware.com/resources/document/whitepapers/monetize-application-technical-debt

Re:Chasing rainbows & comparing apples to oran (0)

Nadaka (224565) | more than 2 years ago | (#38316226)

My head asplode. Function points are a uselessly subjective and abstract metric.

Re:COBOL (4, Informative)

Nutria (679911) | more than 2 years ago | (#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.

Re:COBOL (1)

Unequivocal (155957) | more than 2 years ago | (#38316376)

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!

Re:COBOL (2)

Archtech (159117) | more than 2 years ago | (#38315968)

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.

Re:COBOL (1)

PhrstBrn (751463) | more than 2 years ago | (#38316350)

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

Java == Training Wheels (1, Informative)

Anonymous Coward | more than 2 years ago | (#38315812)

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.

Re:Java == Training Wheels (4, Funny)

masternerdguy (2468142) | more than 2 years ago | (#38315868)

Operating systems are also training wheels since they provide a layer between the hardware and the programmer. Not to mention the user, so many people just use computers without learning how to code in that machine's unique punch card based assembly language. I say why have operating systems at all.

Re:Java == Training Wheels (2)

fsckmnky (2505008) | more than 2 years ago | (#38315992)

Operating systems are also training wheels since they provide a layer between the hardware and the programmer.

I would say the operating systems job is to facilitate access to devices and resources that are shared by multiple applications. In this regard, is it not so much a set of training wheels, as it is an arbiter of system resources.

Re:Java == Training Wheels (2)

tepples (727027) | more than 2 years ago | (#38316154)

I would say the operating systems job is to facilitate access to devices and resources that are shared by multiple applications.

So is the garbage collection mechanism of Java: memory is a shared resource. So is Swing: the screen is a shared resource.

Re:Java == Training Wheels (2, Insightful)

Anonymous Coward | more than 2 years ago | (#38315928)

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.

Re:Java == Training Wheels (4, Insightful)

masternerdguy (2468142) | more than 2 years ago | (#38315946)

You'd also need to engineer the trees, including designing the proteins, etc. It's like Sagan said, you must first invent the universe.

Re:Java == Training Wheels (2)

Mitchell314 (1576581) | more than 2 years ago | (#38316300)

To make an apple pie? :D (It's sad that I get the reference. Sadder still that I meet few others that do too)

Re:Java == Training Wheels (1)

Anonymous Coward | more than 2 years ago | (#38316178)

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.

Re:Java == Training Wheels (4, Insightful)

CSMoran (1577071) | more than 2 years ago | (#38316406)

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:Java == Training Wheels (0)

Anonymous Coward | more than 2 years ago | (#38316222)

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

Memory management is hard, let Lisp do it for you. When you look at it that way, how many malloc/free pairs you can balance with your massive biceps is a lot less important than you think.

Sorting is hard, let Java do it for you

Sorting is kewl! Roll your own sorting routine that runs at half the speed of the one in the standard library.

And, I say this as somebody who hates Java and OO, loves C, and has developed a greater respect (but hasn't written anything serious in) functional languages.

Re:Java == Training Wheels (1)

BlackSnake112 (912158) | more than 2 years ago | (#38316316)

I remember when java was just starting. The java programmers all excited about not having to do memory management anymore.

I asked them how do you know that things are being cleaned up correctly? How do you know that a different memory algorithm works better unless you try it?

They were like, why should we care? We can always add more memory if we need it.

Give today's java programmer a computer from the early 1980s and tell them to code on it. Could be funny.

Re:Java == Training Wheels (2, Funny)

Unequivocal (155957) | more than 2 years ago | (#38316422)

Yeah totally!! I hate that my car shifts automatically, has power locks, power steering, digital tuning on the radio and anti-lock brakes. And that freaking airbag is totally annoying, waiting to go off at ANY time. Get me back to my old 61 ford falcon with a metal steering wheel and no synchros on the gear box. Those were the days when real men drove real cars.

Interpreted languages? (1)

gmuslera (3436) | more than 2 years ago | (#38315818)

"Java EE, Cobol, .Net, C, C++ and other programming languages". Really doubt that PHP applications were checked there.

Re:Interpreted languages? (0)

Anonymous Coward | more than 2 years ago | (#38315950)

JavaScript and PHP were not in the study.

Re:Interpreted languages? (5, Insightful)

Anonymous Coward | more than 2 years ago | (#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...

Java apps are probably most widespread (5, Insightful)

coder111 (912060) | more than 2 years ago | (#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...

--Coder

Re:Java apps are probably most widespread (2)

stompertje (927012) | more than 2 years ago | (#38315942)

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

Re:Java apps are probably most widespread (1)

coder111 (912060) | more than 2 years ago | (#38316024)

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, 80% on new features. Adjust percentages accordingly depending to how much breakage and hackiness and cruft is there in the code with time. THIS part never happens.

And a complete rewrite is rarely a good idea.

--Coder

Re:Java apps are probably most widespread (2)

gstoddart (321705) | more than 2 years ago | (#38316156)

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. You'd be surprised at the number of people who don't really understand what it takes to deliver robust, functional, maintainable software -- even though ostensibly that is their job.

At a previous company, we wouldn't ever demo anything we were playing with in the lab, because it would get immediately sold/included in the spec even though we were telling them this was only in the preliminary stages and definitely not ready for product.

It makes me even more grateful for the managers/PMs I've encountered who do understand these things, because they're actually in the minority.

The languages deserve a lot of the blame (4, Informative)

Shivetya (243324) | more than 2 years ago | (#38316354)

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:Java apps are probably most widespread (0)

Anonymous Coward | more than 2 years ago | (#38316440)

The real question, is where did they learn their trade and how much experience do they have.

range of capability, expression, and process (4, Informative)

Speare (84249) | more than 2 years ago | (#38315824)

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:range of capability, expression, and process (2)

King_TJ (85913) | more than 2 years ago | (#38315958)

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 a text mode via a terminal screen?

Re:range of capability, expression, and process (1)

NoNonAlphaCharsHere (2201864) | more than 2 years ago | (#38316060)

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.

Re:range of capability, expression, and process (2)

DarkOx (621550) | more than 2 years ago | (#38316186)

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? (5, Insightful)

Murdoch5 (1563847) | more than 2 years ago | (#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.

Re:Coding Practices? (2)

NoNonAlphaCharsHere (2201864) | more than 2 years ago | (#38316192)

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.

Re:Coding Practices? (3, Informative)

metalmaster (1005171) | more than 2 years ago | (#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?

Cobol is still being used? (0)

Anonymous Coward | more than 2 years ago | (#38315866)

Where?

Re:Cobol is still being used? (4, Informative)

Lawrence_Bird (67278) | more than 2 years ago | (#38315978)

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]

More Seasoned Coder? (1)

Anonymous Coward | more than 2 years ago | (#38315872)

Some of this might be because the COBOL code was written by seasoned coders who have learned many of the lessons that newer coders are still needing to learn.

java (0)

Anonymous Coward | more than 2 years ago | (#38315916)

'there are many people going into Java now that really don't have strong computer science backgrounds,'

Honestly, as if you need to do CS to be a good programmer. I know plenty of people who write unmanaged code and blow most CS majors away.

If anything CS are mostly trained in managed and interpreted languages like Java and this should actually make Java first instead of last. But instead it's last...I think this says more about the inability of schools to keep up.

so useless (0)

Anonymous Coward | more than 2 years ago | (#38315918)

This useless study is equivalent to comparing the brands of hammers by their respective number of nails required to build a house.

You need a good teacher (1)

Anonymous Coward | more than 2 years ago | (#38315924)

Our Java teacher was a total dick. He gave us really odd examples (copied out a book), ran off and told us to get on with it. Then came back near the end of the lession with us all (excpet one geek) pulling our hair out with runtime errors. We didn't know how to fix the syntax errros we were all getting. It's a shame because Java looked good and is used on so many different OS's. We all ended up trying to get help of the resident geek.

What the programs do... (5, Insightful)

jellomizer (103300) | more than 2 years ago | (#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.

Re:What the programs do... (1)

DarkOx (621550) | more than 2 years ago | (#38316212)

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 (3, Insightful)

Alwin Henseler (640539) | more than 2 years ago | (#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...

Marketing (0)

Anonymous Coward | more than 2 years ago | (#38315952)

So let me get this straight, a company that sells tools to help you find and fix issues in code ran a study that indicated that one of the most prevalent enterprise platforms has the most issues, therefore companies using it have the most need to buy their tools? Shocking!

Computer science backgrounds? Really? (0)

Anonymous Coward | more than 2 years ago | (#38315976)

I say this as someone who has the highest respect for people who go on about comonads, dependent types, information density, p-spaces, and so forth, so don't think I'm bashing CS, but dear lord SPARE me from the production code written by ivory tower eggheads, or from the programming languages designed by people who aren't. These folks came up with Algol-60, not wretched slithering masses like COBOL. The guys who have the fortitude to actually work with COBOL for decades, however, are the ones I want to maintain my systems, because they actually prefer it in the trenches. "One more abstraction layer" involving factories of managers of contexts simply isn't how they work. Nothing wrong with abstraction, it just needs time to shake out, and I'd rather someone else did it.

I say that as someone who's writing systems in Scala using frameworks that are barely a year old, but I know and freely admit I'm building on sand, or at least a very wobbly moving platform.

Students! (2)

gman003 (1693318) | more than 2 years ago | (#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.

So, stuff made 30 years ago... (0)

Anonymous Coward | more than 2 years ago | (#38316016)

...is better than the stuff made now? SHOCKING!

Fewer != less (0)

Anonymous Coward | more than 2 years ago | (#38316042)

Fewer bugs not less bugs.

You wouldn't say "much more bugs," you'd say "many more bugs." It's the same with less vs. fewer.

Lords of COBOL hear my prayer... (2)

_0x783czar (2516522) | more than 2 years ago | (#38316082)

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 lot to learn, but I feel that much of the problems with Java may stem from the fact that it is a language often used by those who are not interested in elegant coding, simply getting something that works. This isn't to say that Java Programmers are inherently flawed, but that it attracts many that are. COBOL on the other hand... well, anyone who writes COBOL these days is probably a true Computer Scientist, and been in the industry a very long time. And yes, it's been around the block a few times. It, like Fortran, has been around for EVER (but then again... so has BASIC) and it's kinks have largely been worked out or worked around. It's not that COBOL is a better language and Java is inferior, when it's all said and done, it's the Programmer who makes or breaks the elegance of the code.

Re:Lords of COBOL hear my prayer... (1)

b4dc0d3r (1268512) | more than 2 years ago | (#38316200)

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.

Is this article from 1978? (1)

edibobb (113989) | more than 2 years ago | (#38316122)

I would venture to say that it's not possible to write a nontrivial Cobol application using good software engineering.

Just like..... (1)

hesaigo999ca (786966) | more than 2 years ago | (#38316144)

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

Fewest! (1)

Anonymous Coward | more than 2 years ago | (#38316148)

Oh, COME ON. I know there's some geek pride in not giving a damn about grammar, but really, in the headlines?

"Fewest", not "least".

(feel free to quibble with the punctuation outside the quotation marks)

huh??? Wake up!!! (3, Insightful)

Anonymous Coward | more than 2 years ago | (#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

As somebody who's worked in COBOL and Java shops.. (4, Insightful)

mwvdlee (775178) | more than 2 years ago | (#38316218)

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?

Not counting waterfall programs (2, Interesting)

Anonymous Coward | more than 2 years ago | (#38316250)

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.

Well of course! (0)

Anonymous Coward | more than 2 years ago | (#38316282)

After all, most Cobol programs haven't really been growing much and all they have had done to them is bug fixes. After 3 decades of bug fixes they ought to he rock solid by now.

What about Ruby? (0)

Anonymous Coward | more than 2 years ago | (#38316294)

Was there any analysis of Ruby tech debt, or would that just be division by zero since it's just going to be thrown away in the end?

A hammer beats them all (0)

Anonymous Coward | more than 2 years ago | (#38316332)

This just in, intensive analysis has revealed that a hammer has fewer flaws than both Java and COBOL!

Doesn't say 'buggy' (0)

Anonymous Coward | more than 2 years ago | (#38316404)

They are talking about using sound programming, not just bugs.

Valid comparisons? (1)

Phlow (2488880) | more than 2 years ago | (#38316426)

I immediately have to question the quality of the analysis for each language. If Java's analysis is more in depth than C++, it's obviously going to look worse under the microscope. Using a common value for each violation does not an equal comparison make. Also, smells like an ad...
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...