Java Apps Have the Most Flaws, Cobol the Least

dcblogs writes "An analysis of 745 applications for violations of good architectural and coding practices found that Java applications had the most problems and Cobol-built systems, the least. Some 365 million lines of code were analyzed by Cast Software to assess 'technical debt,' or the cost to fix the violations. Java was calculated at $5.42 per line of code, while Cobol did best at $1.26. Cobol code had the least number of violations because programmers 'have been beating on it for 30 years,' said Cast. As far as Java goes, 'there are many people going into Java now that really don't have strong computer science backgrounds,' said its chief scientist, Bill Curtis."

Comments

so?

[masternerdguy]

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

Re:so?

[laejoh]

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?

[ErroneousBee]

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?

[Archtech]

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?

[Anonymous Coward]

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?

[v1]

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?

[Relayman]

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

Re:so?

[TheGreatOrangePeel]

Are you sure about that? Java has a lower center of balance.

Re:so?

[Maximum Prophet]

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?

[DesScorp]

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

Re:so?

[Anonymous Coward]

COBOL also is very inexpressive and requires more lines of code to do the same thing

Wait, are you comparing Cobol to Java, or Lisp? Because last I checked, Java still required more lines of code to do the same thing than in more expressive languages such as Ruby or Python. The one thing nobody (who had familiarity with languages other than C/C++) ever accused Java of is being expressive.

Re:so?

[luis_a_espinal]

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?

[Waffle Iron]

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?

[Anonymous Coward]

Plus most COBOL programmers are probably well experienced programmers.

Many of the JAVA coders are probably amatuers and the study didn't adjust for this.

Re:so?

[sjames]

When programming, we all know that the computer is an inanimate object and can't respond to shouting and we all shout at it (especially when error messages are obscure) and know it helps. COBOL offers maximum shouting, so the bugs are kept to a minimum.

Re:so?

[sycodon]

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.

Re:so?

[Joce640k]

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

OTOH Java is a much more recent language based on those 30 years of experience and we're supposed to have learned how to do things better.

I think it's more likely that more experienced people are working on those COBOL programs, not know-it-all grad students fresh out of education.

Re:so?

[Lorens]

The average COBOL programmer is also much older than the average Java programmer.

Maybe, but I work with a lot of COBOL programmers. Most of them are young and very good. While it's easy, it would be an error to assume that age is good. I have stared in horror at a fiftyish COBOL contract programmer displaying such blatant incompetence that we evoked a firing on the spot (in reality it took a few weeks). We think the person in question had no computer experience at all, but had been placed by the contract agency after a week or so of COBOL and nothing else . . .

Re:so?

[Joce640k]

COBOL has older applications, and the only way to become an old application is to start with a sound architecture.

You don't read the daily WTF much, do you?

Re:so?

[johnlcallaway]

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

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

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

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

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

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

Re:so?

[Joce640k]

If you watch the job lists there's still plenty of demand for COBOL programmers.

Re:so?

[ADRA]

COBOL developers are in fact in demand, but no, the language and its use are NOT. The only developers are maintainers and the odd 'new feature' in order to shore up against the code needing to be modernized, which is pretty much every COBOL program out there. The companies are fighting tooth and nail to avoid touching that big black box in the corner until its just so rediculous to maintain that they're forced to deal with replacing it.

Re:so?

[Adrian Lopez]

Java has to many funny characters...

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

Re:so?

[Bill, Shooter of Bul]

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

Re:so?

[Black Parrot]

Like it really even matters TO ME IN MY MOM's BASEMENT anyway.

There. Fixed that for'cha.

And I fixed it for you...

(I wonder what it costs to maintain comments.)

Re:so?

[phorm]

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?

[s73v3r]

and the only way to become an old application is to start with a sound architecture.

Or work for stubborn people who don't see any reason to replace any code, even though the current application constantly breaks and doesn't work half the time.

Re:so?

[s73v3r]

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?

[s73v3r]

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?

[Anonymous Coward]

We definitely now need a COBOLSCRIPT plugin to replace Java and the other plugins.

Re:so?

[Anonymous Coward]

I have coded in FORTRAN, COBOL, 370 Assembly, C, C++, PowerBuilder, Java (all flavors including J2EE), and you have to be fucking kidding me, calling old COBOL programs "rock solid". As COBOL programs age, waves of successive programmers add bumps, twists, and warts onto the code. Don't feel like expanding the data definition? Reuse an obsolete column, or even worse, a SELDOM USED column! Change the meaning of a column with some hard-coded arcane rule!
 
If you think that code evolves into something elegant and "bullet-proof", just look at the human brain; frontal lobes on top of monkey brain, on top of lizard brain.

Re:so?

[monzie]

Would mod that funny if I had the points.. LOL

Re:so?

[Shinobi]

The fact that it isn't as terse as, say, Java, is a good thing in terms of maintenance and debugging however, especially long-term.

Re:so?

[Anonymous Coward]

New COBOL code is written every day.

The difference is obvious. COBOL is generally written by people who actually know what they are doing. Java is frequently used by the least experienced, least knowledgeable, and least trained coders around. The conclusion has been widely known for almost as long as Java has existed. Honestly, if you're the least bit surprised by what is already common knowledge, you're probably not very knowledgeable about trends in the industry.

Now then, that in no way means only bottom rung coders use Java. Having said that, there is a hugely disproportionate number of bottom rung Java coders than any other language I've encountered.

Re:so?

[sapgau]

Excellent, I love it...
+1 (oh, never mind you're maxed already)

Re:so?

[Anonymous Coward]

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.

Look at UNIX, and the systems it replaced. Its designers understood how and why they were doing things differently, but down the road, people forget.

Now we're stuck with systems built around unstructured random-access or streamed data. I'm sure it was cool for a while, but catching spurious commas, newlines, spaces, quotes etc, gets old fast and you start wishing for clearly defined records and fields after a while, which I'm sure is what led to mainframes having them in the first place.

Java is a bit unfair to single out because it mostly evolved from its predecessors. You may as well lump it in with C & C++ against COBOL, ADA, etc. You see the same mainframe/UNIX transition crap again.. now we in plug scripting languages to express business logic and rules in a clear way, and look at the hurdles we jumped to get back to where mainframes already were in terms of centralized applications. History needs to be a bigger component of computer science & engineering I think.

Re:so?

[hudsucker]

COBOL also is very inexpressive and requires more lines of code to do the same thing

...unless you're doing the types of things COBOL was made for. Such as, dealing with fixed point numbers.

Re:so?

[BitZtream]

Gartner is hardly a reliable source when it comes to studies such as this, its common knowledge they shill for whoever is paying them for the study.

Re:so?

[Anonymous Coward]

There used to be some problems with exceptions:
- Speed. about 20 years ago they were normally implemented with setjmp-longjmp so they slowed down the code even if nothing bad happened. For the last 10 or 15 years this has been done at zero cost if no exception is thrown (though you might get some slowdown the first time an exception is actually thrown as the linker/loader lazily relocates some information about what try-catch blocks exist)
- DLLs/shared libraries: There wasn't a stable ABI so throwing exceptions in/out of a dynamic module linked separately could cause problems. For many applications this is a corner case. At worst you have to compile everything with the same compiler.
-Interaction with callbacks from C. If you threw an exception from a callback from qsort, how does the C part of the stack get unwound? Nowadays there are enough C++ libraries that this sort of thing just doesn't often come up.

Keep in mind that projects like Mozilla have been going on for 15 years or so, so their coding standards are often not up to date anyway.

Re:so?

[sapgau]

lol... you might have a point there lizard brain!! snort!!

Re:so?

[BitZtream]

The fact that you're using an arbitrary measurement shows you're complete lack of understanding of programming.

How the fuck did this get marked as insightful? I can write an entire java application, a non-trivial one at that, with a SINGLE ( as in wc -l returns 1 on the single file in the project) line of code. Could do it with python as well, and perl, probably ruby too, PHP for sure, C/C++/C#/Objective C for certain ... in fact, other than VB, I can't think of a language I can't do it all on one line. Not saying they don't exist, but just pointing out that counting lines of code is such a silly concept, anyone that understands whats going on has a hard time grasping why you would consider counting them in the first place.

Using lines of code is an instant indicator of 'not having the slightest clue what so ever' when referring to any non-whitespace sensitive language, and most others as well.

Counting lines of code is only useful in a relative form, as in, counting lines of code YOU personally produced this month compared to last month, and even then lines of change are more indicative than new lines, but both are shitty metrics without context.

No programmer counts lines of code, only bad managers.

Re:so?

[BitZtream]

You fail to understand the problem because you are a programmer.

Programmers care not about the language, the language is simply an end to a means. A programmer can write code in any language because the language is unimportant, the logic that the programmer can visualize is whats important, and that can be implemented in almost all useful languages, certainly any we're talking about here.

The people you see talking bad about cobol are people who are not programmers, they are people who (may) write code in a given language. Plenty of idiots 'write code' in a given language, in fact most of the development in the world happens this way. Programmers on the other hand, write code in any language. Most people who write code are not programmers. The instant someone starts talking about how awesome their language is or how much some other language sucks, you can almost instantly write them off as a newbie non-programmer who has been shown how to write a few lines of code, but they have no actual understanding of the process.

I've never written a single line of cobol, but I'd bet a paycheck that I could write reasonably efficient cobol code in the course of one pay period. I am a programmer, I write code, I care not what the language is, I care about the logic and math. Everyone else is just a code monkey.

Re:so?

[Concerned Onlooker]

..." just look at the human brain; frontal lobes on top of monkey brain, on top of lizard brain."

All wrapped around a creamy nougat center.

Re:so?

[cusco]

You probably don't work with extremely large systems, then. When Target rings up your transaction it's processed and recorded on a mainframe (a.k.a. "big black box") chock full of COBOL programs. The order to replace the items you purchased, receive the merchandise, route it to the store and maintain the inventory are also COBOL programs running on mainframes. When the IRS processes your W-4 withholding, more COBOL, more mainframes. When the phone company sends you your bill, more COBOL, more mainframes. There's a reason why IBM can dump the laptop division without a second thought, it's because their bread and butter is still the massive mainframe, it's what pays the bills. Locally I know of a DEC VAX that was last rebooted in the 1990s (because of a power outage), and several companies who have been running COBOL backends for longer than that. Our economy runs on COBOL, you just don't see it because it doesn't need constant poking and prodding.

Re:so?

[laejoh]

That's END-OF-DISCUSSION. in Cobol for you, dear SIr!

Re:so?

[Anne Thwacks]

They failed to mention that it takes a billion lines of COBOL to do what one line of Perl would do. Of course, all COBOL programmers would know what the COBOL does, while only one in a billion Perl programmers would know what the Perl actually does.

Re:so?

[Anonymous Coward]

Your sentence doesn't parse. Perhaps you meant "it's", which is the contraction of "it is"?

Re:so?

[shutdown -p now]

For extra stability, I recommend running COBOL on .NET. That's three more capital letters right there!

Re:so?

[cshark]

It makes sense to me. Of course, I don't really see COBOL as a programming language; not like the languages we work in today. It's more like a conversation with a computer than anything.

Re:so?

[LameMonikerGoesHere]

Insightful?! You just restated a point made clear in the fucking summary.

Re:so?

[AEC216]

I did COBOL and RPG for about 3 years. God, it was simple to debug almost any problem.

Re:so?

[david_thornley]

You can't write anything serious in C or C++ (and probably not Objective-C) in one line. You will be using "#include ", and you need a line break after each.

Re:so?

[Anonymous Coward]

And we KNEW how to program. You youngsters today think if you can write "Hello world" in .NET or Java, then you are a "programmer".

Now get off my lawn (I mean it! I am blissfully retired!)

Re:so?

[Anonymous Coward]

IDENTIFICATION DIVISION.

              PROGRAM-ID. "COBOL1".

              PROCEDURE DIVISION.

                      DISPLAY "70% OF ALL COMMERCIAL COMPUTER".

                      DISPLAY "CODE IS STILL WRITTEN IN COBOL".

                      DISPLAY "150 BILLION TRANSACTIONS EVERY DAY".

                      DISPLAY "ARE HANDLED BY COBOL".

                      DISPLAY "Hi from Debian 6! Dec 2011".

                      DISPLAY "and it is easy to understand AND runs on Linux!"
                      STOP RUN.

Re:so?

[swillden]

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.

Re:so?

[Anonymous Coward]

Correct RAII means that (1) your destructors won't throw because they're releasing stuff and (2) you write very few destructors that do more than one or more delete calls anyway and (3) you can almost always arrange so there is no destructor that you have to worry about.

Re:so?

[gweihir]

Maintenance does not help with architecture. More likely the Java coders of today do often have zero understanding of good architecture and design.

Re:so?

[rossy]

Good point.

Re:so?

[Anonymous Coward]

Support is a lesser problem. The bigger one is the design. C++ with exceptions is a lot more difficult language than C++ without exceptions (which is already an order of magnitude more difficult than C). There are all sorts of funky corner cases you need to take into account if you want to be really correct.

Re:so?

[swillden]

If you use RAII only to release memory, that's true. If you use it to release other resources, not so much.

Re:so?

[Anonymous Coward]

There's lies, damn lies, and statistics. Also bugs per lines of code (LOC) is a very poor estimate of code quality. It should be defects related to decision density (bugs per LOC/cyclomatic complexity) to normalize for language brevity. Just try comparing LOC required to do something in assembly vs COBOL. Not all languages are created equal.

Re:so?

[Bill, Shooter of Bul]

No, its referred to as the omniscient possessive. I believe in an all powerful being who possess all things not specifically given ownership in gramatical phrases. So my god owns the difficulty that the responsibility of supplying new cobol programmers to keep up with the suicide rate. While it is his responsibility, he is just god and only punishes the truly evil with cobol.

Cobol programmers "beating on it for 30 years"

[Anonymous Coward]

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

Re:Cobol programmers "beating on it for 30 years"

[rawler]

They sure aren't allowed up in the light of day, an arrangement that suits everybody.

Re:Cobol programmers "beating on it for 30 years"

[kiehlster]

By that logic, I guess I should start putting that on my resume: over 20 years of experience beating on it, usage remains fresh.

Technical Debt

[Nittle]

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

[OneMadMuppet]

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

[Anonymous Coward]

Just keep in mind, they always "Shoot the messenger".

Re:Technical Debt

[stephanruby]

How does paying technical debt ever give your app that new feature that your marketing department is pushing for -- to have out by tomorrow.

It's doesn't. That's the point. When the technical debt becomes too high and it doesn't allow you to add a feature by tomorrow without breaking everything, it means it's time to look for a brand new job with a brand new new code base where you can restart new technical debt from scratch

Re:Technical Debt

[idontgno]

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.

Re:Technical Debt

[c0lo]

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.

Hang on, buddy... that's already an overload for the sales/marketdroid single neuron... why should they care, as long as they get the commission? If the company goes busted, that's not their problem either... their CV will show how many zillions they made in sale, not their fault the company went under.

Re:Technical Debt

[Jeremi]

In today's agile world, who gets time to maintain technical debt.

No time to fix our bugs, Dr. Jones... all our time is taken up helping our users work around the damage caused by our bugs!

Re:Technical Debt

[theshowmecanuck]

First thought that came to my mind was 'which one uses agile programming the most, Java or COBOL?' Specifically I thought about many of the proponents of agile I talk to who use the term evolving architecture or discovered architecture and how it seems absurd to think you can build solid apps on a moving (ahem evolving) target. A lot of agile methodologies that I've seen think that doing up front architecture is the wrong thing to do (and woe to those who use requirements and documentation!!!). Why is agile and architecture considered mutually exclusive (this is a rhetorical question). And when it comes to the 'software built using up front architecture is bad' types of people (including a bunch of 'agile coaches' I've encountered), once it gets into maintenance mode and a few years go by, the effects of the evolving architecture are compounded by fact these people are also 'the code is self documenting, documentation and requirements are bad' people. I feel sorry for the people who will have to maintain the code years down the line. On the other hand, most COBOL programs were built using documentation and architecture. Something that provides stable foundations. Slag away in 4, 3, 2, 1, go...

Re:Technical Debt

[BitZtream]

I'm fairly certain you've never lived in Texas. Its too fucking hot to build a new house, let a lone be the moron to burn down the old one.

Re:Technical Debt

[sapgau]

I agree.
Maybe just taking what you need from Agile and making sure at least you have requirements documented (and at least acknowledged) for your client for legal reasons.
Hoping that a fortuitous list of emails, notes and old requirements will show the spirit of what was intended.
I will rather have that than what you describe as 100% Agile.

Sad but true!

Re:Technical Debt

[TemporalBeing]

In today's agile world, who gets time to maintain technical debt. How does paying technical debt ever give your app that new feature that your marketing department is pushing for -- to have out by tomorrow. I think the rules have changed in how companies push their software development organizations to deliver software. That may be the biggest reason that quality is different than it was. That and the other programs have been worked on forever.

It also comes into play with how long it takes you to add the new feature that they want you to add. Sometimes its better to go ahead and take the hit so that the next 5 features can be added more quickly - so you'll quickly gain back the cost. Sadly, too many managers don't think in those terms, so they keep plodding on with the more expensive to maintain code-base.

Re:Technical Debt

[swillden]

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.

Hang on, buddy... that's already an overload for the sales/marketdroid single neuron... why should they care, as long as they get the commission? If the company goes busted, that's not their problem either... their CV will show how many zillions they made in sale, not their fault the company went under.

That's when you have to go over their head. If everyone up the chain thinks the same way, you should hack it in the quickest and easiest way you can and use the time you free up to work on your CV.

Keep in mind, though, that as you walk up the chain you may well run into a person who does understand what you're saying and looks at the company's situation and makes a rational, considered decision to take on the additional technical debt. Technical debt, just like financial debt, does make sense in many cases.

Re:Technical Debt

[Anonymous Coward]

You are what's wrong with this industry. Just because you don't have the time or skill does not mean that the profession no longer requires it.

Mergers and acquisitions are made and broken on IT architecture. Proper software development and maintenance relies completely upon it. Don't suggest that the entire discipline sink to your level.

Conclusion...

[Anonymous Coward]

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

Re:Conclusion...

[TheRaven64]

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

[Anonymous Coward]

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

[Anonymous Coward]

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

Re:Conclusion...

[Relayman]

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.

Re:Conclusion...

[tbannist]

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.

Re:Conclusion...

[sycodon]

massively overpaid

How much is it worth to you to get your pay check on time, all the time?

Re:Conclusion...

[cyber-vandal]

Where are these massively overpaid COBOL jobs. It's been a very long time since I've seen a large amount of COBOL work and that was around Y2K / Euro time.

Re:Conclusion...

[Black Parrot]

Where are these massively overpaid COBOL jobs.

I think it's the ones doing payroll applications.

Re:Conclusion...

[Black Parrot]

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.

I don't know about that. ISTM that a post hoc analysis like this might give a pretty good expected value for what you're going to get if you order new code.

Re:Conclusion...

[s73v3r]

I looked at some "new" code the other day and it was riddled with GOTOs.

How were those GOTOs used? In C/C++, it can be a good way to exit a method early, while still being able to go to the cleanup code.

Re:Conclusion...

[Jeremi]

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?

Re:Conclusion...

[Anonymous Coward]

I'm in chemical engineering student and get to hear software engineers in the lounge talk about coding. Examples; The program was like 5000 lines, but I copy and pasted a lot of it. -not a good start. I could easily implement it to convert to other base systems I just have to change all the 2s to what ever number I want. -Not sure which is worse. You guys are going to be f-ed by the next generation of programmers. I wish I was making this up.

Re:Conclusion...

[BitZtream]

Sigh, idiot.

You do realize that an if statement, a while/for loop and any other branch is the exact same thing as a GOTO, right.

Whenever I see some moron ranting about GOTOs I just have to start laughing. When people rant about GOTO its because they have absolutely 0 idea how everything works under the hood and are doing nothing other than spewing out what someone else on the Internet said about GOTOs.

GOTO isn't bad, only idiots like yourself who don't have a fucking clue what you're doing using it improperly make it bad. The reason everyone tells you its evil is because you aren't' competent enough to understand its proper usage so its better off for the rest of us if you just don't use it than it is for us trying to get you to use it properly.

You might have been taught in the 70s, but you were taught wrong. If you have some sort of retarded self block against using GOTOs, then you are a shitty programmer. They have a time and place where they fit better than anything else.

Perhaps if you understood how things like try {} catch {} finally {} actually worked, you wouldn't make such ignorant statements. GOTOs are everywhere in your code, you're just to ignorant to realize it.

Re:Conclusion...

[utkonos]

Goto? I'm sorry, I'm not familiar with it.

Re:Conclusion...

[Anonymous Coward]

GOTOless

That's actually pretty good, given you didn't have nested functions and compilers that could inline them sensibly back then, that is -substitute the meddling with stack with simple jumps. :-) My goto count has come down to maybe 1/5th with GCC extensions, specially now that I can put the cleanup code into nested functions. I still occasionally break from loops and omit some code on my way out (thus goto).

Re:Conclusion...

[shutdown -p now]

In C++, it is actually rarely useful. First, because it interferes with declaring variables close to the place where they are used (you can't use goto to skip a constructor for a local if that local is still in scope at your target label), and second, because you're supposed to use RAII and scope guards to clean things up in C++, anyway - it's less brittle than "goto Error" everywhere.

Re:Conclusion...

[ConceptJunkie]

You've got a point, but on the other hand, I experienced exactly the same thing in the 80s. I recall one person in one of my CS classes that was constantly bragging about how long his programs were.

Re:Conclusion...

[Relayman]

In my code, every point in the code has exactly one entry point and exactly one exit point. When you use GOTOs (and GOTO's bastard children LEAVE and ITER), you break that.

You claim there is a proper way to use GOTOs which implies an improper way. Who is going to enforce proper use? It's just easier to avoid their use.

Re:Conclusion...

[david_thornley]

In C++, you shouldn't have "cleanup code" at the end of a routine. That's always got low cohesion and high coupling. Put the cleanup into the destructors of the objects you use. Look up "RAII" to see how it's done.

Re:Conclusion...

[Relayman]

I program full time in RPG, the cousin of COBOL, but I don't talk much about billing rates on here. I don't consider myself "massively overpaid," because I deal with systems where problems can cost $20,000 in overtime a month (as happened last year; not my fault). Some of my colleagues work on systems where downtime is much more expensive.

Re:Conclusion...

[donscarletti]

• -Breaking two loops at the same time. Can be accomplished by putting these loops into a function and using return, at the expense of code clarity. Nested loops in my opinion should be expressed as nested loops when they are not performing a readily separated subtask, it saves the future maintainer from scrolling up and down to work out what all of those locals mean and things like while(condition() && !exitLoop) in the outer loop are ugly and require the program flow to be controlled by a local variable that is neither const, nor an iterator, which makes program flow difficult to analyse.

• -When you have a tail-recursive algorithm, but implementing using tail recursion would be unclear or inefficient, such as having lots of local state which can be reused. A do{}while(); can be your friend here, as can splitting the function into two, one of which is recursive, but it just comes down to what feels more legible when you look at it.

• -When there is a compelling reason to do cleanup in that way, mainly when dealing with c libs that do not respect RAII semantics and cannot be wrapped cleanly.

It all comes down to whether the code is easier to read with the goto or without it. In my opinion they should be used quite sparingly, when no other syntax will do, which actually makes them extremely conspicuous and helps the maintainer follow them.

Finally, you mention skipping of constructors, locality of declaration and RAII as being drawbacks with using goto in C++, I would say the opposite and would say that this is why goto is bad in C. In properly written C++, local variables tend to be consts or references that are initialised to the right value when they are declared and upon leaving a scope, any resource allocation incurred in that scope will be automatically freed. Thus you have far more checks and balances, if the compiler does not let you do that jump then you should add scoping around whatever you don't need after the label and if that is impossible, you've probably written something that relies on uninitialised variables.

Re:Conclusion...

[shutdown -p now]

-Breaking two loops at the same time. Can be accomplished by putting these loops into a function and using return, at the expense of code clarity. Nested loops in my opinion should be expressed as nested loops when they are not performing a readily separated subtask, it saves the future maintainer from scrolling up and down to work out what all of those locals mean and things like while(condition() && !exitLoop) in the outer loop are ugly and require the program flow to be controlled by a local variable that is neither const, nor an iterator, which makes program flow difficult to analyse.

I'll agree with that. I actually love Java take on this - labelled break & continue - IMO, it makes the purpose clearer, and labeling the loop makes more sense to me than labeling the first statement after it - it's also easier to give a meaningful name to the loop label.

-When you have a tail-recursive algorithm, but implementing using tail recursion would be unclear or inefficient, such as having lots of local state which can be reused. A do{}while(); can be your friend here, as can splitting the function into two, one of which is recursive, but it just comes down to what feels more legible when you look at it.

Generally speaking, that would be a while or a do/while or even a for loop - since you would always have to have a condition causing it to terminate somewhere. So this wouldn't be a use case for goto.

When there is a compelling reason to do cleanup in that way, mainly when dealing with c libs that do not respect RAII semantics and cannot be wrapped cleanly.

With C++11 lambdas, it's trivial to implement a foolproof scope guard macro that lets you write arbitrary cleanup code. After that, you just write it like:

FILE *f = fopen("foo", "rb");
SCOPE_GUARD({ fclose(f); });

It's much less brittle than goto, and it's easier to follow, because cleanup code is right next to where resource is allocated. I use this technique all the time when working directly with C APIs (mostly Win32). It's also handy when you need to set some flag for the duration of the function's execution, and guarantee that it'll always get reset when control flow leaves the function - writing separate sentry classes for every occasion gets tedious fast.

Re:Conclusion...

[s73v3r]

and second, because you're supposed to use RAII and scope guards to clean things up in C++, anyway - it's less brittle than "goto Error" everywhere.

Ok, but suppose my function hits an error, and needs to bail. Do you prefer having Return statements peppered all over the method, or only one Return to look for?

Re:Conclusion...

[s73v3r]

That's assuming we're using a lot of objects. The shop I work at now is using C++, but most of the people were old C guys, and never really wanted to make the switch. Hell, they're still using VS.NET 2003.

Re:Conclusion...

[shutdown -p now]

I prefer multiple returns over one return with a bunch of gotos to it. Control flow graph is exactly the same in both cases, but at least I know what exactly return does when I look at it - I don't have to skip to the label to find out.

COBOL

[LtGordon]

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

[laejoh]

Let me, an old Cobol fart, just answer by repeating: "As if requirements never change".

Re:COBOL

[tajribah]

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

[Archtech]

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

[Anonymous Coward]

neocommunist unioner...

Re:COBOL

[NonUniqueNickname]

Old COBOL Fart, we who are about to scrum salute you!

Re:COBOL

[Nutria]

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

Re:COBOL

[PhrstBrn]

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.

Re:COBOL

[Unequivocal]

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

[sycodon]

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.

Re:COBOL

[sycodon]

And they'll be comparing that to COBOL and be amazed that COBOL still has fewer bugs.

Re:COBOL

[Anonymous Coward]

And because like has happened here. Some person in a position of power is enamored of what they do and thinks copy and paste is the greatest coding practice. Then you have many applications with the same flaws everywhere.
Most old systems in COBOL seldom did that or someone fixed it later.

Re:COBOL

[geekoid]

The one written by seasoned software engineers.

However, the fact that you ask that question show you is many of the underlining development principles of both languages.

Re:COBOL

[Anonymous Coward]

I wonder how many of the Java programs in the study were rewrites of COBOL programs where the COBOL source code was lost and there was an incomplete or poor understanding of the requirements for the replacements. That kind of problem, especially for old software where none of the original authors are still employed (or alive), can lead to many defects, from simple bugs to design flaws. It seems to me that that could contribute to the bad stats for the Java software.

- T

Re:COBOL

[Pope]

Sure, because of all the Y2K fixing that happened! :)

Re:COBOL

[ravenscar]

I think that this statement is valid, however, there is one thing for which it fails to account. Having worked in a few COBOL shops full of 'old' programs, I can say that code tends not to get more elegant as it ages. Programs often look the best when they are first written. Some of our old code had been worked on by 40 different programmers at one time or another - all of whom had different thought processes, training, and paradigms. Rarely was the code refactored when it was touched, instead, it updated, appended, and commented out.

I worked on one project about 10 years ago that involved cleaning up a block of code that contained the majority of business rules and database activities for a large system. There was a ton of code that started with things like "if systemdate 84165 (the 165th day of 1984) then..." If you followed those statements to their bitter end they often pointed to obsolete modules or resulted in invalid database actions.

So - yes - many of the errors in the original code had been found and fixed over the years, but there were plenty of errors introduced by the regular tinkering.

Completely aside - I think the way some of the old school programmers worked resulted in some very elegant implementations. The guys in the 60's and 70's had to work within the bounds of limited system memory, limited processing power, and limited storage space. I think programmers of today could learn a lot by studying just how 'economic' programmers were in the past.

Re:COBOL

[colinrichardday]

awk?

Re:COBOL

[Black Parrot]

I, for one, welcome our New Old COBOL Fart Overlords!

Re:COBOL

[thetoadwarrior]

There is some truth to that but they are right in that very few people start off programming Cobol but there are a ton of idiots learning Java, PHP, Ruby, etc. So if everything was equal in terms of developers and we started from scratch the Cobol programmers will probably be better because they're more serious about programming. You'd have to be to learn a language that is nearly dead.

Re:COBOL

[TheLink]

Can you provide an example of what you mean by that?

Re:COBOL

[Anonymous Coward]

So what you're saying is that about half the COBOL code in existence is more than 20 years old. That statement seems to support the idea that most COBOL programs are very old and possibly less buggy simply due to their age. The doubling time for lines-of-code for software in general i single-digit years, not the two decades required for COBOL.

Re:COBOL

[KlomDark]

C# with the Entity Framework give you that functionality as well.

Probably Java with Hibernate as well.

But only COBOL has tombs in BSG!

Re:COBOL

[Anonymous Coward]

Old COBOL Farts neved Die. They just keep Stinking.

Re:COBOL

[Nutria]

What he probably means are record overlays (like struct unions in C, but readable): populate a record and then refer to bits and pieces in innumerable ways.

There's also MOVE CORR and INITIALIZE.

Re:COBOL

[mobby_6kl]

Or a Perl one liner!

Re:COBOL

[Anonymous Coward]

Also: buggy, trouble-causing, unmaintainable software is likely to be replaced rather than patched. Buggy COBOL code gets replaced with (maybe just as buggy) code in another language.

This statistic also shows that natural selection also works on code: the only COBOL code still remaining is maintainable code.

Re:COBOL

[sapgau]

The latest for Java is JPA
http://en.wikipedia.org/wiki/Java_Persistence_API

Re:COBOL

[laejoh]

Just wondering, In my general direction?

Re:COBOL

[sapgau]

So you've been a COBOL programmer for that long?

Re:COBOL

[BitZtream]

Pretty much every single thing you listed indicates you suck at programming, regardless of language.

Whats even better is you're too ignorant to realize that half of your list has nothing to do with the language what so ever.

I'm guessing you just read some text book and really have absolutely no experience programming what so ever.

Re:COBOL

[LoztInSpace]

You are starting from an impossible position. The Java app will have a 1000 lines of meta-manager-interface-factory-facades before doing a stroke of useful work. So either the Java wins because there are no identifiable bugs in its operation (i.e. there is no operation) or it loses for not actually being capable of providing *any* functionality in 1000 lines.

Re:COBOL

[Anonymous Coward]

You forgot: Guaranteed Job Security for anyone involved in a major COBOL project

It's great.

Re:COBOL

[thetoadwarrior]

Never because I have no use for it.

Re:COBOL

[dkf]

The latest for Java is JPA

Which is damn close to Hibernate, but standardized so there can be multiple implementations of it.

Re:COBOL

[mikechant]

I thinks it's probably reasonable to say that most of your criticisms do not apply to IBM's z/OS Enterprise COBOL, particularly if you have the budget to buy all the related tools.

Java == Training Wheels

[Anonymous Coward]

Java is the "training wheels" of programming languages.

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

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

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

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

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

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

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

Re:Java == Training Wheels

[masternerdguy]

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

[Anonymous Coward]

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

[masternerdguy]

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

[fsckmnky]

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

[tepples]

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

[Anonymous Coward]

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

[Anonymous Coward]

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

[Mitchell314]

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

[BlackSnake112]

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

[CSMoran]

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

[Unequivocal]

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.

Re:Java == Training Wheels

[fsckmnky]

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

The OS facilitates sharing of *system* memory between and among applications. The GC system in Java manages *application* memory for a single instance of an executing Java application. Invalid comparison. While the OS prevents resource conflicts, the GC of Java speculatively allocates/releases memory in an attempt to alleviate programmers of the task.

So is Swing: the screen is a shared resource.

The "screen" is either a hardware device, as in the graphics card and attached monitor, or a virtual facsimile of the same. At least on Linux, Swing is merely an API that interfaces with X11 for a single application instance ... it is X11/Card Driver/OS ( and perhaps soon Wayland ) which is responsible for the sharing and resource conflicts of accessing the real/virtual screen device by multiple application instances. Another invalid comparison.

Re:Java == Training Wheels

[MobileTatsu-NJG]

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

I always considered that the definition of scripting.

Re:Java == Training Wheels

[characterZer0]

Damaging the system is not the big concern. Managing memory is not the hard part.

Corrupting the data is the big concern. Doing the correct things with the data is the hard part. So what if I could have done memory management in C, or used a sort tailored to the task instead of java.util.Collections.sort(List) to make the program run 10% faster to save the customer 10% on hardware and energy costs? By using Java for those things, I can focus on meeting the customer requirements correctly and quickly, which will greatly outweigh that 10%.

Re:Java == Training Wheels

[bored]

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

[Mitchell314]

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.

Re:Java == Training Wheels

[Rising Ape]

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

Have you seen the price of memory these days? It's virtually given away in cereal packets.

Re:Java == Training Wheels

[0123456]

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

[0123456]

Have you seen the price of memory these days? It's virtually given away in cereal packets.

16GB of RAM doesn't last very long if every Java app configures the JVM to give it 2GB even though it only actually needs 20MB.

Re:Java == Training Wheels

[geekoid]

Yes, price is the issues~

Memory has overhead.
Memory can be maxed out

It's not just cost.
And quality memory isn't cheap.

Re:Java == Training Wheels

[geekoid]

Those where the days when men died in real cars.

But the comparison is either plain stupid, or you are completely ignorant of COBOL and the architecture it is primarily running on.

Re:Java == Training Wheels

[cyber-vandal]

It was very rare indeed to have to do memory management in COBOL either. As for being able to do real damage to the system heh. Never seen that happen in 15 years of COBOL development.

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.

What utter shite. Shit programmers exist for all languages but there are incredibly talented ones too. I can't speak for Java programmers but I presume you have a similar misplaced contempt for C# people in there too and I can assure you that things like optimisation and good algorithm choice are very important, as efficient code = responsive software = happy users. I have no doubt however that I could be just as 'leet' as you and hack on C, C++ or whatever it is you think is the one true language in a pretty short time.

Re:Java == Training Wheels

[Rising Ape]

Does Java really work that way? I don't program in Java, so I really don't know, but that would be one of the most bizarre memory allocation systems I've heard of.

I've seen Java apps allocate tens of GB of virtual memory, but then not appear to touch it - the actual resident set size is much less.

Re:Java == Training Wheels

[0123456]

Does Java really work that way? I don't program in Java, so I really don't know, but that would be one of the most bizarre memory allocation systems I've heard of.

The JVM has to decide when to collect garbage allocations. To do that it uses various methods, including when the accumulated crud has reached some maximum size defined when you start up. If you give it too much RAM then the crud will keep piling up until it eventually gets cleared out, and then your JVM will still have 2GB of RAM even though little of it is useful. If you give it too little, then the program will crash.

Most memory allocations in C++ programs are usually on the stack, so they're automatically freed when you exit that code. The remainder are freed when you're done with them, and so the memory can immediately be reused. If a C++ program temporarily needs all the RAM on the machine it can use it, and if the memory allocator is smart enough it can give that RAM back to the OS when it's done.

Re:Java == Training Wheels

[blueg3]

Thanks to virtual memory systems, almost all of that 2 GB isn't actually consumed, because it's all zero pages that have never been touched.

Re:Java == Training Wheels

[s73v3r]

To a point. You should know which sort the Sort() method is using. You should also have a good enough understanding of your data and system to know if that's the proper (or often just "good enough") sort to use in the situation, or if a different sort would be better.

Re:Java == Training Wheels

[Anonymous Coward]

And if you expect your app to have uptime measured in months, servicing thousands of customers with millions of requests; you still better manage your memory or your shit is going down. bitch.

Re:Java == Training Wheels

[Hatta]

You have a point. But in that case, how bad are Java programmers that they need TWO sets of training wheels?

Re:Java == Training Wheels

[Unequivocal]

I think maybe you think I was not using irony.

OP was complaining that Java has too many training wheels, and it doesn't teach key programming practices. I was using irony to point out, by time honored car analogy, that sometimes training wheels are in fact real innovations that are just plain better than the old way. Sounds like you agree.

Re:Java == Training Wheels

[quarkscat]

Ah, FORTH. Greetings, comrade.

Re:Java == Training Wheels

[DamonHD]

If the Java GC/VM in place is smart enough and obeys the -XX:MaxHeapFreeRatio and -XX:MinHeapFreeRatio for the Oracle VM or similar than it too can nominally give back unused blocks of memory to the OS.

Not that I recall ever actually seeing a C++ application do it in all the years that I was writing and using mission-critical C++ apps, and instead I saw plenty leak and hit 2GB and die for the want of GC, even with the best attention to code quality, use of Purify, etc.

Yes, I've seen lots of Java apps die with 'leaks' too (by putting junk in statics for example), but then it's also possible to run pretty efficient Java apps: down to tens of kilobytes of heap with the early KVM (J2ME/CLDC). And I happily run the same Java code on a SheevaPlug as on a big fat co-lo server with careful attention to memory usage.

Upshot: it's possible to write crap code and waste memory in virtually any language. I'm happy with the trade-offs in Java/C# against C++ in general.

Rgds

Damon

Re:Java == Training Wheels

[DamonHD]

Unless you run a swapless system (eg entirely on limited-wear Flash) and have limited overcommitment of VM, in which case being unused doesn't let anyone else actually use it fully.

Rgds

Damon

Re:Java == Training Wheels

[BitZtream]

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.

Re:Java == Training Wheels

[BitZtream]

Most people who write java code are not programmers. Java programmers probably don't really need any training wheels.

Re:Java == Training Wheels

[BitZtream]

All of this easy easily fixed with 4 characters worth of command line arguments.

Re:Java == Training Wheels

[BitZtream]

Which means the OS won't actually allocate it, and no REAL memory will be used. It'll just take up some TLB cache somewhere and thats it.

If your OS is too stupid to not allocate unused pages, I really can't see the problem. (For reference, I've written OSes for microcontrollers that are that stupid)

Re:Java == Training Wheels

[BitZtream]

Really? Have you actually looked at highway statistics, I think you'll be surprised.

Re:Java == Training Wheels

[BitZtream]

Until you realize that you're speeding up the heat death of the universe by 10%. At that point, the perceived cost savings isn't so much a savings ... is it? Thats right, I said it, by using Java you're bringing about an early end to the universe as we know it.

Note: I'm probably writing Java code as you read this.

Re:Java == Training Wheels

[sapgau]

Levels of abstraction my friend...
Unless you are suggesting everything should be done in C.

Re:Java == Training Wheels

[sapgau]

The comparison is spot on!

Re:Java == Training Wheels

[Anonymous Coward]

Because scripting is for sissies?

Re:Java == Training Wheels

[MobileTatsu-NJG]

Well I'll put it this way: I do a lot of scripting, but I don't call myself a programmer. It wouldn't offend me if somebody who say, understood memory management, considered me a sissy.

Re:Java == Training Wheels

[sapgau]

"Computer science is the applied mathematical study of being lazy. "

Perfect definition!

Re:Java == Training Wheels

[Anonymous Coward]

Your reply is hyperbole, distorting what was originally said. The AC speaks the truth. I have seen it first hand, the Java-first CS education is now creating a generation of young CS grads who can't think critically about anything because they think Java or C# will "do it for them". Even if you're using libraries 90% of the time, there is a need to think "under the hood" occasionally and a practical need for a sold understanding of implementation details. Further, thinking that GC is a silver bullet allowing you to not think about allocation patterns and efficient memory layout leads to very crappy-performing Java and C# apps. Lastly, exceptions as practiced by Java/C# gives these people a weird mental framework where their code can never fail and therefore they don't have to think about failure conditions. I know this because I'm constantly cleaning up other people's messes.

That said, most people who code in any language do a shitty job of it, so maybe over-reliance of Java/.NET brain damaged thinking is just a handy way of detecting people who should probably be in some other career.

Re:Java == Training Wheels

[Anonymous Coward]

If you make it idiot proof, someone will make a better idiot.

Re:Java == Training Wheels

[blueg3]

Yes, that's what I meant. Though if it's never accessed, it'll probably only take up lines in the page tables and not in the TLB.

A resource-guaranteeing OS may allocate unused pages, but you're probably not going to see Java running one one of those anyway.

Interpreted languages?

[gmuslera]

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

Re:Interpreted languages?

[Anonymous Coward]

JavaScript and PHP were not in the study.

Re:Interpreted languages?

[Anonymous Coward]

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

Re:Interpreted languages?

[digitig]

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

Re:Interpreted languages?

[Black Parrot]

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.

Re:Interpreted languages?

[Anonymous Coward]

If this is all based on business applications then I'm surprised there weren't more Visual Basic. The C and C++ numbers seem about right. How many office-use applications are actually coded in C? *insert someone else's anecdotal evidence here*

Re:Interpreted languages?

[Jonner]

Java and DotNet code is usually interpreted and/or JIT compiled and the term "interpreted language" is nearly meaningless. However, the article is almost useless as it says nothing about how the code samples were selected.

Re:Interpreted languages?

[MenThal]

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

Oh, Mistress Ada, I've been a baaaad boy!

:P

Java apps are probably most widespread

[coder111]

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

[stompertje]

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

[coder111]

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

[gstoddart]

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.

Re:Java apps are probably most widespread

[Anonymous Coward]

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

Re:Java apps are probably most widespread

[Anonymous Coward]

If you look at enterprise world (which is what they analyzed) you'll see that either Java or C# are most widely used.

That's incorrect, Java and C/C++ apps vastly outnumber C# apps. C/C++ apps alone account for more than 3x the number of C# enterprise apps in the wild.

Re:Java apps are probably most widespread

[Squidlips]

That is very scary considering what a crap language C++ is. Just think of all the stack overflow and heap corruption potential there! Fixing a bug in C++ is orders of magnitude harder than Java, despite what the nerdly Java bashers would have you believe.

Re:Java apps are probably most widespread

[cyber-vandal]

It also means you get retrained COBOL developers like me with nearly 20 years IT experience. I might not have a CS degree but I do know how to talk to users in a way that doesn't piss them off.

Re:Java apps are probably most widespread

[Jeremi]

Fixing a bug in C++ is orders of magnitude harder than Java, despite what the nerdly Java bashers would have you believe.

Nerdly Java basher here to say you're absolutely right. C++ gives you plenty of room to shoot yourself in the head, and if you don't know what you're doing you can spend weeks or months trying to track down memory corruption bugs due to bad dynamic allocation handling, or memory leaks, or memory corruption. Most of those errors are much harder (or even impossible) to make in Java.

The upside of C++ is that if you do know what you are doing, you can make programs that would not be possible to write in Java.

Re:Java apps are probably most widespread

[BitZtream]

Said by the guy who has no idea what he's talking about.

Re:Java apps are probably most widespread

[david_thornley]

No, that would be crap C++ programmers. Heap corruption is very rare with the proper use of smart pointers and container templates. Of course, if you write C++ like it was C with addons, or like it was Java, you're going to wind up in trouble.

range of capability, expression, and process

[Speare]

Sure, it's easy to conclude that teams writing COBOL programs have more development discipline, but there's also something to be said about the overall complexity of the languages. There are huge differences in the range of capability in the core language, the range of different expressions to solve the same problem, and the range of handling different modes of process (serial, concurrent, federated, etc.).

Re:range of capability, expression, and process

[King_TJ]

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

[NoNonAlphaCharsHere]

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

[DarkOx]

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.

Re:range of capability, expression, and process

[Anonymous Coward]

Rubbish. COBOL code is pretty much business only and that means handling monetary logic. That results in pretty thorough testing. Java code could be for anything, with the attitude, "[click][click]yup, that's working". If it's broken, it'll can be fixed later, because a bug in a widget isn't that important compared to accounts.

Coding Practices?

[Murdoch5]

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?

[NoNonAlphaCharsHere]

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?

[Murdoch5]

I know you not joking, I've been told the same thing.

Re:Coding Practices?

[metalmaster]

line formatting and variable names fit into code maintenance.

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

Re:Coding Practices?

[Murdoch5]

Actually to top that I was once told that comments make the code harder to read because it breaks the code up. That's not a joke and I'm going to say what company told me that but it's by fair the most insane thing I've heard. I had to take 20 comments out of my code in order for it to pass a code review.

Re:Coding Practices?

[gstoddart]

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

And, as a developer who has done code reviews for a long time ... I've had to tell other developers the exact same thing. Because it was too fscking terse.

In our shop, you needed a comment before your function describing what it was for, magic numbers were strictly verboten, and we expected function/variable names to actually have some descriptive value so we can tell what they're for, and anything non-obvious needed a comment.

We'd still get functions with three-letter names which were meaningless, variables like "b1" and "b2" which conveyed no information whatsoever, and generally crap code. Those guys didn't last long because they couldn't understand why their code was unusable in a production codebase.

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

Maybe because there was no irony? I've seen a bunch of young coders who claim that their code is so elegant and obvious as to be easily maintained. I've also shoved the same code back in their face after 3 months and said "fix this", which got me a "what's it do"?

If you think there should have been irony in his statement, maybe your code isn't very good.

Always assume that someone half as clever as you think you are is going to be fixing that code with great time pressures and in the middle of a bad day ... because quite likely, even if it's your own code and you fixing it, that will be true. People who act otherwise are likely a liability in the long run.

I have seen far too many coders who thought they wrote clever code, but after six months couldn't follow their own logic in order to be able to debug it. If the original author can't debug it, WTF is anybody else going to do with it besides rewrite it? (Something I've had to do before.)

Re:Coding Practices?

[Anonymous Coward]

And if neither of you understand what your manager was saying, I don't *ever* want to be in a position where I have to touch your code.

Re:Coding Practices?

[NoNonAlphaCharsHere]

I guess my post was too terse.

Re:Coding Practices?

[sycodon]

Give that man a drink and a woman!

Re:Coding Practices?

[gknoy]

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

Re:Coding Practices?

[DerekLyons]

You act as though these are binary tests - either true or not true. Nothing could be further from the truth.

Re:Coding Practices?

[Black Parrot]

Actually to top that I was once told that comments make the code harder to read because it breaks the code up. That's not a joke and I'm going to say what company told me that but it's by fair the most insane thing I've heard.

I had someone who didn't want comments because "sometimes they're wrong".

Re:Coding Practices?

[Black Parrot]

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

Your list is redundant. (1) and (4) follow from (2), and (2) follows from (3).

Readability is the single most important property for any program that isn't a one-off solo hack.

Re:Coding Practices?

[gstoddart]

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

Re:Coding Practices?

[chooks]

FYI - egoless programming is talked about in the book Code Complete (Amazon link). This is a great book for beginning programmers (and heck, even those whose neck beards are getting longer...) I read it early on in my career and it left quite an impression, the concept of egoless programming being one of the more lasting ones.

Re:Coding Practices?

[Anonymous Coward]

Agreed. Debugging is 2x hard as coding. If your code requires 100% of your brain to write (because you want to make it too terse), you'll never be able to debug it later.

Re:Coding Practices?

[gstoddart]

I read it early on in my career and it left quite an impression, the concept of egoless programming being one of the more lasting ones.

Indeed, and not even just for coding. On a recent project where I was sort of the de-facto technical lead, that was pretty much how I approached all problems .. throw it open, discuss the relative merits, try to decide what works best, and then go with it.

If everyone has a say, you weigh the technical merits and inputs from everyone, and then decide on a best course of action ... everyone feels included, nobody feels like they're being told "because I told you so", and everybody has buy in to the end decision.

The people who were in charge were consistently impressed at how we did such things, and very pleased with the end results. It's more about learning to play well with other children and arrive at the best available solution as it is about being right.

We managed to deliver a huge software rollout in a very large and complex environment, and the general consensus from management was that we'd managed to do it without any infighting and bruised egos -- and a very good focus on the end goal. My own manager was completely delighted with how we did it and seemed to think that, in part, I had been a key factor in that. I'd like to think that was because I tried to approach it from an egoless angle -- it wasn't about me, it was about what we we trying to do.

The trick to herding cats is to try to convince them all that over here has something really cool and we should all go there. Once that happens, it makes a lot of other things go smoothly. And, in my experience, generally yields better results.

Re:Coding Practices?

[dskzero]

You two guys have no idea what it's like to work as a developer, right?

Re:Coding Practices?

[dskzero]

It was a terrible attempt at being "clever".

Re:Coding Practices?

[Murdoch5]

Agreed, Write code as it logically makes sense and leave comments in the code so when you go back to it in 6 month it only takes a few minutes to figure out what you meant to do.

Re:Coding Practices?

[hughbar]

Oh I do so agree, especially as I write and maintain Perl. 'Good' variable names, comments and simplicity make things so much easier for the next person. I'm 61 and the ration quoted is one unit of development to five units of maintenance, so these simple and sensible things become really, really important. There's no virtue whatsoever in 'clever', terse, hard-to-understand and probably badly formatted code.

Re:Coding Practices?

[BitZtream]

And both of you were too stupid to recognize the point, eh?

Re:Coding Practices?

[Murdoch5]

What point? I don't know what point were talking about at this exact point in the multiple convo's people have started.

Re:Coding Practices?

[david_thornley]

I read about it in Weinburg's "Psychology of Computer Programming", which antedates "Code Complete" by quite some time. Egoless programming is one of those things that's pretty much obviously the right thing to do (once explained), has been written about in excellent books for a long time, and is surprisingly rare nowadays.

Re:Coding Practices?

[swillden]

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.

Yeah? Well I recently got a peer review comment during the annual performance evaluation cycle that said "His code is some of the most straightforward, transparent and understandable I've seen."

Dude, I'm thinking about getting that quote framed and hanging it on the wall, I'm that proud of it. It helps that it's from a guy who's brilliant, writes beautifully elegant code himself, has nearly 30 years' experience at it and has given me a lot of tremendously insightful feedback in design reviews, but regardless fo the source, the statement itself is some of the highest praise I've ever received, IMO.

That's the standard that professional programmers should strive to reach, that their code is utterly straightforward, transparent and understandable, no matter how complex or tricky what they're implementing may be. It's a goal that will never actually be achieved, except for trivial code, but there's huge value in the effort. Conciseness aids understandability, but terseness hurts it.

Re:Coding Practices?

[donscarletti]

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.

See point 2 and 3 on your list. Variable names and line formatting helps the maintainer understand the code's function and structure, which is going to impact point 1 and 4 down the line too. Anyway, just use an editor that mandates consistent line indenting and highlights spelling errors in identifiers and those stupid things should vanish with no human effort required. As such tools are plentiful, there is no justification for leaving your documents unmanaged.

Re:Coding Practices?

[donscarletti]

I think a lot of people here got a deep sense of pathos for your coworkers when they saw what you had written.

Re:Coding Practices?

[Anonymous Coward]

For a lot of folks, this is too terse:

month = month%12 + 1;

while this is ok:

if (month==1) month = 2;
else if (month==2) month = 3;
else if (month==3) month = 4;
else if (month==4) month = 5;
else if (month==5) month = 6;
else if (month==6) month = 7;
else if (month==7) month = 8;
else if (month==8) month = 9;
else if (month==9) month = 10;
else if (month==10) month = 11;
else if (month==11) month = 12;
else if (month==12) month = 1;

Cobol is still being used?

[Anonymous Coward]

Where?

Re:Cobol is still being used?

[Lawrence_Bird]

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

Re:Cobol is still being used?

[bitroli]

In your bank.

Re:Cobol is still being used?

[TheRaven64]

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.

Re:Cobol is still being used?

[Anonymous Coward]

"A computer without COBOL and FORTRAN is like a piece of chocolate cake without ketchup or mustard." — a fortune cookie from the Unix

Re:Cobol is still being used?

[Black Parrot]

Where?

If you have a job, it probably prints your paycheck.

Re:Cobol is still being used?

[Anonymous Coward]

You're not allowed to re-quote that unless you've tried ketchup and mustard on an Oreo.

More Seasoned Coder?

[Anonymous Coward]

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

[Anonymous Coward]

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

Re:java

[BitZtream]

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.

so useless

[Anonymous Coward]

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

[Anonymous Coward]

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.

Re:You need a good teacher

[BitZtream]

Perhaps you should have been trying to switch classes instead. Both Sun and IBMs JVM are rather verbose when it comes to dealing with that sort of thing. Sounds like you don't even have the most basic of troubleshooting skills, which pretty much entirely precludes you from doing any sort of useful programming.

What the programs do...

[jellomizer]

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

[DarkOx]

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.

Re:What the programs do...

[BitZtream]

Except that the majority of Java code is backend servers with no GUIs, but hey, you go on thinking silly things like.

Good metric

[Alwin Henseler]

(..) 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:Good metric

[Anonymous Coward]

Why? What is the lifetime of a smartphone model, and is their software ever actually updated? At this time they are basically throw-away items, like fries at McD's, so it is probably not worth that effort.

Re:Good metric

[dkf]

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

You'd think so, but evidence says otherwise. After all, many OSes are still released with bugs in!!!

(Runtime patching seems to have become a bit easier over the years, which reduces the pressure to get it right first time. This is both good and bad I suppose; releasing sooner is a good thing...)

Re:Good metric

[Anonymous Coward]

But software isn't popular until it has masses of users bashing at it.

Marketing

[Anonymous Coward]

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?

[Anonymous Coward]

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.

SQL too

[tepples]

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

[toadlife]

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

[Anonymous Coward]

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

Re:SQL too

[sadness203]

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

Re:SQL too

[S.O.B.]

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

PHP is no more or less vulnerable.

Re:SQL too

[toadlife]

It was meant as a fucking joke. Jeebus guys, have some more (or less) coffee. ;)

Re:SQL too

[CastrTroy]

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

[fotoflojoe]

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

Re:SQL too

[tbannist]

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.

Re:SQL too

[Anonymous Coward]

I'm thinking my MongoDB backed web app is pretty safe from SQL injection.

Re:SQL too

[Anonymous Coward]

Yes, but in all SQL injection cases you'll notice the code uses mixed case SQL hence the vulnerability. When will people learn to always use ALL-CAPS SQL statements!?!

Re:SQL too

[EdIII]

That's sad. It's the programmers behind it. Whole point of the article really, which is how many newbie programmers come in without the fundamentals. Most don't need to know how to "program" but to develop. They just collect code snippets and 3rd party modules and stitch them together.

SQL injection is easily mitigated if you know what you are doing and pay attention to detail. Small websites can have great security just because the guy responsible paid attention to detail.

I was just on a website for a top Fortune 500 company and whatever code monkey they hired did a terrible job with sanitizing and validating data in the fields. Employee was complaining that there was something wrong with our "email". Their email address was on the form, but being rejected. I looked at it and intuitively I guessed the guy did not perform a trim on the input before attempting to validate the email address. Checked the end of the email and there was a single white space character. Removed and submitted the form and the angry employee went on with their work.

SQL injection attacks exist precisely for the reasons that Bill Curtis outlines.

Re:SQL too

[jedidiah]

You haven't seen any because something like the web is far too new for Cobol coders or their apps.

Re:SQL too

[DigitalisAkujin]

PHP coder here.

No no no no!!!!

Using mysql_real_escape_string WILL NOT PROTECT YOU from SQL injections.

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.

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

Re:SQL too

[znrt]

I'm thinking my MongoDB backed web app is pretty safe from SQL injection.

url?

Re:SQL too

[DigitalisAkujin]

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

[Anonymous Coward]

Posting AC, but I _have_ seen COBOL web applications vulnerable to this. If you use string concatenation to make a copybook record and just send it over to cobol which hase hardcoded non parameterised SQL, you get a SQL injection attack no problem.

01 SQL to run
  07 filler value 'select * from table where field =
  07 FIELD-VALUE PIC X (10)
  07 filler value ';'

This is doubly bad because the COBOL SQL programmers always assume you are reading clean input from a VSAM record, because why would you ever have a VSAM record with SQL in it?

Re:SQL too

[Anonymous Coward]

Who are you... TROLLFACE? This is patently, idiotically false: Using mysql_real_escape_string WILL NOT PROTECT YOU from SQL injections.

Re:SQL too

[tepples]

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

Which is why MySQLi has the object-oriented style $db->escape_string() to escape a string correctly for a given connection.

not to mention that before mysqli, you couldn't even use prepared statements.

And even with MySQLi, you still can't use prepared statements with a variable number of ? placeholders, such as statements using operator IN or produced through a query-by-example engine, without a lot of pain.

Add that to the fact that PHP is what is avaiable on cheap web hosts

Not to mention MySQL. All the popular PHP blog, forum, etc. apps target MySQL because too many cheap web hosts decline to offer PostgreSQL.

Re:SQL too

[cduffy]

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

[thetoadwarrior]

They probably should have named it better. PHP is a fucking mess.

Re:SQL too

[tepples]

No no no no!!!!

Using mysql_real_escape_string WILL NOT PROTECT YOU from SQL injections.

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.

What's the precise difference between failing "to filter your inputs" and passing on "a character that would break SQL"? It might be easiest for me and other readers to understand this difference if you give an example. I use parameterized queries almost everywhere but not everywhere because of the difficulty of setting up MySQLi's $db->bind_param() correctly for a variadic query.

Re:SQL too

[hpoul]

what exactly is the problem with 16GB of RAM? it's about the same as subscribing in the apple developer program for a year..
(sure i never cared about building android, so no idea which parts require 16 GB of ram to compile, or why i can't use swap space.. but anyway .. i guess when i'm investing tons of time playing around with a platform, i could afford the 100 USD upgrade.. i guess gamers spend more so they can buy yet another game - i know i did)

Re:SQL too

[Darinbob]

http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html

Re:SQL too

[S.O.B.]

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.

Re:SQL too

[ksd1337]

Well, that's because you're probably running NetBSD on your coffee machine.

Re:SQL too

[DigitalisAkujin]

Not implying that iOS mobile is any better.

Just sad by Google's choice with Android.

Re:SQL too

[jd2112]

You haven't seen any because something like the web is far too new for Cobol coders or their apps.

There are plenty of COBOL based web apps out there, mostly on corporate intranets. The web presentation part is usually done with Java or .net though.

Re:SQL too

[TheSpoom]

Where do I begin?

Using mysql_real_escape_string WILL NOT PROTECT YOU from SQL injections.

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

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

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

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

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

Re:SQL too

[BitZtream]

Funny, I used to work on a COBOL web app.

If you want a shining example of COBOL web apps ... www.irs.gov

Some of the most important web apps in the entire world run on COBOL. And for reference, Facebook is in no way 'important'. That little bit of perspective might be a good start for you.

Its so cute how newbies think they know so much about technology yet your lack of experience and wisdom makes you so ... funny to watch.

Loose the arrogance and learn yourself some history, trust me, you'll save yourself so much freaking time its not even a little bit funny.

Re:SQL too

[TheSpoom]

Also apparently I stuttered when typing cross-site scripting. Sorry about that.

Re:SQL too

[petermgreen]

And even with MySQLi, you still can't use prepared statements with a variable number of ? placeholders, such as statements using operator IN or produced through a query-by-example engine [pineight.com], without a lot of pain.

Does mysqli support named placeholders? I've found writing code that generates queries isn't too bad if you have named placeholders as any desyncs between the loop that generates the query and the loop that fills in the parameters will be immediately apparent.

for example some code of mine (using PDO rather than mysqli) that generates a parameterised query.

http://isis.philpem.me.uk/hg/isis/file/9364d6277308/app/models/searchmodel.class.php

Re:SQL too

[Synerg1y]

See this is what original article means by "people with no strong computer science background", OP was joking about the caps, they have nothing to do with the code base besides how the code displays.

Re:SQL too

[sapgau]

+1
Prepared statements are essential for preventing SQL injection.
If your DBMS doesn't support them then you have bigger things to worry about.

Re:SQL too

[BitZtream]

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

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

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

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

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

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

It's sad that it takes 16GB of RAM just to compile a build of Android. And the funny thing is it kills the whole point of Android being "open". What person has 16GB of RAM on the off chance that they might wanna compile an Android build?

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

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

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

Re:SQL too

[petermgreen]

what exactly is the problem with 16GB of RAM? it's about the same as subscribing in the apple developer program for a year..

Depends if you already have the CPU/MB to support it.

But I think the 16GB figure is rather exaggerated unless you are doing frequent rebuilds of the whole stack. (see my other post for why)

Re:SQL too

[Anonymous Coward]

I read somewhere earlier today that the 16gb spec is a recommendation only, and gets you a tolerable build time.

Fortunately I have no particular need to build android from source. :)

Re:SQL too

[petermgreen]

The full quote is

"Here are some preliminary numbers. Final numbers will probably be a bit different, but those should be a reasonable first-order approximation. Of course, your mileage may vary.

- 6GB of download.
- 25GB disk space to do a single build.
- 80GB disk space to build all AOSP configs at the same time.
- 16GB RAM recommended, more preferred, anything less will measurably benefit from using an SSD.
- 5+ hours of CPU time for a single build, 25+ minutes of wall time, as measured on my workstation (dual-E5620 i.e. 2x quad-core 2.4GHz HT, with 24GB of RAM, no SSD).

It sounds like he was building with -j16 or so (he has a hyperthreaded dual quad core so 16 virtual cores and his CPU time figure is 12 times his "wall time" figure and not every job will be using the CPU all the time) on a box with 24GB of ram. Extrapolating from there I'd think you would be more than fine with 8GB and -j4. If you have a quad core with hyperthreading then you probablly also have a machine that can take 16GB of ram

Of course if you have a dual socket monster you will want more ram so you can run at higher -j values but on single socket quad core systems you probablly won't gain much from values over 4 or 5 (a friend of mine tells me that they find stuff compiles quicker with -j5 and hyperthreading disabled than with -j9 and hyperthreading enabled. YMMV).

And unless google have been real idiots with the build system you really shouldn't need to rebuild the whole stack very often.

Re:SQL too

[sapgau]

Always read Joel with a grain of salt... and a couple shots of tequila to get you to the end of the article!

Re:SQL too

[Roger Lindsjo]

Well, of course it is easier to inject stuff into big capital letters such as "O" compared to lowercase "o". There is a lot more space to inject into. And easier to hit.

Re:SQL too

[EdIII]

I found it a good read.

Joel has some pretty damn good points in there. Although, common languages can be hard enough to weed out the weak programmers. You just need to place operational and performance constraints on the produced work.

For example, anybody with a basic understanding of databases can create one. Understanding transactional databases, indexes, and how to optimize a database for large datasets by understanding your data is what distinguishes a MySQL monkey from a true database professional. Ask them if they understand index selectivity and see if their eyes gloss over.

Pointers are really useful to understand if you are going to make programs. That is not where most of the work is today. The money is in interpreted languages and document standards like PHP and HTML. CSS will get you a fair amount of money simply because it was a created industry vis-a-vis the browser/rendering clusterfuck that we have today. Any code monkey can make a functional web page. Make a web page that is rendered and operates the same way on all browsers and you are ahead of the curve.

Sadly, adequate PHP programmers are becoming rare because newbies are just concentrating on Wordpress and plug-in modules. It's the difference between building your computer components and just assembling them into a computer. You may understand what a hard drive *is*, but you can't *build* one.

Recursion is something I use all the time. It's useful. However, very few newbies even understand it conceptually. It can be an efficient and elegant solution to a problem.

I get Joel's point. Although I learned recursion in elementary school, my CS course in college was quite difficult. No object oriented anything and I had to create polymorphic classes. That was really cool and intense. It even applies today since I can write whole classes in PHP that extend other classes. Not the same thing of course, but similar in concept.

Re:SQL too

[ca111a]

BHB for true symmetrical redundancy.

I think OHO would be even better... Or, OOO. But, of course, if you really want true symmetrical mufti-dimensional redundancy, then you have to go with just O

Re:SQL too

[kat_skan]

Shows what you know.

Re:SQL too

[Ksevio]

Though it's also worth noting that poorly written SQL statements can still be injected even using mysql_real_escape_string. Something like

"SELECT * FROM table WHERE x = ".mysql_real_escape_string($_GET['input'])

Putting quotes in the statement would fix it (though that's still a messy way).

Re:SQL too

[mvdwege]

[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

Re:SQL too

[cshark]

Really? I've never had trouble with it in php. It's a real bitch on anything connected to SQL server.

Re:SQL too

[Anonymous Coward]

It doesn't take 16GB of RAM to compile Android. That's what they recommend, but I've compiled it with 8GB, and I know people that have done it with 4. It just takes a longer.

Re:SQL too

[cshark]

Oh please. Escaping your strings isn't enough. Any half way intelligent hacker knows that all you have to do in order get around that is screw with the character set. Seriously, even the wanna bunnies at Anonymous know that. You're not even talking about PHP though, and that's what I find annoying. PDO Let's you use prepared statements, but that's not php either. See, the problem with people who say clueless things like this is that it demonstrates that they're either totally uneducated at the difference between a language and an api, or they're working in Microsoft world. Same basic idea. PHP itself is neither good, nor bad with injection attacks, because PHP is a language. MySQLi isn't even a requirement for installing it. If you don't like MySQLi, try PDO or any of the others. Why not be adventurous and do something other than write poorly constructed mysql database apps? I mean, if you don't know the difference between an api and a language, it's safe to say that you won't be able to write anything in any language that scales for shit.

Re:SQL too

[Anonymous Coward]

He's a Microsoft flunky. Can't you smell the ignorance?

Re:SQL too

[frank_adrian314159]

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

Re:SQL too

[david_thornley]

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

Re:SQL too

[viperidaenz]

Java has had prepared statements since it was invented. You'd be surprised by the amount of string concat sql statements I see coming from developers mostly from India

Re:SQL too

[swillden]

Well, I have never even seen any vulnerable Cobol web applications

Have you seen any COBOL web applications, period?

For that matter, how many COBOL applications even use those new-fangled relational databases? SQL injection isn't a problem if you don't have SQL.

Re:SQL too

[euroq]

No software is "important" with quotes in it. Only friends, family, health, and happiness.

However, if there were "important" software, Facebook would be one of them.

Re:SQL too

[euroq]

First of all, 16GB of RAM to build an operating system isn't a big deal and has NOTHING to do with Java. Second of all, you don't need 16GM of RAM to build earlier versions of Android. Third of all, if you're making your own build of Android for the fun of it, you should be able to afford 16GB of RAM which costs nothing compared to the hardware you would be installing it on.

Second of all, why do you think the example you gave is a bad thing? Were you expecting other developers to cower from such frightening code? Why would another language make what you wrote there better? Was it the 4 method calls in one line, and a string concatenation? Do you understand what's going on there? That is OS-level code, which has to do with loading code dynamically, also past a certain security threshold, of which 99% of apps don't need to do. It would be more complicated in C-Windows or C-Linux than in Java-Android.

Java has the advantage of having many developers - which allowed Android to be picked up by many. It was a good choice by Google.

Re:SQL too

[Anonymous Coward]

First, let me say "BRAVO!" to your post - I agree with an immense amount of insight in it, and my experiences echo yours in spades.

Now, allow me to add this bit of "analysis": another reason that the Java situation sucks ass, as related in your point about the "fuckton of really shitty [pseudo-techs] who think they are developers", is that the "REALLY REALLY REALLY shitty" techniques used to create bloated pile-o-crap applications is DECLARED BEST PRACTICE ! ... and not just by a few, but the whole damned Java "community of practice" ! ... and not just casually, either - its to the point where far more capable people are BANNED from using other technologies, or even deviating from the enacted policies of crappy coding techniques, in a "not only must you use Java for everything, but you must use it in THESE ways" form of incompetent fascism.

Re:SQL too

[rossy]

BitZStream.
Nicely done and fucking awesome post. Best /. Read for me in years.

Re:SQL too

[terjeber]

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

Isn't PHP an anti-pattern all by it self?

Re:SQL too

[terjeber]

for example some code of mine (using PDO rather than mysqli) that generates a parameterised query.

http://isis.philpem.me.uk/hg/isis/file/9364d6277308/app/models/searchmodel.class.php

Honestly, that was one huge anti-pattern.

Re:SQL too

[CptNerd]

So what is C and C++? Chopped liver? I mean a "programming language" is any language that you can write programs with, including assembler, which can read and understood by either a computer program (compiler) or a human being.

ObOldFart: I also had compiler design classes in college about 30 years ago, and have since used yacc/bison and lex/flex for "small languages" since, so I know a little about "programming languages," Junior. And get off my lawn.

ObOriginalPoint: I agree with the article summary, since languages are so easy to create, we should have "mini-languages" that are specialized for particular tasks. They could be fairly simple in syntax, and specialized in semantics, and have a framework of OS-level tools that they could all access. The programs for those solutions could then be simpler, because they wouldn't require the additional overhead of the Java compiler, for example, and they might even be easier to read, given the simpler syntax/semantics.

'Frinstance, if you have a task that doesn't really need to be worked using an object-oriented design, use a small language that's more functional, or in some other way more closely matches the description of the task. It would be easier to do that than to try to shoehorn a design into a language that isn't a good match, and which probably requires syntactic or semantic hoops to jump through to achieve the same results a simpler program could supply.

Bottom line though, people need a sound grounding in computer science theory, before anything else. At least OS, compiler, and data structure theory.

Re:SQL too

[on the 8ball]

The quality of "official" documentation in the PHP manual is laughable. Almost all the useful tips that I have found when looking for answers have been in the user-contributed comments. To say the official docs are "sparse" is being kind. Why give a detailed explanation of the method and its parameters with examples when a short, vague sentence will suffice?

In general, it seems to me that the quality of documentation for open-source software like PHP is pathetic, compared to best practices. I don't know why this is, but it is true. Maybe open-source developers lack an understanding how important documentation is, or maybe they just cannot write clear, helpful explanations and examples, or cannot get out of super-geek mode enough to understand the needs of the average developer who is just looking a quick, useful explanation?

I am an application developer with 40 years experience and have written a ton of docs for software that I wrote. I'm sure not perfect but my docs are a lot more detailed and comprehensive than most of what I see coming out these days. (I know, old geezer complaint, "you damn kids - get off my lawn"!!) Comments welcome (ideally non-snarky and useful ones please)! Flamers just shut up.

Re:SQL too

[Anonymous Coward]

Whoa, I'd mod you to +6 if such a score existed, I had karma and weren't an AC. But apart from that...

Re:SQL too

[Azetkt]

I built Android 4.0 on an old laptop with 2 GB of RAM. Took 5 1/2 hours, which is too slow if you're a developer, but fine if you're just playing with it, like me.

Students!

[gman003]

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:Students!

[Relayman]

I'm wondering if it's the inexperience of the programmers or the sloppy programming techniques that they're taught. How many Java routines check for valid inputs? What happens when a mouse routine is fed coordinates of (5280 feet, -1760 feet)? Does it crash?

Re:Students!

[gman003]

Well, my code does, and wouldn't crash, but I've seen some of my classmates'. Their understanding of "input" is rather poor, let alone "sanitized input".

Re:Students!

[Relayman]

Good. In the real world, crappy input happens every so often and your program should have a way of dealing with it without crashing.

So, stuff made 30 years ago...

[Anonymous Coward]

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

Re:So, stuff made 30 years ago...

[Black Parrot]

...is better than the stuff made now?

Yeah, 30 years ago we got everything from Korea instead of China.

You'd be very wrong about that

[Anonymous Coward]

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.

Re:You'd be very wrong about that

[sapgau]

Live and learn...

Fewer != less

[Anonymous Coward]

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.

Chasing rainbows & comparing apples to oranges

[Anonymous Coward]

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

Lords of COBOL hear my prayer...

[_0x783czar]

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

[b4dc0d3r]

You don't need a JVM, you can go directly to machine code.

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.

Re:Lords of COBOL hear my prayer...

[_0x783czar]

That's a good point about the JVM. And you're right, there's a lot of garbage code being written out there in Java, it seems to be the curse of the popular.

Re:Lords of COBOL hear my prayer...

[Anonymous Coward]

I cannot speak anecdotally regarding the JVM, but I can regarding the Python VM. Which much like the JVM has been actually reduced to run on a chip at one point.

It actually...can fit in 4 KB.

While I agree it will never reach guru level -- some of this actually runs faster than non-optimized C even with the overhead.

You're probably saying "WTF?"

The trick is to understand... a highly expressive language, implementing a "concise" (but non-trivial) program in it that language...may be smaller with the bytecode and VM than an implementation of the same task in C.

Rephrasing -- sometimes a tersely written python program and the VM can fit entirely in CPU cache. And when this happens... it runs *fast*.

I'm sure if you optimized the hell out of C, you could do the same thing by definition of algorithmic decomposition ... but there gets to be a point where readability is more important.

I suspect this is possible with Java as well.

So don't call the JVM inferior. Just make sure you use the right language for the right task. Sometimes not being close to the metal is a good thing.

Re:Lords of COBOL hear my prayer...

[_0x783czar]

Like I said, it's likely more Psychological than real. It stems from the problems with JVM which are non-existent on modern machines. (also it should be noted that Python has an interpreter not a VM, but your point remains valid just the same.)

Is this article from 1978?

[edibobb]

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

Re:Is this article from 1978?

[Anonymous Coward]

that's okay, most "enterprises" don't use good software engineering for other languages either, making it a level playing field.

Re:Is this article from 1978?

[Relayman]

"Not, non": Double negative? I would venture to say that it is possible to write a COBOL-based system that could put a man on the moon. This isn't punch-card COBOL we're talking about; it has been extended so it can do all kinds of neat things. Like generate HTML or XML.

Just like.....

[hesaigo999ca]

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

Re:Just like.....

[BitZtream]

What happens is the ratio stays the same, perhaps you should RTFA before you call half the oranges apples.

Re:Just like.....

[hesaigo999ca]

Careful, your newbieness is showing

Fewest!

[Anonymous Coward]

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

[Anonymous Coward]

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

[mwvdlee]

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

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

Re:Chasing rainbows & comparing apples to oran

[Nadaka]

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

Not counting waterfall programs

[Anonymous Coward]

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

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

Well of course!

[Anonymous Coward]

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?

[Anonymous Coward]

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

[Anonymous Coward]

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

The languages deserve a lot of the blame

[Shivetya]

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

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

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

Doesn't say 'buggy'

[Anonymous Coward]

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

Valid comparisons?

[Phlow]

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

What about that Y2K thing?

[dilbert627]

That might skew the cost on COBOL's side a bit...

Root of all (software) evil

[luis_a_espinal]

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:Root of all (software) evil

[Lumpy]

Yup.

In my field of embedded programming a CS grad is worthless. If you dont have an EE degree you will never be able to write the code. You have to understand what the voltages coming in MEAN. Understand transistors, logic devices, feedback loops, etc...

The last CS grad we hired was completely worthless. Dude did not even know how a microprocessor worked. Almost all CS grads know nothing at all about computers.

Re:Root of all (software) evil

[walterbyrd]

I have worked in IT for 32 years. As I remember, most of the old COBOL developers did not have a computer "science" background, or any formal education beyond high school. In fact, few colleges back then even had a CS degree. I can remember when developers (called "programmers" back then) where promoted from computer operators.

Re:Root of all (software) evil

[BitZtream]

Awe how cute, you think the only people capable of doing EE are people with EE degrees. Funny history shows some of the most important EEs in the past hundred years had no degree in EE.

Likewise, its cute that you think that CS is worthless for writing code for embedded devices. Your attitude alone is enough to fire you in my opinion.

Re:Root of all (software) evil

[donscarletti]

I think he said it in just a nice, palatable way. I would have said that many people who are going into Java now just didn't have much of a plan after high school and computers seemed like a reasonably tolerable career.

No, no, I can give a better explanation. A Java programmer my age was the guy in the front of the maths/physics/chem class in highschool that was forever asking dumb questions but at the class test that show's he didn't understand the topic but somehow he would manage to get full marks in assignments despite mediocre test scores and he'd have the same grade as me by the end of the term, which he would be sure to point out to me.

A Java programmer my age 5 years ago was the guy who took only the minimum of 2 honours level classes in his final year of undergrad (winding up with lower seconds), but then does a 1 year coursework masters at the same 3rd tier university, taking all the easiest honours level courses (those requiring no maths and little programming) and then spends the rest of his life making sure that he subtly mentions that he has a master's degree to any peer who might listen.

This is what Java programmers are, they're not smart, but they stick at it. They do have a CS background in the sense that they don't really have any other background. They write awful code, but they shotgun debug it until it works, leaving in all of the mess and dead code right there or commented out.

Re:Root of all (software) evil

[donscarletti]

Typical CS skillset is optimised towards large systems, optimisation techniques are based on scalability rather than managing individual instructions and registers. CS people are great and managing huge codebases and datasets, most don't know anything about small systems where there is a completely different set of goals and constraints. Just like I have not met a single EE that can write legible code over 50 lines (and most embedded projects are well over 50 lines).

Though if you're smart and have a related set of skills, you can pick it up new things fast enough.

Re:Root of all (software) evil

[Lumpy]

No, what I am saying that that people with a CS degree cant program a system that relies on EE knowlege, in fact I said that quite clearly.
No worry about you firing me, The janitor cant fire people.

COBOL...Bedrock of IT for 50 years

[sycodon]

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.

Re:COBOL...Bedrock of IT for 50 years

[Darinbob]

My payroll gets messed up and I get mad. A web site screws up and I think "meh, what do you expect?"

Two programmering language

[geekoid]

one requires training and adherence to good practices, the other can be used by any Jaba to slap some shit together.

No surprises here.

Backend vs Frontend

[karmicoder]

From my experience with financial companies, COBOL still is entrusted as the God of all Data and backend processes, but almost no user input is provided directly. In fact, most of the COBOL I've worked with has ASSUMED that the data is good and non-malicious. Either that, or the security checks were in the user interface code, which was abandoned 20 years ago. My guess on this? The COBOL still out there has very small attack surface...it's encased in a warm, porous, gooey layer of Java/PHP/.NET/Ruby/Groovy/Grails/G-g-g-g-g-unit! The fact that PHP (and to a lesser extent, Java) was designed by and for script kiddies does not help either, buy hey!

COBOL

[stixn]

Great features for masochists to maintain horribly engineered legacy systems, including (but not limited to):

No recursion or dynamic arrays: hard coded implementations at compile time, off by one errors, limited toolset

Global comm(memory) access is the rule: ad-hoc code, debugging errors due to opverlaid memory can take days

Lack of OO Concepts: lack of abstraction, repeated code, ad-hoc code

No automated testing: unavoidable code rot, makes TDD impossible, ad-hoc code

Lack of frameworks or simple library functions: no option but to always rebuild the wheel

Horrible IDEs: Completely inaccessible (try downloading a COBOL compiler), Worse to code in than notepad, costly and eternal vendor lock in (hope you like micro focus)

COBOL Culture: Programmers are a dime a dozen, Analysts with domain knowledge and no technical ability are awesome

I know why.

[Lumpy]

Java apps are to be written as fast as possible without sleep and you have ZERO time for debugging and testing before it ships.

Cobol apps are designed properly, go through reviews, testing, more testing, and the programmers are given the time to perfect it.

Re:huh??? Wake up!!!

[geekoid]

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.

C'mon, you know why don't you? Really, you don't?

[Anonymous Coward]

C'mon guys, maybe I missed someone commenting on the extremely obvious, but COBOL code is less "buggy" because COBOL code does 1/10,000th of what Java code does. COBOL code is several orders of magnitude simpler and the problem space it addresses is so very small compared to Java.

As proof I'll create a computer language with 10 commands that simply moves an image of a turtle around a screen. Guess what? 99% of programs written in that language will be bug-free. Why? Because it is a simple language.

Ergo, COBOL is like using a screwdriver to do things only screwdrivers can do while Java is like a whole workshop full of tools that will let you build almost anything and, yeah, you're going to mess up more often building almost anything.

$75 per hour

[cretog8]

How much per hour does it cost to get an OK Cobol programmer to come fix stuff versus an OK Java programmer?

There are lots of possible reasons for the disparity, including, as others have pointed out, that a "line of code" doesn't mean the same thing between Cobol and Java, but if it's going to be reported in dollars instead of hours, then it needs to be made meaningful by the difference in costs for the two languages.

The Lords of Cobol be Praised

[CAIMLAS]

This is pretty obvious as to "why".

Java: mostly written by inexperienced undergraduates and Indians with only a couple months of experience.

Cobol: mostly written by the (relatively speaking) Gods of Computing, in a better age.

So say we all.

The study has the most flaws

[Hentes]

In looking at specific languages, Java EE fared worst at $5.42 per line of code, while Cobol did best at $1.26.

Seriously, lines of code? No surprise this guy favors Cobol, he is stuck in the eighties. So are more compact languages scoring higher for the same number of bugs?

Re:The study has the most flaws

[c0lo]

Re:The study has the most flaws

Why, was it written in Java?

Re:The study has the most flaws

[Hentes]

No but the damage it caused per line is more than 5.42$.

whiner

[Anonymous Coward]

You sound like just another whining bitch who doesn't know what the fuck he's talking about.

First of Sandbox? What the fuck are you talking about, unless you're referring to craplets.

Java programers prefer to work on actual problem, and not spending hours writing memory management boiler-place.

Sorting is hard? Really? Sorting is a waste of effort, the algorithms are already well known, why the fuck should I have to waste my time re-hashing them? That's old shit.

And in java you do have to worry about optimization, memory utilization and algorithm choice; you just don't have to worry about re-implementing shit you learned in a basic data-structures class.

Re:whiner

[0123456]

Java programers prefer to work on actual problem, and not spending hours writing memory management boiler-place.

No, instead they spend weeks tweaking the garbage collector so their program doesn't need 16GB of RAM and doesn't freeze for two minutes to garbage-collect all that junk.

I actually did write 'new' in a C++ program yesterday. That's the first time in months that I've had to do actual memory allocation, and since it's a smart pointer I don't need to worry about freeing it either.

Re:whiner

[Anonymous Coward]

Java programers prefer to work on actual problem, and not spending hours writing memory management boiler-place.

No they like to spend months writing exception handling boiler-plate.

Program Task

[arkenian]

So I'm going to go against the grain. I don't think this is about the COBOL programmers vs. the Java programmers, or the language vs eachother. To me this is about what the software is used for. A lot of Java stuff is used for prototypes, one-offs, etc. etc. and generally in tech-based fields where getting a capability OUT is more important than having it be perfect. COBOL is typically used in the financial industry, which has very low bug tolerance. Plus, of course, the average COBOL program is much older than the average Java program. So:
a.) The number of acceptable bugs in a 'typical' Java program is generally going to be much higher.
b.) COBOL programs have been typically under maintenance and burning down bugs for a very long time

The end result? COBOL programs are less buggy. Nothing to do with the language, not much to do with the programmers, just a result of the different structural realities around the sorts of software written in their respective languages.

Yikes.

[Anonymous Coward]

So here we go again: circle-jerking to the awe-inspiring deities of neon-green font set against black backgrounds... Here's what you have to ask yourself: "Is it really worth it?"

I'm a guy coming close to 30, so right there the lords of bytes around here will assume I know nothing about everything. That's okay--it rolls off me like buttah--but when I graduated from my undergrad back in in the day, I immediately accepted a job-offer from as a COBOL-2 developer. My experience there didn't last more than a year (for many reasons.) One thing I know for sure is that you can't stick any ole Tom, Dick, or Harry into a COBOL seat and expect them to produce gold. Why management at this place thought this about me is totally beyond me. I think it had something to do with some words that were said about me by my instructors because if it wasn't for my instructors, I would have never had the interview in the first place. If you ask me, I think management of these kinds of shops are in a type of "panic mode" because they realize that nobody in their right mind *wants* a job like that regardless of whatever money is on the table. Since the seniors are all retiring or simply getting cut or literally dying off, well, that leaves slim pickings in the wake... For example, I know of only 2 schools in the Midwest that teach that old shit.

Anyway, I worked there for about 1 year and it was one of the most painful experiences of my life, and if you knew me, you'd know that that's saying something. Did I know anything about COBOL-2? Nope, and I never wanted to before I got on board but lured into the web with sweet whispers was I... My intern background at my school consisted of CSS and PHP!!! Ha. After a year and $45,000 worth of depression-assisting salary, starting out, do I *want* to learn more about it with the idea that this starting rate eludes to an unparalleled amount of senior-level salary? Hell no. The job sucked, the projects made you lose hair, the language blows despite being some sort of supposed fantastical feat of modern-day technology, the management personnel are slavers who are almost all prescribed some sort of anti-psychotic drugs and everyone I ever met in that place wore an expression on their face that begged and pleaded, "Help me. Please... Help... Me."

I'll kill myself before I ever return to something like that. I swear to god I will. The management in these kinds of shops realize this kind of reaction, too, which is why you never want to mention to any of them during an interview that you want to get your foot in their door as some mainframe developer just to do something else, like web development... That is, if you're an odd sort and want one of these jobs. Doing so turns them off faster than a light switch and you know it's true if your own recruiter says that to you the night before your interviews.

Say what you want about these "seasoned gods" of COBOL, JCL, and whatever else they dick around with for 365 days each year. Personally, I feel sorry for them because I can't help but think about how much life they've wasted on that stuff. I know, I know... It's my opinion and just someone's opinion, but still... I've seen what goes on in these places and it's a living hell.

Oh, and for whatever it's worth, COBOL people do get tossed out the back door just like everyone else does during bad economies and so forth, high demand or not. I've seen it happen, not only to myself (joking aside), but also to people who WERE seasoned, too. Don't be fooled into working for a big shop just because some snake-tongued manager-type (who can't stare you straight in the eyes) promises you fortune and glory as well as job security. I promise you... I ABSOLUTELY PROMISE YOU, that you WILL live to regret accepting their offer.

Worst job to have on Earth. PERIOD.

GOOD Cobol vs. BAD Cobol, who can tell?

[Anonymous Coward]

How many people these days can distinguish between GOOD Cobol program and BAD Cobol program? Most of so called programmers will not be able to distinguish between Cobol program and cheese sandwich?

Re:C'mon, you know why don't you? Really, you don'

[znrt]

C'mon guys, maybe I missed someone commenting on the extremely obvious, but COBOL code is less "buggy" because COBOL code does 1/10,000th of what Java code does. COBOL code is several orders of magnitude simpler and the problem space it addresses is so very small compared to Java.

As proof I'll create a computer language with 10 commands that simply moves an image of a turtle around a screen. Guess what? 99% of programs written in that language will be bug-free. Why? Because it is a simple language.

Ergo, COBOL is like using a screwdriver to do things only screwdrivers can do while Java is like a whole workshop full of tools that will let you build almost anything and, yeah, you're going to mess up more often building almost anything.

absolutely. the whole story is a joke, this article is just surreptitious advertising for a software company that can't be taken seriously in anything IT related just for being capable of producing such nonsensical, laughable marketing.

this is like comparing error ratio between baking cookies and running a pastry shop.

if we have to believe blindly in any sort of fancy metrics (and there seems to be plenty of people in desperate need for it), we should at least restrict them on systems that are truly comparable.

Re:huh??? Wake up!!!

[Anonymous Coward]

Those things are calling .NET libraries on Windows (which is MS-flavored copy of Java -- ironic isn't it???). How cool is that COBOL code you realy wrote? How solid are those on Linux, BSD, cell phone, android phone? I doubt there is any such thing available. ["Not that I couldn't."] -- Yeah right!!!

On the server-side, how is that changing the goal post? Show me 100% native-COBOL in non-batch mode that can run as the SSH server, VNC server, VOIP server, CHAT server and show me how solid those apps run? How about UDP and TCP port services written in native COBOL? How about non-existent!!!

How about native-COBOL libraries that can run dozens other languages, something like BeanSell, Jython...

I wouldn't hold my breath 5 years, or 50 years for that. How about never???

You can't even teach those COBOL programers to understand such concepts as TCP/IP, UDP, GUI, Voice Processing, let alone write any such code libraries in native-COBOL. They buy/lease their COBOL libraries from Software vendors who wrote those in other languages. Wonderful world of COBOL -- NOT.

The internet

[phorm]

Also, the internet allows everybody to share their crap code with the world. I've seen people using online code references that showed some pretty dangerous or stupid ways of doing things.

Think about the barrier of entry

[bussdriver]

Java is closer to pseudo code and has a low barrier of entry for beginners so you can have a lot of bad programmers cheaply. Less easy languages require a higher experience or skill set which filters out or highlights the weak programmers.

Do we want things so easy that somebody who can make some HTML thinks they are a programmer?? Sure there are some benefits for ease of use but there ARE downsides as well. Java may remove the top C programming errors but it allows in a lot more bad programmers.

Were there other languages compared?

[shoor]

I didn't see anything about how other programming languages fared in the study. I also didn't see anything very detailed about their methodology. It is, of course, a very interesting question on both a purely intellectual and a practical level, and a lot of studies have been done concerning the topic.

In ancient civilizations that had complex writing systems, whenever a newer, easier to learn writing system was introduced, the old guard would resist it because then they wouldn't be able to demand high compensation for their rare, valuable skills. Programmers, in some cases, can adopt a similar attitude, and I say that as a programmer myself. I've sometimes felt a certain anxiety about programming becoming 'easy', rendering my valuable skills obsolete, while at the same time realizing that if I were a businessman having to hire programmers, that's exactly what I'd want to happen.

When trying to look at this objectively, I still think the quality of code depends significantly on what I'll call the human programmer's talent more than the actual language involved (though some languages are certainly more fun to use than others), and it'll probably be that way until the singularity happens.

Technical Debt is a shitty term

[Colin Smith]

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.

Re:Chasing rainbows & comparing apples to oran

[s73v3r]

More or less so than "Lines of Code"?

Re:C'mon, you know why don't you? Really, you don'

[Anonymous Coward]

Those 200 billion lines or so of Cobol running the world's financial systems are some screwdriver!

And what makes you think COBOL 2002 can't do anything that Java can?

Obligatory Fellows and Parberry

[colinrichardday]

http://en.wikiquote.org/wiki/Edsger_W._Dijkstra#Misattributed

Computer Science is no more about computers than astronomy is about telescopes.

Re:Chasing rainbows & comparing apples to oran

[Anonymous Coward]

COSMIC-FFP: ISO/IEC 19761:2011 Software engineering. A functional size measurement method.

        ISO/IEC 19761:2011 specifies the set of definitions, conventions and activities of the COSMIC-FFP Functional Size Measurement Method. It is applicable to software from the following functional domains: application software which is needed to support business administration; real-time software, the task of which is to keep up with or control events happening in the real world; hybrids of the above.

        ISO/IEC 19761:2011 has not been designed for measuring the functional size of a piece of software, or its parts, which: are characterized by complex mathematical algorithms or other specialized and complex rules, such as may be found in expert systems, simulation software, self-learning software and weather forecasting systems, orprocess continuous variables such as audio sounds or video images, such as may be found, for instance, in computer game software, musical instruments and the like.

        However, within the local environment of an organisation using the COSMIC-FFP Functional Size Measurement Method, it may be possible to measure these FUR in a way which is meaningful as a local standard. ISO/IEC 19761:2011 contains provision for the local customisation of the method for this purpose.
       

abstract and subjective did you even read the standard about function points before discarding them as uselessly subjective and abstract! For what that metric was designed to accomplish it is quite correct.

Flaws? Relative.

[DarthVain]

I did COBOL in university back in the day. I also did C and Pascal and VB, and a host of others (even assembly).

When I wrote in C and Pascal, the Professor cared about elegance. I recall they really seemed to dig recursive algorithms as being good (given situations).

COBOL seemed more about structure, and having things... "consistent". I recall for my final project, I thought I was being smart by doing a few recursive algorithms within the program. I actually LOST marks for doing so.

VB didn't really care so long as your widget did what it was supposed to do, and the GUI looked good.

So I think programming "Flaws" are relative to what language you are using, or at least that was how I seemed to be taught.

In addition to the aforementioned postulation that that different languages are meant to do different things, and that COBOL has had 30 years of maintenance and work to fix problems, I think it is worth mentioning that COBOL was generally done a long time ago, while Java is recent. By that I mean a lot has changed over time as to how programs are constructed, maintained, and the culture is vastly different now. I mean everything now seems to be released in Alpha, Beta, and just patched until it works properly. Back when doing that was a fairly big deal to change, you wanted to get it right the first time I would imagine, so a lot more care may have gone into the code. Projects are generally bigger now I would say as well, increasing complexity and difficulty as well. Where before you may have had a small team, now you have whole companies, many with overseas contracting etc... Also anyone can go to their local college and pick up a course in Java, where as back in the day, one likely had to have a more complete education (say in Computer Science) in order to have that training. Now in today's business, they just hire the cheapest labor, as no one really looks beyond a quarter or two these days. I would say in most cases they don't really care about getting it done proper, but rather doing it as quickly and cheaply and getting it out the door, they intend to fix all the problems later on.

Re:Flaws? Relative.

[Anonymous Coward]

I would say in most cases they don't really care about getting it done proper, but rather doing it as quickly and cheaply and getting it out the door, they intend to fix all the problems later on.

In other words, they don't really care about getting it done proper.

Only if you don't understand it

[cbcanb]

Technical debt is not about bugs, mostly.

Technical debt is about things like design quality and ease of change. High technical debt code is hard to change. That means that adding new features or fixing bugs is more expensive, takes longer, and is riskier. You pay interest on the debt every time you make a change (or don't make a change because it was too scary because your design sucked).

If you pay off your technical debt by improving the design, adding features and fixing bugs will be cheaper, faster, and less risky.

Java encourages complexity bugs

[HighOrbit]

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.

Re:Java encourages complexity bugs

[Anonymous Coward]

last time I asked about that, it appears as though the COBOL OOP extensions are actually implemented in Java (at least on the mainframe) so it rarely ever gets used as Java on the mainframe really isn't all that well developed. (NOTE: I can't verify that because the shops that I have worked in never actually bought the OOP COBOL license and I was more involved in writing apps that interfaced with the big bad back end that was the mainframe.

I am not sure it really fits the architecture of mainframe apps either as they tend to be collections of smaller programs that are linked together using JCL

Re:Java encourages complexity bugs

[BitZtream]

If you need language extensions to do OOp, you really don't get it. Language extensions make it easier, they are not required.

Re:Java encourages complexity bugs

[dkf]

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

That's actually bad practice, or at least insufficiently good practice. They should be using an XML file to control a library that instantiates and connects the classes together while pulling configuration strings from a separate file somewhere else that's been set up to handle localization (without, you know, actually supplying multiple localizations).

Such monstrosities, where you're in a maze of object-oriented complexity that tries its hardest to conceal exactly what is happening and where, I term them Ravioli Code. Maybe they're discreet parcels rather than the tangled mass of spaghetti code, but they're still pasta in sauce and they're still a mess.

Selling a PDO port to my boss

[tepples]

Does mysqli support named placeholders?

No. MySQLi supports ? only, and it requires three things to be kept in sync: the statement, the list of argument types, and the list of arguments passed by reference.

using PDO rather than mysqli

Porting an existing application from MySQLi to PDO MySQL to be able to use named placeholders might take a while, especially when the boss wants features nyaaouw. But it might be an easier sell if you can come up with a couple other advantages of PDO.

Re:Selling a PDO port to my boss

[petermgreen]

No. MySQLi supports ? only, and it requires three things to be kept in sync: the statement, the list of argument types, and the list of arguments passed by reference.

ick

Porting an existing application from MySQLi to PDO MySQL to be able to use named placeholders might take a while

Is there any reason you have to port the whole app at once? afaict there is nothing stopping you porting one transaction at a time.

But it might be an easier sell if you can come up with a couple other advantages of PDO.

The only other thing I can think of is support for multiple databases but having not used mysqli I'm not a good person to ask for a comparison.

Re:Selling a PDO port to my boss

[tepples]

Is there any reason you have to port the whole app at once? afaict there is nothing stopping you porting one transaction at a time.

For one thing, the overhead of opening two connections for each page view: one for those transactions that have been ported and one for those that haven't.

WOW! How did you get so FUCKING AWESOME?!?!?

[Anonymous Coward]

was it by using CAPITAL LETTERS? (You know, the stable ones -- see upthread.)

Btw, all the languages you named are near-identical in terms of semantics, so don't start getting any ideas in your head that you understand computer languages.

Re:WOW! How did you get so FUCKING AWESOME?!?!?

[DrGamez]

How rude AC.

PHP makes it hard to do things right

[200_success]

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.

What happens when you compile COBOL to JVM?

[Anonymous Coward]

Most modern COBOL compilers not on the mainframe compile code to the JVM. What happens when you combine COBOL and Java?

Java is good. It is just used badly.

[bytesex]

Somewhere around the same time that Java entered the market, everyone suddenly became a consultant or a manager. I'm not saying there is a causal relationship, or even a correlation. I'm saying it was a sign of the times: no more people to actually get their hands dirty. The mindset around Java suffered from this: seven hundred different 'frameworks', but no-one to actually implement - say - a PDF-generating library. Because that's menial work. We're building the future - we don't do that kind of stuff.

And so, ironically, the language that was supposed to stop people from re-inventing the wheel, made everybody re-invent the wrench.

Re:Chasing rainbows & comparing apples to oran

[sapgau]

What about lines per function point! :-P

I respectfully disagree

[rve]

I've worked in Java and COBOL shops. The average age is pretty similar: most are in their late 20s to early 40s, with only a small minority older or younger than that range. I don't know if this is because people stop working as programmers by their early 40s, or if it's just an artifact of the fact that the field has been growing so fast in the last 20 years or so, adding so many new programmers every year that the older guys remain a minority.

To me (gut feeling, not having done any research on the matter) it makes more sense that the effect in TFA has more to do with the fact that Java is used for a much wider variety of uses than COBOL, and has very sophisticated analysis tools available, which I'm sure they've used to find the violations mentioned.

Flawed

[Anonymous Coward]

Clearly the analysis ignored all Ruby code ever written. Examples:
  - Puppet
  - Mcollective

Apples and Oranges

[scottbomb]

A new programmer (who is likely using Java) isn't necessarily a BAD programmer, they're just NEW. Any skill (say, for instance, playing the guitar or playing tennis) takes a lot of practice (time) to perfect.

And let's not forget where a lot of our modern-day code written - in India. How long have Indians been programming? How long have Americans been programming? Again, it's not necessarily a bad programmer you're looking at, but an inexperienced one.

Everyone has to start somewhere. The most seasoned, grey-haired old man hacking away at assembly, C, COBAL, whatever... was once a beginner too. His code probably wasn't very good then either.

Heh.

[Anonymous Coward]

It's a good thing Android relies so heavily on Java then; it's so stable. Look at how smooth, reliable, and bug free the experience is there.

duh

[Anonymous Coward]

given that java is generally written pompus idiots... (look no further than maven or any other over-engineered POS) this does not surprise me.

Young pilots crash more than experienced ones

[Anonymous Coward]

Asinine report. The folks that program Cobol are considerably more experience (and older) than Java programmers. The "between the lines" conclusion is that less experienced programmers produce buggier code on average. Really? No Sh*t Sherlock! But a report that shows a direct relationship showing more experience translates to fewer bugs is not a headline catcher nor satisfies whoever paid for the report. Sheez.

Not enough RAM slots

[tepples]

what exactly is the problem with 16GB of RAM? it's about the same as subscribing in the apple developer program for a year

The motherboard you already own might not support that much RAM, in which case you might need to configure the build system for an overnight build instead of an immediate build.

Re:C'mon, you know why don't you? Really, you don'

[BitZtream]

C'mon guys, maybe I missed someone commenting on the extremely obvious

You didn't miss it because no one with a clue was saying it. You're just ignorant of how much of the world runs on COBOL. Whats best, is its the important shit that runs on COBOL, you know, like the worlds financial systems.

Re: Ada

[durdur]

Java in fact shares quite a few concepts with Ada. Packages, array validation, etc. Java has at least as good runtime checks as Ada. And there are Java static analysis tools.

Why there are fewer bugs

[rainbird]

Its because it takes like 300 lines of cobal to write a decent bug.

Java is the modern Cobol

[Anonymous Coward]

it already feels old and dated

What idiot wrote this code?

[Anonymous Coward]

I know what you mean! I was doing exactly that and (knowing it was my code) said out loud "What idiot wrote this code?".

Pogo had it right when he said "We have met the enemy and he is us!"

It's a shitty job at any price

[neurosine]

I've taken COBOL and RPG, but I don't believe there is enough money to intice me to program in these languages professionally. Even when my dignity and self esteem are at an ebb, some things I just refuse to do to myself.

No COBOL apps

[SpaghettiPattern]

There are no COBOL apps on my Android.

(Think for yourself what I'm implying here.)

Seriously?

[Anonymous Coward]

A smaller amount of cost per code doesn't necessarily mean anything. What we should be analyzing are the end results of the program itself, along with how long it took to write the code, how effective the code is, the versatility of the language, and the average cost of implementation and maintenance. While COBOL is designed for business mainframes, and has been around for 30-some years, it is not a viable solution to a lot of modern mainstream business needs and end-user demands.

Last time I checked, outside of the database maintenance niche, COBOL isn't really used for anything else.

code reliability and code bloat

[lsatenstein]

I started with 1401 autocoder, then to cobol, and assembler, and later, to C language. I look at object oriented programming as bloat. The same function for different objects requires a unique method per object. Something is wrong there.

Think of the human body. -- No duplication. Negative side, no redundancy but positive side, functions that are not duplicated.

A Lot of Morons

[Anonymous Coward]

There are a lot of clueless morons programming java. And between the crappy CASE tools like Oracle BPEL and all the architecture astronauts designing Rube Goldberg-esque software it's no wonder we see these kinds of statistics. Anyone ever heard of the KISS method?

30 years? More like 50...

[Anonymous Coward]

Seriously, COBOL has been around FOREVER. Shoot, the first version, Cuneiform Obelisk Building Overseer's Language, was used for generating grain silage reports during the construction of the great pyramids.

This is retarded

[luis_a_espinal]

Yup.

In my field of embedded programming a CS grad is worthless. If you dont have an EE degree you will never be able to write the code.

Bullshit. Where I work we have CS grads doing embedded work just fine. Though you are right that there are items that a CS grad should be cognizant, specially for doing work at the bare metal (like FPGA). There is a wide spectrum in the areas of embedded development. The closer you get to the metal, the more you need a EE degree (specially when you are spec'ing the hardware). From device driver level up, many competent CS grads do fine (read "competent".)

You have to understand what the voltages coming in MEAN. Understand transistors, logic devices, feedback loops, etc...

A lot of CS students (depending on the school that is) actually have a lot of CE/EE in their curriculum. Or used to... CS education has been watered down in the last 15 years.

The last CS grad we hired was completely worthless. Dude did not even know how a microprocessor worked.

And that's a reflection on him and the CS school that gave him a degree. Understanding how a microprocessor work, down to the digital level, is a must for a good CS degree. Or used to be a must.

Almost all CS grads I know or met know nothing at all about computers.

There. Fixed that for you. The sad thing is that many who have graduated with a CS degree in the last few years are just web-based programmers. That is not the same as being a Computer Scientist.

And don't be so smug with your EE degree. I work with many EE grads, and they can't code for shit. Yeah, they can make the hardware sing alright, but their code is unmaintainable, unreadable and fucking atrocious. Their cope out it is that their code is "embedded" or "optimized", but more often than not, it is anything but. A lot of the cost over runs associated with them simply come from their craptacular code bases.

Even beyond that, because they thing they can code a for loop, they thing they are the authority in matters of software. I have a EE co-worker who was stupidly lecturing me on semaphores, assuming I didn't know because I was a CS grad (all the while the retard didn't even know that the concept of a semaphore was invented by Dijkstra, a CS'tist.) That same tard was arguing with me (quite gratuitously and for no reasons at all other than to prove that Computer Science was easy) that he could write a compiler with nothing but lookup tables. Yeah, I want to see how things like dead code elimination and register allocation can be done with lookup tables.

Better, I know of a EE lead at another company that is insisting developers to use 8-bit error codes to identify unique errors, down to the actual physical line of code (as opposed to an error type code and a error string descriptor), because it is more efficient. The guy does not comprehend that potential faults in their code base can be mapped into thousands of points, so how the fuck will he map those into a 8-bit error code. He might know what a transistor is, but he for certain cannot write even semi-decent embedded code.

Stupidity and incompetence exist in both sides of the fence. It takes more than knowing about circuits, transistors and feedback loops to perform GOOD, COST-EFFECTIVE embedded programming. Anyone who thinks otherwise is full of it or is ignorant of his own ignorance.

Re: Ada

[bar-agent]

Java in fact shares quite a few concepts with Ada. Packages, array validation, etc. Java has at least as good runtime checks as Ada. And there are Java static analysis tools.

Java shares a lot of concepts with everything. Or rather, Java is kinda like English: it waylays other languages in dark allies and rifles through their pockets for loose change.

But, look, runtime checks are easy. In fact, they are axiomatically complete: if you have a problem, but you can't see it at run-time, then you don't actually have a problem. Compile-time checks are what separates the men from the boys. Or, in the case of Ada, what separates the women from the little girlie princesses who like ponies. From what I've heard, the thoroughness of Ada's compile-time checking is unequalled. "If it compiles successfully, an Ada program is bug-free."

Re: Ada

[Black Parrot]

From what I've heard, the thoroughness of Ada's compile-time checking is unequalled. "If it compiles successfully, an Ada program is bug-free."

Unfortunately, no compile-time checker can detect flaws in your logic.

Let's be a little more realistice

[LostMyBeaver]

COBOL is a far less capable language than most. In fact, COBOL was rarely the only language used to make a system because COBOL itself was practically useless. It was little more than a fixed field record store manager. RPG was used for generating reports. Screen I/O was a COBOL extension which generally consisted of designing an input UI in another language and calling functions in COBOL... although there are some direct COBOL UI toolkits, but they are barely useful for anything.

COBOL unlike SQL is not a structured query language. Typically, raw COBOL works on fixed field records connected to a fixed field ISAM. With DB2 (or other modern multiuser ISAMS), COBOL can often be mixed with SQL... giving us all the power of another bug ridden SQL implementation. If the form developer allows it, then it could in theory be used to execute SQL code through injection just as easily as in other languages.

COBOL is a crappy ass language that allows for implementing fixed field databases relatively efficiently.... but pretty much every other language is going to be flawed with regards to security in comparison as COBOL itself is pretty much incapable of handling the nasty nasties like dynamic memory allocation and such.

Let's not suggest that COBOL is more secure because of its maturity. Let's instead suggest it's more secure because it can do what it can do an pretty much nothing else.

On that note... COBOL is as secure as the terminal it is running on. But this is where maturity matters. COBOL is generally being run on a IBM mainframe virtual machine (IBM mainframes never run native code) which is still running almost the same operating system as it was in 1969 with additional features. Things like Ethernet aren't even supported by the operating system. They're handled by add-ons which map a terminal session to a telnet, 3270, 5250 or ssh session. Oh... but there was a major update in recent years which made it so most new things are running with UTF-8 instead of EBCDIC.

COBOL - Common Business Oriented Lanaguage

[stevenddeacon]

COBOL has been around for fifty years. It was originally designed as a business programming language to replace IBM's Autocoder & RPG (Report Program Generator language), System 360/Assembler Language,and FORTRAN principally for business applications. Initially designed for batch processing it was quickly adapted for Online Transaction Processing by IBM for its CICS (Customer Information Control System) OLTP environment with CICS 360/Assembler macro level API support and shortly for the more popular CICS Command-Level Programming Interface. Although less efficient than IBM Assembler Language, also known as BAL (Basic Assembly Language), it provided a very favorable medium for developing and maintaining structured programming business solutions. COBOL continued to support numerous API languages including Assembler, FORTRAN, and PL/I. PL/I had been developed to provide an engineering language to replace FORTRAN. Today COBOL is strongly supported by IBM for business application program development with support for batch processing, OLTP, interfaces to IBM IMS DBMS, DB2 RDBMS, WebSphere, Peer-to-Peer and Message Queuing applications, and GUI interfaces and integration for Oracle's Database and Tuxedo OLTP. Online program development can be done with IBM's TSO/E and ISPF environments with fully supported run-time environments. IBM also offers a GUI Application Development Framework and Oracle offers support for COBOL in their Fusion Suite and ADF development tools. IBM COBOL now supports an Object Oriented Programming methodology and interfaces to the JAVA programming language. The only knock I have ever had with COBOL is that it can become extremely verbose. With the advent of structured and function programming constructs and GUI Application Development Frameworks this problem can be minimized while still providing very easily read, maintained, and debugged business applications.

Re:COBOL - Common Business Oriented Lanaguage

[stevenddeacon]

By the way, COBOL has been supporting API interfaces with C/C++ for a couple of decades now.