Java Apps Have the Most Flaws, Cobol the Least

so? by masternerdguy · 2011-12-09 04:42 · Score: 5, Insightful

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

--
To offset political mods, replace Flamebait with Insightful.

Re:so? by laejoh · 2011-12-09 04:54 · Score: 5, Funny

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!
Re:so? by ErroneousBee · 2011-12-09 05:00 · Score: 4, Interesting

COBOL has older applications, and the only way to become an old application is to start with a sound architecture. So they are probably just looking at a survivorship bias issue than a language or programmer experience issue.
It would be nice to see application age and programmer experience controlled for.

--
**TODO** Steal someone elses sig.
Re:so? by Archtech · 2011-12-09 05:06 · Score: 2

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.

--
I am sure that there are many other solipsists out there.
Re:so? by Anonymous Coward · 2011-12-09 05:06 · Score: 5, Insightful

COBOL also is very inexpressive and requires more lines of code to do the same thing, so saying "dollars per line of code" is not very useful.
In fact if you ever hear the words "per line of code" you can just assume that you're talking to someone who doesn't actually write code.
Re:so? by TheGreatOrangePeel · 2011-12-09 05:21 · Score: 2

Are you sure about that? Java has a lower center of balance.
Re:so? by DesScorp · 2011-12-09 05:26 · Score: 5, Informative

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.

--
Life is hard, and the world is cruel
Re:so? by Anonymous Coward · 2011-12-09 05:30 · Score: 2, Insightful

COBOL also is very inexpressive and requires more lines of code to do the same thing
Wait, are you comparing Cobol to Java, or Lisp? Because last I checked, Java still required more lines of code to do the same thing than in more expressive languages such as Ruby or Python. The one thing nobody (who had familiarity with languages other than C/C++) ever accused Java of is being expressive.
Re:so? by luis_a_espinal · 2011-12-09 05:35 · Score: 3, Funny

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? by Waffle+Iron · 2011-12-09 05:37 · Score: 2

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.
Gartner actually grossly underestimated the totals: Those numbers were just a count of the boilerplate declarations from the couple of dozen COBOL programs they looked at.
Re:so? by sycodon · 2011-12-09 05:49 · Score: 3, Funny

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.

--
When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
Re:so? by Joce640k · 2011-12-09 05:55 · Score: 3, Insightful

That COBOL code has been maintained for like 30 years, it would naturally be rock solid by now.
OTOH Java is a much more recent language based on those 30 years of experience and we're supposed to have learned how to do things better.
I think it's more likely that more experienced people are working on those COBOL programs, not know-it-all grad students fresh out of education.

--
No sig today...
Re:so? by johnlcallaway · 2011-12-09 06:07 · Score: 5, Informative

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

--
I rarely read replies, it's my opinion and if you thought about your opinion a little more, I'm OK with that.
Re:so? by Adrian+Lopez · 2011-12-09 06:20 · Score: 3, Funny

Java has to many funny characters...
One of your o's fell off, which proves your point.

--
"In prison you just have to shut your eyes and take it. Here you have to shut your eyes and give it."
Re:so? by Bill,+Shooter+of+Bul · 2011-12-09 06:21 · Score: 5, Funny

Yes, its difficult to keep up with the suicide rate.

--
Well.. maybe. Or Maybe not. But Definitely not sort of.
Re:so? by phorm · 2011-12-09 06:41 · Score: 2

Many times I've had to produce a nice report-like output and missed COBOL. It was *great* for that. In the same mind, other languages are great for other things.
I'm sure people back in the day wrote crappy COBOL code, but nowadays with fast CPU's and *huge* libraries (not to mention probably a lot more devs), it's easier to write a massive POS with major vulnerabilities.
Re:so? by s73v3r · 2011-12-09 06:49 · Score: 2

I wouldn't say age is good, but there is a higher chance that an aged programmer has experienced many problems throughout their career, has understood them, and has seen what it takes to fix or prevent them. They've aged like fine wine.
This should in no way be taken to ignore the many programmers who have had much time, but really it's just one or two years of experience repeated over and over again. These ones have aged like milk.
Re:so? by s73v3r · 2011-12-09 06:57 · Score: 2

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?
Re:so? by swillden · 2011-12-09 13:05 · Score: 2

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 wrap it all in a try/catch... but what can you do in the catch? Swallowing the exception is a bad idea, obviously. Throwing will cause an abort() sometime, when your dtor is called during an exception handling stack unwind. Even in normal functions, writing C++ code that is actually exception-safe is not nearly as easy as it looks.
I like C++, warts and all it's still my favorite language, and I'd love to be able to use exceptions, but I can't.

--
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.

Cobol programmers "beating on it for 30 years" by Anonymous Coward · 2011-12-09 04:44 · Score: 5, Funny

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

Technical Debt by Nittle · 2011-12-09 04:45 · Score: 5, Insightful

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 by OneMadMuppet · 2011-12-09 05:03 · Score: 2

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.
Re:Technical Debt by idontgno · 2011-12-09 06:51 · Score: 2

That reminds me of a South Texas philosophy of home architecture.
Build your house above a crawl space, and with widely-spaced slat floors. Don't bother with trash cans; just poke your rubbish through the floor with your pointy boot toe.
When the crawl space fills up, burn down the house and move on to your next one.

--
Welcome to the Panopticon. Used to be a prison, now it's your home.

Conclusion... by Anonymous Coward · 2011-12-09 04:45 · Score: 5, Insightful

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

Re:Conclusion... by TheRaven64 · 2011-12-09 05:04 · Score: 3, Insightful

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 am TheRaven on Soylent News
Re:Conclusion... by Relayman · 2011-12-09 05:26 · Score: 2

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

--
If I used a sig over again, would anyone notice?
Re:Conclusion... by tbannist · 2011-12-09 05:49 · Score: 4, Interesting

Much as I dislike Microsoft, I don't think that's actually the only issue. There has been many changes that would impact code quality over the years. Setting aside the differences in language construction. There has been a broadening of the pool of people who write software, and many people have learned "how to program" so they could get a job. It seems likely that in the 1970s if you were in computers and programming it was because you enjoyed it and took pride in it. Since the 90s, there has been an influx of people for whom it is "just a job". That alone would see a substantial decline in quality, however, on top of that the "newbies" are mostly being taught how to start programming in Java now. That means for most programmers, if you are learning Cobol it's not your first language. That means you can expect the average level of experience of Cobol programmers to be much higher than that of Java programmers.
Those two factors might be enough to explain most of the difference by themselves, but there are still a host of other factors that could contribute to this result, for example, hobbyist (as opposed to professional) programmers are much more likely to create Java projects than Cobol projects because Java resources (such as do-it-yourself) tutorials are more commonly available than the equivalent Cobol resources.

--
Fanatically anti-fanatical
Re:Conclusion... by Jeremi · 2011-12-09 07:25 · Score: 2

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?

--

I don't care if it's 90,000 hectares. That lake was not my doing.

COBOL by LtGordon · 2011-12-09 04:47 · Score: 4, Insightful

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 by laejoh · 2011-12-09 04:52 · Score: 5, Insightful

Let me, an old Cobol fart, just answer by repeating: "As if requirements never change".
Re:COBOL by tajribah · 2011-12-09 04:55 · Score: 5, Insightful

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 by Archtech · 2011-12-09 04:59 · Score: 2

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 am sure that there are many other solipsists out there.
Re:COBOL by NonUniqueNickname · 2011-12-09 05:12 · Score: 4, Funny

Old COBOL Fart, we who are about to scrum salute you!
Re:COBOL by Nutria · 2011-12-09 05:17 · Score: 4, Informative

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.

--
"I don't know, therefore Aliens" Wafflebox1
Re:COBOL by sycodon · 2011-12-09 05:56 · Score: 2

Not to mention the ability to get a record and slice and dice it easy as you please without having go through all the parsing crap. I haven't seen anything that does that except COBOL.

--
When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.

Java apps are probably most widespread by coder111 · 2011-12-09 04:48 · Score: 5, Insightful

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 by stompertje · 2011-12-09 04:57 · Score: 2

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 by gstoddart · 2011-12-09 05:15 · Score: 2

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.

--
Lost at C:>. Found at C.

range of capability, expression, and process by Speare · 2011-12-09 04:48 · Score: 4, Informative

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

--
[ .sig file not found ]

Re:range of capability, expression, and process by King_TJ · 2011-12-09 04:58 · Score: 2

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 by DarkOx · 2011-12-09 05:16 · Score: 2

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.

--
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html

Coding Practices? by Murdoch5 · 2011-12-09 04:48 · Score: 5, Insightful

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? by NoNonAlphaCharsHere · 2011-12-09 05:17 · Score: 2

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? by metalmaster · 2011-12-09 05:33 · Score: 3, Informative

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:Coding Practices? by gstoddart · 2011-12-09 05:41 · Score: 5, Insightful

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

--
Lost at C:>. Found at C.
Re:Coding Practices? by sycodon · 2011-12-09 06:02 · Score: 2

Give that man a drink and a woman!

--
When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
Re:Coding Practices? by gstoddart · 2011-12-09 06:56 · Score: 2

You make a good point about how something which seems obvious and clear now is not several months down the line. I think everyone needs to have the experience of reading code they wrote a year or more ago (and adding features or fixing bugs).
I worked at a company once with a really smart guy, but who tended a little more to the theoretical than the applied.
During an enhancement cycle, he needed to go into one of his components and extend it. Not only couldn't he decipher his own code to figure out where to begin, when he (finally) got there he had designed it so cleverly as to preclude making any changes to it that hadn't been in the original design because he hadn't made any room for it.
He wrestled with it for days and had to refactor a bunch of stuff, and was then grumbling that his 'elegant' design was being hacked up to make the modifications. If it was so elegant, it wouldn't be that tough to modify it.
Far too often I've seen people write code that not even they can maintain, and then they whine and complain when you tell them in a code review that their code isn't written in such a way as to be even close to maintainable by someone else and isn't acceptable.
I will forever be grateful to one of my CS profs who was doing code/architecture reviews with me as far back as 1990 or so ... because I learned what he called at the time "Egoless Programming". Which meant we tore it apart with the goal of making better overall code and not just focusing on doing it how someone thought best because they said so. I frequently learned nuance and modularity in design, and occasionally suggested something that made my prof go "OK, that's a better solution, do that".
The end result was better code overall, and some lessons that have carried forward to this day in how I work with people. Man, I need to buy that man a beer next time I'm in town. :-P

--
Lost at C:>. Found at C.

Re:Java == Training Wheels by masternerdguy · 2011-12-09 04:51 · Score: 4, Funny

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.

--
To offset political mods, replace Flamebait with Insightful.

Re:Java == Training Wheels by Anonymous Coward · 2011-12-09 04:56 · Score: 2, Insightful

By this logic we assume we shouldn't automate memory or cpu management. That's akin to asking me to create every nail, hammer, axe, and grow each tree, for me to build a house.

What the programs do... by jellomizer · 2011-12-09 04:57 · Score: 5, Insightful

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.

--
If something is so important that you feel the need to post it on the internet... It probably isn't that important.

Re:Java == Training Wheels by masternerdguy · 2011-12-09 04:57 · Score: 4, Insightful

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

--
To offset political mods, replace Flamebait with Insightful.

Good metric by Alwin+Henseler · 2011-12-09 04:58 · Score: 3, Insightful

(..) assess 'technical debt,' or the cost to fix the violations.

Sounds like a very useful metric: the cost of fixing a bug. Or perhaps even more useful: the cost of a bug as it's released into the wild. That is: the total cost of stumbling on that bug, reporting it, discussing it, devising workarounds, producing & testing a patch, bandwidth / system maintainers' time for checking whether to apply it, actually doing so, cost of a site hack resulting from that bug, etc, etc, all of that vs. no bug in the first place.

With that as a metric I suspect even minor bugs have a massive cost if you're talking mass-used software like popular OS or the embedded software that runs smartphones etc. And considering that massive cost, it might make sense to invest massive effort trying to find bugs before software is released. At least for popular and/or mission-critical software...

Re:Cobol is still being used? by Lawrence_Bird · 2011-12-09 05:00 · Score: 4, Informative

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

SQL too by tepples · 2011-12-09 05:00 · Score: 4, Insightful

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 by toadlife · 2011-12-09 05:03 · Score: 5, Funny

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

--
I don't always use unix-like operating systems; but when I do, I prefer FreeBSD.
Re:SQL too by S.O.B. · 2011-12-09 05:19 · Score: 4, Informative

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.

--
Some of what I say is fact, some is conjecture, the rest I'm just blowing out my ass...you guess.
Re:SQL too by CastrTroy · 2011-12-09 05:25 · Score: 5, Insightful

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.

--

Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
Re:SQL too by tbannist · 2011-12-09 05:35 · Score: 4, Funny

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.

--
Fanatically anti-fanatical
Re:SQL too by DigitalisAkujin · 2011-12-09 06:33 · Score: 3, Insightful

PHP is C-like just like Java but the path the two syntaxes take would bring them further apart than closer together.
For example in PHP you would never see something like this:
final Class d = mContext.getApplicationContext().getClassLoader().loadClass(mContext.getPackageName() + ".R$" + subClassName);
It makes me sad that Google chose Java as Android's main language considering how much of a rats nest Java really is.
It's sad that it takes 16GB of RAM just to compile a build of Android. And the funny thing is it kills the whole point of Android being "open". What person has 16GB of RAM on the off chance that they might wanna compile an Android build?
Re:SQL too by cduffy · 2011-12-09 06:43 · Score: 4, Insightful

Oh, the irony of seeing this...

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

It's up to you to filter your inputs.
*headdesk*.
Trying to filter your inputs is a losing battle. Not commingling code and data in the first place (and thereby avoiding the underlying problem -- that things intended to be data can be treated as code when reparsed) is the simple, simple win that avoids needing to fight that battle in the first place.
Incidentally, this is the same reason why using $foo rather than "$foo" in shell scripts is so evil -- things which would otherwise be data get parsed and processed (through not just string splitting but also glob expansion), leading to unforeseen results when abused.
Re:SQL too by thetoadwarrior · 2011-12-09 06:45 · Score: 2

They probably should have named it better. PHP is a fucking mess.
Re:SQL too by S.O.B. · 2011-12-09 07:14 · Score: 2

You are sooooo clever pointing out that a non-SQL DBMS is not vulnerable to SQL injection attacks. This just in...neither is my coffee machine which is equally relevant to the discussion.

--
Some of what I say is fact, some is conjecture, the rest I'm just blowing out my ass...you guess.
Re:SQL too by ksd1337 · 2011-12-09 07:16 · Score: 2

Well, that's because you're probably running NetBSD on your coffee machine.
Re:SQL too by TheSpoom · 2011-12-09 07:32 · Score: 4, Informative

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

--
It's better to vote for what you want and not get it than to vote for what you don't want and get it.
- E. Debs
Re:SQL too by BitZtream · 2011-12-09 08:00 · Score: 5, Informative

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.

--
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Re:SQL too by mvdwege · 2011-12-09 10:18 · Score: 2

[mysql_real_escape_string] is made for escaping strings in case it contains a character that would break SQL. It's up to you to filter your inputs.
And this is why you fail, and why PHP coders have the reputation of clueless monkeys.
You don't filter your inputs when you are about to feed them to an SQL query. You use place holders and let the database cast your input into the right data type. You trust the database library to know that something is a data type and feed it to the query as a parameter, not as query text. If you trust filtering, all you need is one mistake and it's Bobby Tables time.
Mart

--
"I know I will be modded down for this": where's the option '-1, Asking for it'?
Re:SQL too by frank_adrian314159 · 2011-12-09 11:24 · Score: 2

So what you're saying is that PHP was originally named "AFM"?

--
That is all.
Re:SQL too by david_thornley · 2011-12-09 12:14 · Score: 2

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

--
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes

Students! by gman003 · 2011-12-09 05:01 · Score: 2

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.

Re:Java == Training Wheels by fsckmnky · 2011-12-09 05:01 · Score: 2

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:Interpreted languages? by Anonymous Coward · 2011-12-09 05:08 · Score: 5, Insightful

Here are the languages and numbers of applications submitted for assessment.

Java EE 339
Oracle Forms 39
Oracle CRM 12
Visual Basic 14
dotNET 51
ABAP 59
C 14
C++ 9
COBOL 80
Other 11
____
total 745

339 Java, 14 C, 9 C++???

The sample size and distribution renders all statistical conclusions meaningless! Just another piece of corporate bullshit...

Lords of COBOL hear my prayer... by _0x783czar · 2011-12-09 05:09 · Score: 2

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.

--
~theCzar

Re:Java == Training Wheels by tepples · 2011-12-09 05:15 · Score: 2

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.

huh??? Wake up!!! by Anonymous Coward · 2011-12-09 05:18 · Score: 3, Insightful

Beside server-side, start by showing me COBOL codes that can play music, MIDI, animation, display web contents (HTML), VNC, VOIP, text chat, audio chat, video chat...

Do those also on cell phone, PDA, tablet... ... then maybe I would agree to talk seriously about some grueling comparison between COBOL and Java

As somebody who's worked in COBOL and Java shops.. by mwvdlee · 2011-12-09 05:18 · Score: 4, Insightful

As somebody who's worked in COBOL and Java shops (within the same company), let me say "Duh!".
It's not so much the language as the typical environment it's used in, combined with the experience.
People working on Cobol are usually working on mission-critical applications, Java applications are typically less mission critical.

In practice I find that the cost of a bug is usually a pretty good measure of the quality of code; I've worked on code where an hour of downtime literally costs over a million dollar and I've worked on code where a full day of downtime means some user might have noticed it and had to wait a day. There are people working on code where a few seconds of downtime means death. Want to guess what code will be the best quality?

--
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?

Not counting waterfall programs by Anonymous Coward · 2011-12-09 05:21 · Score: 2, Interesting

The problem with legacy COBOL is the occasional Waterfall program. That means that you flow from the beginning of the code to the end, occasionally skipping chucks of code with branches that lead to two different GOTO statements. A good COBOL program only uses GOTO to skip to the end of the procedure it is in, not to go to any arbitrary label in the program. You can write a good COBOL program that doesn't jump around all over the place if you bracket your code with procedure names and call those procedures properly.

My COBOL is a bit rusty or I'd give examples.

Re:Java == Training Wheels by Mitchell314 · 2011-12-09 05:24 · Score: 2

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

--
I read TFA and all I got was this lousy cookie

The languages deserve a lot of the blame by Shivetya · 2011-12-09 05:28 · Score: 4, Informative

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.

--
* Winners compare their achievements to their goals, losers compare theirs to that of others.

Re:Java == Training Wheels by CSMoran · 2011-12-09 05:32 · Score: 4, Insightful

Knowing how to do hard things doesn't mean I need to do it on a day by day basis.

I can know about a dozen sorting algorithms, it doesn't mean I shouldn't use the sort() provided by the standard library of whatever language I'm using. In fact, I'd be a retard not to use it.

True, but that only works for smart programmers like you. There's still a fair point with "if you make it too easy, riff-raff comes in".

--
Every end has half a stick.

Re:Java == Training Wheels by Unequivocal · 2011-12-09 05:33 · Score: 2, Funny

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.

Root of all (software) evil by luis_a_espinal · 2011-12-09 05:43 · Score: 2

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.

Re:Cobol is still being used? by TheRaven64 · 2011-12-09 05:44 · Score: 4, Funny

People also mock Fortran, yet it still rocks and has been updated to include many 'modern' features

Fortran doesn't get updated. Every decade or so a new and totally incompatible language is released and called Fortran.

--
I am TheRaven on Soylent News

COBOL...Bedrock of IT for 50 years by sycodon · 2011-12-09 05:45 · Score: 2

Your bank transactions are done with it, your payroll most likely... all the stuff that matters.

COBOL is the Mac Truck and Container Ship of I.T.

--
When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.

Re:Java == Training Wheels by bored · 2011-12-09 05:47 · Score: 3, Interesting

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

And that is one of the 3 or so major flaws in garbage collection, especially as implemented by Java. The memory requirements of the application are not reflected in the memory footprint being requested of the OS. This can cause _SERIOUS_ performance consequences in systems where there are multiple applications (one or more not using as shared jvm).

I saw it a few years ago in an application I worked on. The load of the application varied over time, and on different machines. Invariably though the JVM would have gigs of memory allocated for a basically idle app and cause another application on the machine to be paged, when the actual footprint requirements were fairly minor. Then the java app would scale up for a few hours. The end result was pretty much throw 10x the hardware at the problem, because convincing the JVM to actually back down the memory footprints at the appropriate times required our app to be able to poll the memory situation of the host machine and make determinations about its state, which wasn't nearly as fine grained as the OS was capable of. The resulting C version of the java app, quite literally ran on a single machine vs the dozen or so the java app required.

Re:Java == Training Wheels by Mitchell314 · 2011-12-09 05:47 · Score: 2

Automation and abstraction are good things, resources permitting. Why should we take the easier route and have things like memory management, etc? Because, the harder something is (ie memory management done by hand as opposed to garbage collection), the more frustration - and more importantly - more errors occur. And that means money or time, so being lazy by doing the easy thing is often the economical and logical choice. Hell, the whole point of a computer is to automate away tedious tasks. Computer science is the applied mathematical study of being lazy.

That's not to say java, et al, is the better choice for every situation. C is probably one of my favorite languages, after all. But it has it's place, just as Cobol does. The most important optimization lesson I ever learned was when I discovered the hard way that a minute saved from a faster program was not worth the 10 minutes spent observing and tweaking the code.

--
I read TFA and all I got was this lousy cookie

Re:huh??? Wake up!!! by geekoid · 2011-12-09 06:06 · Score: 2

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

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

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.

--
The Kruger Dunning explains most post on /. http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

Re:Java == Training Wheels by 0123456 · 2011-12-09 06:11 · Score: 2

Because, the harder something is (ie memory management done by hand as opposed to garbage collection), the more frustration - and more importantly - more errors occur.

Garbage collection is a disaster, at least as implemented by Java. In most respects I prefer it to C++, but huge memory bloat and massive amounts of tuning to try to get it not to freeze or suck up massive amounts of CPU time when garbage collecting are not improvements.

And 99% of memory management in sensible C++ code is handled automatically by things like STL containers (or plain old local variables on the stack), so there are few reasons to need to call free and delete in modern code.

Re:Interpreted languages? by Black+Parrot · 2011-12-09 06:48 · Score: 2

I wonder whether Ada came up in the "Other"? Previous research I've seen shows Ada with a much lower error rate than other languages (although it wasn't clear whether that was because Ada only tends to get chosen when there are a lot of constraints in place to keep the error rate lot).

Unlike many popular languages, Ada makes you say what you mean and mean what you say. The compiler finds errors that you wouldn't find until you ran the program for most other languages, and run-time checking (if enabled) finds errors that you wouldn't find until you noticed that your program has been running wrong for god-knows-how-long, for most other languages.

It's not a panacea, but it sure helps enforce badly needed discipline on its users.

--
Sheesh, evil *and* a jerk. -- Jade

Technical Debt is a shitty term by Colin+Smith · 2011-12-09 07:00 · Score: 2

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 environments they are going to be used in.

In many industries, quality assurance is taken seriously, they often have far more people and resources working on quality than on developing the products.

Software, not so much... "It compiles" is often the gold standard of quality. "It passed the unit tests", the platinum one.

--
Deleted

Re:Chasing rainbows & comparing apples to oran by s73v3r · 2011-12-09 07:03 · Score: 2

More or less so than "Lines of Code"?

Java encourages complexity bugs by HighOrbit · 2011-12-09 07:57 · Score: 2

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

PHP makes it hard to do things right by 200_success · 2011-12-09 08:23 · Score: 2

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 parameters. It takes no extra work to avoid SQL injection, and your code ends up being cleaner too.

Re:Java == Training Wheels by BitZtream · 2011-12-09 08:51 · Score: 2

Actually, memory management in java is HARDER since you have no control over it.

Its cute that you think its easier, but the less control you have, the harder it becomes.

You speak as someone who has exactly 0 practical experience programming. Dealing with shitty weak reference issues in java is an obnoxious pain in the ass that is entirely avoided in non GC languages, but you go ahead and pretend you know what you're talking about.

--
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager

Re:java by BitZtream · 2011-12-09 12:30 · Score: 2

Going to collage for CS doesn't mean you know what you're doing, which seems to be your confusion.

I can drive a car, but I don't try to pretend I'm a race car driver. Not everyone who 'can do something' are actually talented at it. Most of us are just good enough to get along in the daily life and too stupid to realize thats where our talent ends.

I've been to several dancing classes and I still suck at it. Not everyone can be a dancer no matter what 'education' they get on it.

I know for a fact that a education in CS will make you a better programmer. It can't make a non-programmer a programmer, but it will make any programmer better than they would be without it.

Everything you said in your post can be summed up to 'not everyone is a programmer, even though they might think they are', you included.

--
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager

Slashdot Mirror

Java Apps Have the Most Flaws, Cobol the Least

94 of 435 comments (clear)