Join COBOL's Next Generation

jfruh writes "COBOL, it's finally becoming clear, isn't going away any time soon; there are far too many business-criticial applications written in it that work perfectly well for that to happen. This reality could be a career boon for IT staff. Need to learn the ins and outs of COBOL? Your employer may well pay for your training. Just getting started in IT? COBOL can provide a niche that gets you a first job."

Comments

Nothing does

[geekoid]

what COBOL does as well as COBOL does it.

Re:Nothing does

[Joce640k]

Keeping them employed until retirement age.

Re:Nothing does

[julesh]

This is true. There is no other language which enables programs written in COBOL to run.

Re:Nothing does

[Half-pint HAL]

Actually, you could probably get Lua to run COBOL programs....

Re:Nothing does

[Nerdfest]

If you mean solving business-related information technology problems in a concise and maintainable way, I think you're very, very wrong. COBOL is a horrible, wordy language. If you mean wearing out developer's keyboards, you are more correct. COBOL is too verbose to be easily legible. I'm of the opinion that there is an ideal level of information density when it comes to conveying the intent of a piece of software. At one end is assembly, and at the other is COBOL. neither are good. C approaches it from one end and probably something like Python from the other. Both are for more usable, maintable, and flexible languages.

I'm of the opinion that if you enjoy writing code in COBOL you either haven't used anything else or you're a masochist.

Re:Nothing does

[Nerdfest]

I will also add that the reason it's so hard to get rid of is that most software written in COBOl tends to be a tangled mess that can't be easily split up and decoubled, replacing parts with more modern, usable languages. It tends to be an all or nothing venture. It has very little, if anything to do with it being the best language for the job.

Re:Nothing does

[gweihir]

Actually, you could probably get Lua to run COBOL programs....

Huh? How would that work? Lua is pretty cool, but this is not only about interpreting the individual instructions.

Re: Nothing does

[Anonymous Coward]

Sarcasm.

Re:Nothing does

[Anonymous Coward]

If you mean solving business-related information technology problems in a concise and maintainable way, I think you're very, very wrong. COBOL is a horrible, wordy language. If you mean wearing out developer's keyboards, you are more correct. COBOL is too verbose to be easily legible. I'm of the opinion that there is an ideal level of information density when it comes to conveying the intent of a piece of software. At one end is assembly, and at the other is COBOL. neither are good. C approaches it from one end and probably something like Python from the other. Both are for more usable, maintable, and flexible languages.

I'm of the opinion that if you enjoy writing code in COBOL you either haven't used anything else or you're a masochist.

COBOL is a domain specific language. You're a masochist and a fucking idiot if you use COBOL to design an operating system, or a control system for a nuclear plant. COBOL is designed from the start for business applications. And that's what it's good at. The syntax is what it is, but 100 times better to design business programs in COBOL than in fucking JAVA. There's a reason why languages come and go but FORTRAN and COBOL are still there. Think about it.

Re:Nothing does

[solidraven]

Being verbose is often considered bad, yet languages like VHDL and Ada do it as well. The latter two combine it with a very strict syntax. As a result Ada and VHDL code that compiles/synthesizes has a larger chance of working on the first attempt. More keystrokes isn't exactly a problem. I'm not sure about you but my typing speed isn't the limiting factor in writing programs. The days of planning, flow diagrams, etc. are.

Re:Nothing does

[Nerdfest]

COBOL was breated not to be the perfect language for business, but to be a language that was easy enough for an average 'business-person' that was not a programmer, to write programs. The end result unfortunately was that lots of average 'business-people' wrote software. In general, it ended up being a tangled mess that is still (barely) running many years later and few know how to maintain or replace it. Be careful what you wish for,

Re:Nothing does

[macraig]

It didn't have to be that way. When I was still in school a millennium ago and took my one and only COBOL course, I recall devising a pseudo-structured way of using the language that the instructor had never seen before, yet my code was no less capable than the more typical approach(es). It obviously caught him quite by surprise by his reaction, which I've never forgotten (I've forgotten every detail about my technique). Perhaps it made my code more modular and maintainable.

Re:Nothing does

[Anonymous Coward]

Programs should be readable and understandable by humans. In the end it's humans that maintain software, not the computer. Computers only have to execute code, but we, we have to read code. So a verbose language that conveys all the information explicitely is much better than C or C++ where you're almost constrained to obfuscate by default. That's the nature of those languages. So yes in an e-peen contest, C or C++ may win over COBOL; but start maintaining large software and clarity is paramount. C or C++ programmers wouldn't even recognise that word (clarity).

Re:Nothing does

[Minwee]

It has very little, if anything to do with it being the best language for the job.

That depends on what "the job" is. If the job is to implement a completely new, problem-free and infinitely maintainable system for managing financial transactions with no budget or time constraints, then the answer is "No". Actually, it's a much longer answer that starts with "HELL NO" and includes phrases like "If I ever catch", "Then I'm going to" and "With a frikkin' caber, that's what", but the general sense of it is "No".

If the job is to keep the horrific monstrosity which runs the entire bank lumbering along for another few months while still complying with the latest round of new regulations before it drives you irredeemably mad then the absolute best language for the job is COBOL, because that's what code-thulhu is already written in.

Re:Nothing does

[Nerdfest]

It may be possible, but you shouldn't have to bend or force the language to make it do the right thing. A language should make doing things the "right" way easy.

Re:Nothing does

[macraig]

Agreed, but the origins of that language predated many theories about what the right way is, and by then I suppose there was so much code in the wild that no one wanted to tackle the matter head-on?

Re:Nothing does

[icebike]

As long as YOU get to decide what is the right way, there would only be one computer language. Your pet language.

Look, its pretty clear you are totally ignorant about COBOL, and have maybe looked at a couple programs once, but your pontifications clearly indicate you haven't a single clue.

Re:Nothing does

[SerpentMage]

And of course languages like Javascript, Ruby, PHP, and so on don't make tangled messes? Lest we forget Objective C or even C++. The only languages that I would think where most people would agree to that are "clean" would be C#, Java, and Smalltalk. I don't want to get into the functional paradigm because it is not IMO a tangled mess if you understand the paradigm.

Anyhoo, if messes were the basis of whether or not to adopt programming languages we would not be writing any programs. Ever try to figure out WTF a Java Spring or Java EE app is? Its a bleeding mess!

The thing is that Cobol applications work! Yes they work, and they perform oodles of calculations without having to do anything major. Let's not forget that at the end of the day most things don't change that much. Thus why rewrite? And the answer, "oh but this is a new shiny toy" does not count.

Re:Nothing does

[mwvdlee]

It sure does!

On the other hand, I got out of COBOL programming after some ~12 years because the only thing COBOL does well is what COBOL has done thousands of times before.

It's a boring platform to develop for; very few interresting (from a technical perspective) projects ever come along.
Safe and secure life as a developer; yes. Actually enjoying your safety and security; no.

Re:Nothing does

[Darinbob]

It keeps the makers of CapsLock keys in business.

Re:Nothing does

[AlphaFreak]

Record (file) handling. To process a record-composed file in C you have to write a lot of boilerplate code (just parsing the records into its components and re-creating the records by parts) requires probably to write a specific function to do that. In COBOL you just declare the structure mapping the physical record and you are done.

By the way, the languge has all the control structures needed to write decent code since COBOL-81. Before that (COBOL-74) it was a really ugly mess, but the modern COBOL (yes, it has been updated a lot of times) allows to write clean and understandadble code.

Re:Nothing does

[azadrozny]

You are spot on. If the creators of the Internet knew what it would grow into, they would have designed it differently. Consider the debates and frustration surrounding HTML5 or IPv6. Sometimes you have to declare you have done your best and release it, and then adapt as you learn.

Re:Nothing does

[Waffle Iron]

but start maintaining large software and clarity is paramount.

Mathematicians have spent many centuries refining how best to expresses mathematical operations with clarity -- And they sure as hell didn't pick spelled out English verbs in all caps.

That's not clarity; instead, it looks like that obfuscated legalese from an EULA text box.

Re:Nothing does

[RabidReindeer]

Yes, COBOL is wordy, but for the most part you can accomplish the same thing in the same number of lines. Unless of course you write C or C++ where you are packing as much as you can into a line. Yes, I wish I could do "running_total =+ current_val" instead of "compute running-total = running-total + current-val", or do "last_val = current_val" instead of "move current-val to last-val". My real issue being 'verbose' is when it causes extra lines, which makes logic harder to follow.

ADD CURRENT_VAL TO RUNNING_TOTAL.

Which doesn't excuse 1001 other ways of inducing COBOL inflicted carpal-tunnel syndrome, but at least there's that.

Although one of the most horrible programs I ever saw included a 3-page "IF" statement. Since the "ENDIF" for the original COBOL is a miniscule dot, that's just a disaster looking for ways to happen.

Re:Nothing does

[Darinbob]

COBOL has some features rarely seen elsewhere, except in libraries. A wide variety of data types including built-in fix point and decimal for example. It is also relatively simple, there's no way to do fancy tricks with it like with C, you won't have complex data structures, what you see is what you get and that helps maintenance. Now maybe there are better business oriented languages but they just aren't that popular or portable.

Of course it has bad stuff too. Like Fortran it only added structured programming constructs late in the game, and both languages are often used with on "dusty deck" programs that were written decades ago or by people who didn't use structured consructs. So most COBOL users are going to run into spaghetti code and have to deal with it.

Re:Nothing does

[Anonymous Coward]

So... you're saying that COBOL has already been replaced by VBA?

Re:Nothing does

[Darinbob]

You don't have to do this. There are modern structured constructs in COBOL. The problem though is that if the program you are working with wasn't written using them then you have to deal with the mess. And there are a lot of COBOL programs written using GOTOs and the like.

These problems exist in every language, but they tend to be more common in COBOL and Fortran because those are some of the oldest languages around. Thus you have to deal with decades old code that still has to work; plus the programmers learned by example from the boss, who learned by example from the boss, who learned by example...

Re:Nothing does

[Darinbob]

Ya, but try to find a PL/I compiler that runs on a wide variety of machines and operating systems, or a significant number of PL/I programmers.

Re:Nothing does

[blippo]

Hi AC.

I think you have confused the term "domain specific language" with something else. And besides, what's generally considered as a nice language is that it's easy to extend it (using the language itself) so that you can USE it as a DSL. Not so much for COBOL.

Today, it would probably make more sense to use a modern lisp dialect to write business applications, at least from the DSL point of view, and
its an even older language.

Whats keeping Fuckin' COBOL alive is the fact that it's running in a well defined virtual machine, and in a well defined OS on quite solid hardware.

Fucking Java is the *new* Fucking COBOL, for the fact that it's running in a well defined virtual machine, and in a well defined environment.

If you find a 10 year old COBOL program, Java program, and a C++ program, you will be able to compile and run the COBOL and Java program
more or less on the first try, but the c++ will take a rather long time to get in shape since the toolchain and every single library and include file is changed
since it last worked...

Another reason is that hey both seems to attract the different kind of-, but still fucking useless- programmers.

I think Djikstra nailed main problem with COBOL in 1975;

-- The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense.

The best counter argument is something like this:

--COBOL programs with convoluted control flow indeed tend to 'cripple the mind, but meh...

Re:Nothing does

[Jane Q. Public]

I imagine it's also possible for an artist to make a living doing cave paintings. That doesn't mean I'd want to do it.

I have a huge amount of respect for Grace Murray Hopper. But technology changes.

Re:Nothing does

[Hognoxious]

It may be possible

It isn't, unless by "a millennium" he means what the rest of us call a week.

You couldn't do anything remotely clever with the wanky old version I had the pleasure to work with in the '90s (which, according to its (c) message, was older than I was).

Re:Nothing does

[jbolden]

Verbosity isn't better for humans. Humans can only retain and manipulate fairly short lists which means the number of things in any block of information has to be small. The more things the more levels need to be in the hierarchy.

Look at human languages. The density of Perl came from just starting to import even some of the density features of human language into computer languages. So no. If computer languages were more like human like them to be they would:

a) Take much longer to learn
b) Have tremendous amounts of implicit syntax
c) Be a total bear to write a compiler for.

Re:Nothing does

[jbolden]

A wide variety of data types including built-in fix point and decimal for example.

Structurally that's an integer datatype with a show routine that includes a decimal. Modern languages don't confuse how data is displayed with how it is computed.

Re:Nothing does

[tripleevenfall]

Sure, and like the article says, learning COBOL might get you a first job. But someone hiring for a Java position might be as likely to take a new college grad who has education in Java over an experienced COBOL programmer, since the worlds are quite different.

I think the logic holds up as long as COBOL holds up, and as long as you continue to educate yourself and keep yourself relevant.

Re:Nothing does

[sensei moreh]

plus the programmers learned by example from the boss, who learned by example from the boss, who learned by example...

This does not go on ad-infinitum. COBOL is younger than I am. Now, get off my lawn!

Re:Nothing does

[tripleevenfall]

You're about to find out. 2014 is going to be the Year Of COBOL On The Desktop.

Re:Nothing does

[dargaud]

Ada is wordy, but for the few months I tackled it I found it powerful, intuitive and very readable. I looked at Cobol source code for sheer kicks and got cold sweat worse than any horror film or girlfriend saying "I'm late".

Re:Nothing does

[lgw]

You can also do perfectly structured programming using GOTO instead of for and while loops - because for and while loops are effectively just macros around GOTO.

I did assembly programming for 5 years, and the programs I wrote were arguably more clearly structured than what I've written since, as without the language helping you it paid to be obsessive about it.

Re: Nothing does

[Nerdfest]

Come on, how are they going to create the next Y2K fiasco with that kind of thinking.

Re:Nothing does

[lgw]

Nah, you can do it just as trivially in C, just make a struct mapping the physical record just as in COBOL. People often don't do that, but that's people for you.

Re:Nothing does

[Nerdfest]

I've worked with everything from machine language and microcode to Ruby. My dislike for COBOL comes from working with COBOL.

Re:Nothing does

[Gr8Apes]

and yet the only way I'd touch anything that even hinted of COBOL is to migrate it to any modern language. Even Perl is more maintainable than the general COBOL program. (OK, maybe not, but at least it'd be more concise)

Re:Nothing does

[Nerdfest]

Yes, but like a few other languages, COBOL makes writing bad code easy. A good language should make writing *clean* code easy.

Re: Nothing does

[jbolden]

Y2K was because of an integer datatype with 2 digits and inconsistent treatment for the first digit being something other than 5-9, there they really did run out of room.

The next Y2K fiasco is going to be 32 bit timestamps in C...

Re:Nothing does

[cold fjord]

Keeping them employed until retirement age.

I seem to recall they had plenty of offers after retirement for Y2K as well. With many schools and people losing interest in Cobol, that may not change.

Re:Nothing does

[stymy]

Mathematicians have spent many centuries refining how best to expresses mathematical operations with clarity by hand.

FTFY. Spend all day typing up proofs on LaTeX and then tell me that's the optimal notational system (I know other systems for typing math exist, but they all take a while).

Re:Nothing does

[Mitchell314]

Language doesn't make the programmer.

Re:Nothing does

[LifesABeach]

Admiral Grace was very aware of the current available technologies, and their direction. I think that if you had ever talked with Admiral Grace, you would have found her insight to be very compelling; but I speak from personal experience.

Re:Nothing does

[bws111]

No, it isn't. Your ignorance is showing. Decimal types mean you have decimal data. So you can have two records with EBCDIC/ASCII decimal fields in them, read those records in (without doing ANY parsing or translation of the records, add two fields together and write the results. Excluding the actual IO operation, that can be done in only 7 instructions (PACK, OI (to set the sign) for both operands, ADD PACKED, UNPACK, OI). Note that the compiler is using DECIMAL instructions to do that.

Which of your 'modern languages' can do that more efficiently?

Re:Nothing does

[Capt.Albatross]

Most software written in COBOl tends to be a tangled mess that can't be easily split up and decoubled.

More modern languages have done little, if anything, to reduce a programmer's ability to create a confused mess. Goto may be gone, but inheritance has tremendous power for cryptic obfuscation, and I have seen way too many cases where a programmer has used this capability to the hilt. Perhaps most frustrating are the cases where a rewrite has ended up no better than the original.

Re:Nothing does

[bws111]

People don't do that because it is stupid. C makes NO GUARANTEES about the layout of structures. If you only have one compiler, and are not sharing your data with any other system you might get away with it.

Re:Nothing does

[Nerdfest]

The really funny thing about this is that one of Grace Hopper's famous quotes is "The most damaging phrase in the language is: We've always done it this way", the mantra of many COBOL shops.

Re: Nothing does

[Nerdfest]

It's not integer, but characters. A 2 byte int would have let them avoid problems for another 60K years or so.

Re:Nothing does

[HornWumpus]

Seconded. I'm embarrassed to admit I once wrote COBOL. The language sucks big wet donkey balls.

I also replaced entire COBOL systems with god damn Dataflex back in the late 80s. Dataflex was like a COBOL programmer got drunk with a GWbasic programmer. Dataflex was the hangover. Damn fast DB engine though. Anything is better then COBOL.

Re:Nothing does

[cold fjord]

Mathematicians have spent many centuries refining how best to expresses mathematical operations with clarity -- And they sure as hell didn't pick spelled out English verbs in all caps.

Papers and articles on mathematics tend to have lots of words and some symbols. If all that is needed for understanding is symbols, why include the words?

Re:Nothing does

[jbolden]

That's not a problem.

First off of course you are parsing it is just a built in decimal parser. CPU's don't do decimal math they do integer math so it has to be converted you are just doing it implicitly.

For example to read you (and really this is the library) write 1 time something like
fun read2Digit (x) {
    x =~ /(D*)\.?(D*)/
    if $2 return $1 * 100 + $2
        else return $1;
}

then you define that as the 2Digit's base reading type. So that when
X 2Digit;
X = read...

X will default to the read2Digit routine.
similarly with output. And yes there are plenty of libraries that do this google "fixed precision math".

Re:Nothing does

[HornWumpus]

Never take advice from anybody who uses the word 'performant'. They are idiots trying _way_ too hard to sound smart.

'Fast' is the word you are looking for. You're not getting paid by the letter.

Also note: AC doesn't understand why floats exist and that they are just as reasonable a default as BCD types.

Re: Nothing does

[jbolden]

No if it was character data then the rollovers wouldn't have worked right. 1959 + 1 = 195(3*) where 3* is a superscripted 3 (remember this is EBCDIC so different stuff than in ASCII). It was numerical data. 0-99 is packed data on disk (generally 7 bits).

Re:Nothing does

[Crudely_Indecent]

The article was especially interesting to me, as it follows a conversation I had nearly 15 years ago after having learned COBOL II in college and couldn't even find a company who was willing to interview me - the reason given, we want 10 years of COBOL experience. How do you get 10 years of experience coming out of school when nobody will hire you because you don't have 10 years of experience?

That conversation was with a person who was a CICS administrator, and her take was that eventually the jobs would need to be filled by new blood as the old blood retired. Neither of us thought it would take 15 years, and I wasn't interested in waiting - so I moved on. Considering COBOL as a starter language, it was easier to learn other languages. I only had a few opportunities to use COBOL in the past 15 years, but COBOL isn't the sort of language that you forget.

With so many people out of work, and others struggling - I'd welcome some boring security over the mad dash that is consulting. Seldom does a paying job ever interest me as much as my personal projects.

Re:Nothing does

[HornWumpus]

Mod AC insightful.

Re:Nothing does

[Waffle Iron]

Those words are free-form natural language, which computers currently can't understand. So they would be useless. Computer programs at present do not contain free-form prose.

What COBOL does is nothing more than a mechanical replacement of the formal symbols you'd find in a math paper with capitalized English words. While a few people may feel that's somehow letting people program with a natural language, it's simply not true. It doesn't change the situation one bit as far as the computers are concerned because it's logically equivalent to conventional math symbols, but just with harder to read lexical tokens.

Re:Nothing does

[KingMotley]

Thirded. COBOL is probably the worst language ever.

Re:Nothing does

[tibit]

Yeah, because most of COBOL's syntactic sugar and library functionality couldn't be replicated, say, in C++. LOL.

Re: Nothing does

[HornWumpus]

2 digits for year in 1950-1960 was the right choice.

Present value the extra 2 bytes back then vs all the resources spent fixing it in 2000.

Even there, you should allocate much of the y2k fix costs to delaying the fix until it was a 'crisis'.

Re:Nothing does

[Waffle Iron]

So to save a little typing to format a 1-inch formula, you'd rather make your readers decipher things like:

VOLUME IS EQUAL TO THE INTEGRAL OF PI MULTIPLIED BY RADIUS SQUARED DIVIDED BY HEIGHT SQUARED MULTIPLIED BY X SQUARED MULTIPLIED BY DX ON X FROM 0 TO HEIGHT

(Filter error: Don't use so many caps. It's like YELLING)

Re:Nothing does

[HornWumpus]

Look up BCD. Binary coded decimal.

What uses 'ASCII decimal'?

Re:Nothing does

[bws111]

Most cobol programs are running on mainframes, and mainframe cpus do, in fact, do decimal math. And when I said efficient I meant run time efficiency. Your example, especially if it is in a library, is not efficient.

Re:Nothing does

[bws111]

BCD is packed decimal. The number 12 would be stored in 1 byte as '12'x. ASCII decimal would represent 12 as '3031'x. The purpose of the pack and unpack instructions are to convert between those formats. As to what uses it, minor things like keyboards, displays, printers, etc.

Re: Nothing does

[bws111]

It was character data. The compiler first packs the data to bcd, then uses decimal operations, then unpacks the result. Three instructions. Rollovers work just fine.

Re:Nothing does

[Greyfox]

I can add one to things better in pretty much any other language. :-P

Re:Nothing does

[gargleblast]

More modern languages have done little, if anything, to reduce a programmer's ability to create a confused mess. Goto may be gone ...

Goto is still with us. One "feature" I have never seen implemented in anything except COBOL is the ability, when calling a subroutine, to specify the start point and the exit point of the subroutine.

Re:Nothing does

[jbolden]

I'd like to see any disk what-so-ever that can read fast enough that a CPU can't do a translation like that faster than the system can read from disk. I've never seen any mention of this in things like the Hitachi emulators. So where are you getting this notion of CPUs doing decimal math and what's the point?

Re: Nothing does

[jbolden]

Compilers don't pick data.

In any case whatever is doing decimal operations can't be doing it on character data. If you mean that the data on disk is character data, that depends on the COBOL dictionary and the CPU. I've worked with uncompressing mainframe record data without using the OS conversion and the datatypes vary. Programmers on the system don't tend to notice this because the COBOL dictionaries take care of this for them. But if you pull it off as pure binary you get the underlying structures.

Re:Nothing does

[EETech1]

So true.

Once you write some assembler libraries, or better yet a few complete applications in assembler you realize what the processor is actually doing, and write better programs as a result.

Once you realize that goto is all you got, and learn to use it properly, there are so many ways it can make you a better programmer.

Cheers!

Re:Nothing does

[RightwingNutjob]

The determined Real Programmer can write FORTRAN programs in any language. The determined idiot can make unmaintainable spaghetti in any language. If people can make maintainable assembly code (and for embedded applications, good embedded programmers *do* write maintainable assembly), then a good COBOL programmer can write maintainable and comprehensible COBOL programs. Things like variable naming and jump/goto/label naming discipline are a pain in the ass when you've grown up with C and Java-style scoping rules and curly braces that let you be sloppy with zero cost to legibility or maintainability, but they can be the difference between something that's usable as and something that forces a rewrite each time.

Re:Nothing does

[HiThere]

I don't know about Javascript and PHP, but Ruby doesn't require that the code not be clean. Neither does Objective C. And C++ is generally not too bad, until you start using STL. (C++ templates would give me nightmares, except that I switched to more civilized languages. Like Python and D (dmd).

That said, I'd really like to use Smalltalk, but it's too slow, and doesn't work well on a multi-processor system. (Yeah, that's implementation rather than basic language. And much the same criticisms can be leveled at Python and Ruby, but they don't try to insist that you do everything in one language.)

What would be really interesting is a multi-processor version of Vala that was decently documented, but it looks as if it's never going to get as far as a beta release. (Well, it's been 3 months since I last looked, but I've been looking periodically for years.)

Re:Nothing does

[HiThere]

Verbosity *IS* a problem, though not as bad as sometimes painted. Automatic documentation generation can get around a lot of it, but the documentation itself need to either be compace, or at least have a compact mode, where you can see all the methods in a class on one screen...preferably with brief notes about what they do.

Ada partially solves this with their header files (which are much more readable and useful than C's). But it doesn't handle the documentation problem at all well. (I don't like Doxygen, because it spreads simple things over multiple pages, which defeats half the purpose.) Javadoc works well with some IDEs, because they let you readily access the documentation while you're programming something else. Perhaps there's something similar for Ada that I don't know about.

Verbose code does NOT have a better chance of working better on the first attempt...except sometimes. Being a bit dyslexic I find that my usual problem is getting a logical comparison backwards. Fortunately, verbose unit testing can resolve this. Unfortunately, half the time it turns out that the backwards logic test was in my debugging code. Still, if the errors are caught during testing it's much better than only catching them much later. So my debug tests tend to be quite verbose. Which means I want a language that supports that. (For that, among many other reasons, I currently prefer Digital Mars D [dmd].) But there are other languages that come close, sometimes for other reasons, like having a better supported set of libraries. Python is another language I like, for other reasons. And if Vala would ever get production ready I'd be quite interested in it. (Note that all these languages have decent support for unicode, also. Which is the main reason *I* prefer Python3 over Python2. [Python2 can handle unicode, but it's a bit clumsy, and you had really better not mix the dialects.])

Re: Nothing does

[bws111]

I didn't say it picked the data, I said it packed the data. As in, it generates the PACK instruction to convert CHARACTER DATA into packed BCD, then performs whatever DECIMAL operations are required, then generates the UNPK instruction to store the result as character data.

The fact that you don't know even that basic stuff means you probably shouldn't be commenting.

Re:Nothing does

[bws111]

There is this fancy new thing you may not have heard of called multitasking. With this amazing new technique the cpu can be working on a different task when your task doesn't have anything to do. Do you really think that in this day and age an entire system is going to be nothing other than read from disk, process, write to disk? Yes, efficiency matters.

As for where I get the idea that cpus can do decimal arithematic, there are documents published by the cpu manufacturers. IBM calls theirs the Principles of Operation, Intel calls theirs Software Developer Manual. In these documents you will find the definition of the decimal instructions.

Re:Nothing does

[omfgnosis]

It can have a high rate of coincidence though. Not even because of language quality, so much as language popularity. I've said this before in defense of JavaScript, but most programmers aren't particularly good. Find the place where most programmers are, and you'll surely find poor programmers. That goes for Java and PHP and probably Python as well.

Re:Nothing does

[murdocj]

That's a bold statement, there are some pretty bad languages out there. Perl comes to mind as a "write-only" language.

Re:Nothing does

[jbolden]

Read more carefully. Each byte contains more than one digit. It isn't character data. http://en.wikipedia.org/wiki/Binary-coded_decimal#Packed_BCD

Re:Nothing does

[jbolden]

Do you really think that in this day and age an entire system is going to be nothing other than read from disk, process, write to disk? Yes, efficiency matters.

No efficiency on that level doesn't matter at all. Efficiency matters where CPUs can do something useful. A decimal conversion takes a few hundreds millionths of a second.

As for where I get the idea that cpus can do decimal arithematic, there are documents published by the cpu manufacturers. IBM calls theirs the Principles of Operation, Intel calls theirs Software Developer Manual. In these documents you will find the definition of the decimal instructions.

You are now claiming Intel does it to? You aren't reading whatever you are looking at carefully.

Re: Nothing does

[jbolden]

BCD isn't character data: http://en.wikipedia.org/wiki/Binary-coded_decimal#Packed_BCD

If you don't know basic stuff about how your system works maybe you should stick to COBOL.

Re:Nothing does

[davester666]

on the desktop? It'll be the year of COBOL for Mobile! Run your infrastructure directly on the phones your employee's bring to the office.

Re:Nothing does

[Samantha Wright]

Ten bucks says there's an x86 instruction for it.

Re:Nothing does

[Samantha Wright]

...I was joking, but it's called AAA. bws111 is a bit wrong (I think?); unpacked BCD still uses 0x00 to represent 0, not 0x30. You have to do an extra operation to go between ASCII and unpacked BCD.

Re:Nothing does

[serviscope_minor]

Well, I for one wouldn't bet against you on that...

http://en.wikipedia.org/wiki/Intel_BCD_opcode ... with good reason it turns out.

Apparentlt there's now an IEEE fp standard for decimal floating point and the IBM processors can do it. I guess it makes sense if most of your time is reading/writing plain text decimal formatted floating point numbers, and only a little bit of time doing anything with them.

Re:Nothing does

[Samantha Wright]

No, no, not BCD, ASCII decimal. BCD's been ubiquitous in instruction sets since the early sixties, I'm pretty sure. The imagined horror is doing all that math with 0x30 ORed onto everything.

Re:Nothing does

[Half-pint HAL]

on the desktop? It'll be the year of COBOL for Mobile! Run your infrastructure directly on the phones your employee's bring to the office.

Many a true word spoken in jest...

Re:Nothing does

[Xest]

"Ever try to figure out WTF a Java Spring or Java EE app is? Its a bleeding mess!"

They're not a mess, they just just push a higher level of abstraction than junior developers and the like can cope with which enhances their modularity and testability leading to more maintainable better software but the price of that is the learning curve and when you're on the lower end of that curve yes, you can do far more harm than good with it.

It's not inherently bad, no more a mess than the theory of relativity is compared to Newtonian physics, sure the former is harder to understand and much more complex, but it also works properly as you tend towards c and just as Newtonian physics is fine for most people's needs it doesn't fill the needs of high end expert physicists to solve the problems they encounter.

Re:Nothing does

[serviscope_minor]

Oh ASCII decimal? Yuck, I misread. Not sure I've heard of a system to do that.

I think the horror would actually not be all that bad compared to other things, since the bits in 0x30 wouldn't intfere with the lower order bits. It'd be like BCD but not nybble packed, so it might well share much of the same hardware. i.e: and with 1111, BCD add, check bit 4 for carry. In fact the implementation would be almost identical to multi-word addition but with 3 extra instructions, one to AND out the high bits, one to move bit 4 to C flag and one to OR back in 0x30.

Actually, you could probably skip the ANDing with some care.

I'm now speculating on how to implement such an awful scheme in ASM. This is why I love slashdot.

Re:Nothing does

[solidraven]

Heh, that's what you'd think right? Verbose code makes you start using indentation in very specific ways I've noticed. In fact, it's funny to see how almost everybody indents verbose code in the same structure. Enhances readability a lot. And I've seen auto doc implementations for these languages, but most sort of fail; The problem being that languages like Ada and VHDL operate in a very niche branch of coding. Especially VHDL is tricky in that aspect because even the order of things implies very different hardware structures in certain cases. What'd be far more useful is automatic test bench generation. Documenting these type of languages is sort of implied, you can't start designing in either without being very well aware about your goal and how you're going to get there. Just slapping parts together will lead to the compiler/synthesizer coming back around and hitting you in the head with your sloppy code.

I've seen a few attempts at it, none successful mind you. It'd be an interesting goal, though personally I don't think it's strictly necessary considering the way Ada encourages you to work. (Think first, write, verify instead of just starting and seeing where you end)

Ada actually does support unit tests (GNATtest is great). VHDL is indeed far more problematic, then again I don't think a computer would be very good at generating a test bench for VHDL because it's hard to predict what's to be expected. And generating input for a FSM with thousands or millions of states is a hopeless goal. But yeah, it's mainly a personal choice. Must admit I'm more of an electronics guy so I have a tendency towards these languages as they give me fine control over the things I care about (how multitasking happens, what data goes where under which format, does it arrive in the same shape, etc.).

Re:Nothing does

[s1lverl0rd]

Oh, a bit like comefrom in Intercal?

Re:Nothing does

[jbolden]

Wow. You should get an account. That's insane. Good fine anonymous.

As for the 286... OS/2 was written for the 286.

Re: Nothing does

[bws111]

Are you illiterate? First, you confused 'pack' with 'pick'. Then, you conveniently skipped the explanation of what PACK does, which is convert CHARACTER DATA TO BCD. Nowhere did I say BCD was character data.

Re:Nothing does

[bws111]

I guess in your careful reading you missed the definition of zoned decimal, where each byte contains ONE digit and a zone. When a zone and digit are in a byte like that we call it a character. And guess what the PACK and UNPK instructions do? Convert between zoned and packed! Amazing!

Re: Nothing does

[jbolden]

. Nowhere did I say BCD was character data.

"It was character data. The compiler first packs the data to bcd, then uses decimal operations, then unpacks the result. Three instructions. Rollovers work just fine." http://slashdot.org/comments.pl?sid=3903963&cid=44106705

Re: Nothing does

[bws111]

What is that quote supposed to show, other than the fact that you can't read? That quote CLEARLY says that there is an operation to convert FROM character data TO BCD. Therefore, I certainly did NOT claim that character data IS BCD, only that it can be converted TO BCD in a single operation, which it can.

Re:Nothing does

[Anonymous Coward]

*EVERY* language makes writing bad code easy. Bad code is a function of the programmer, not the language.

Re:Nothing does

[lsatenstein]

what COBOL does as well as COBOL does it.

I am an old fart. I started with cobol in the 60's, and it was a favourite. I could do perform paragraphs as good as the next guy, and I knew my go-tos and computed go-tos.
I am more than picture 66 clauses.

Re:Nothing does

[TheLoneGundam]

COBOL, which is compiled, doesn't need another language to run. It does, in many implementations, require a run-time library to supply common functions which are called by the compiled code - for example, the DISPLAY verb may be implemented as a common subroutine. On IBM mainframes, the run-time library support for many languages is provided by the Language Environment product.

Re:Nothing does

[lgw]

If you only write for one platform, every modern C compiler will give you exactly what you expect on that platform.

Remember, we're comparing with COBOL here.

Re:Nothing does

[blippo]

In computing, every minor thing can fuck up everything, but there is "not easy" and "totally and utterly fucked up".

Getting old java programs to run is in the "not easy" category...

Re:Nothing does

[Meski]

Can you still learn COBOL? Or will the generations that know it now be the last? GOBACK repeat question for FORTRAN

Re:Nothing does

[blippo]

Huh? What are you talking about? Jar-files without version numbers in their file names? Maven? IBM including old versions of your favorite tool in their own servers and then implementing randomly behaving class loaders from hell in each release? You had to rename a few variables that happened to be called "enum" ?

  The java api is stable and in almost every sense backwards compatible though. And so is the abi.

So still, moving old java programs to new servers is a walk in the park, compared to some unix related "migrations" i've been unfortunate to deal with.
Yes you need to test, but you don't have to code and code for days and weeks.

Re:Nothing does

[lokedhs]

Pretty much, although it's probably even more accurate so say it's been replaced by Excel.

COBOL Lives!

[LeepII]

I took COBOL in the 80's, my instructor was one of the guys that MADE COBOL. He said even back then, COBOL will not be going anywhere for decades. Man did he call it.

A complicated answer to a simple problem

[Sparticus789]

The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence. -- Dijkstra

So I say any company that wants to send their employees to a COBOL class should be sent to jail for torture and reckless endangerment.

Re:A complicated answer to a simple problem

[Minwee]

The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence. -- Dijkstra

So I say any company that wants to send their employees to a COBOL class should be sent to jail for torture and reckless endangerment.

By that logic, as a result of off-shoring initiatives, several major US corporations have technically declared war on the nation of India.

Java = the next COBOL

[Anonymous Coward]

If you already know Java, you don't need it. There is so much enterprise Java code out there that there will be work for Java coders for at least the next 50 years.

Re:Java = the next COBOL

[gweihir]

And in how far is Java any less messed up than Cobol is? Java, as used by enterprises today, is an abomination.

Re:Java = the next COBOL

[AlphaFreak]

IDE? Who needs an IDE? :) A text editor is enough!

Re:Java = the next COBOL

[Crudely_Indecent]

The joke doesn't work if you play both parts. Expect that someone here (especially here) will catch your reference and carry you to the punchline.

Re:Java = the next COBOL

[gweihir]

Oh, to have such a simple model of the world! Wrong on all counts. Although I am not just a programmer and I have done real work with more languages most programmers ever touch.

Re:Java = the next COBOL

[gweihir]

I have met a number of deeply unhappy Java developers. Their problem was that what they were working on actually needed to be really reliable and fast.

I agree that their are likely far more happy Java developers around than Cobol developers. The reason seems to be simple: With Cobol, only people that are a)smart enough to actually write good code are left and b) they made some mistake and are now stuck with Cobol and they know it. With Java, there are a lot of happy idiots that have not yet realized that they will never amount to anything.

As to the tool-support, as soon as you write real software, things like IDEs become pretty meaningless. Sure, when writing mindless glue-code, IDEs do help, but who in their right mind would want to do that for a living? That is one reason Java is an abomination: The language is so overloaded with syntactic clutter and so badly structured that it becomes difficult doing anything without a good IDE. But that is a problem of Java that most other languages do not have.

Re:Java = the next COBOL

[gweihir]

Except for Python, your selection is terrible and Java is indeed less-bad than they are. (Yes, C++ is a terrible, terrible language...) Python has the problem that it is a very advanced tool requiring significant skill for larger projects. It is however vastly better than Java once you have those skills. In fact, Java is pretty much stone-age and extremely tedious in comparison. (Caveat: Yes, I am using Python 3 with some core classes in C for a larger project of significant complexity and it is by choice. Have not regretted it one bit so far.)

Works perfectly well?

[TsuruchiBrian]

"COBOL, it's finally becoming clear, isn't going away any time soon; there are far too many business-criticial applications written in it that work perfectly well for that to happen.

Well I guess we can finally fire all the COBOL programmers. Their job is now completed.

Re:Works perfectly well?

[UnknowingFool]

That is until the hardware dies and business decides to move COBOL to new hardware rather than develop in a newer language.

Re:Works perfectly well?

[TsuruchiBrian]

They can simply compile all the COBOL code to the new platform. Since the COBOL applications in question work perfectly well, I assume they are written in a way that is platform independent.

Re:Works perfectly well?

[Darinbob]

But then you need to get rid of all politicians, federal, state, county, and city. Because those guys tend to change the rules all the time so that the code needs to be continually maintained. Maybe fire the bosses also, because they keep changing rules or wanting the program to do something new.

Re:Works perfectly well?

[UnknowingFool]

Most likely there won't be any major development, but you still need a developer to do it.

Re:Works perfectly well?

[jbolden]

Since the COBOL applications in question work perfectly well, I assume they are written in a way that is platform independent.

How are those two concepts even connected? That's like saying Since the COBOL applications in question work perfectly well, I assume they are written using lots of variable names with "blue" in them.

Re:Works perfectly well?

[TsuruchiBrian]

If variables with the word "blue" in them were more "perfect" I would agree with that. But since platform independence is a desirable trait and variables with the world blue in them is not, I don't see the point of this comparison.

Re:Works perfectly well?

[jbolden]

This isn't Aquinas arguments for God. Working reliable in runtime on a particular machine is not tied to being "more perfect".

Re:Works perfectly well?

[TsuruchiBrian]

Well let me phrase it a different way then. A COBOL app may work perfectly on particular hardware. If it turns out that this hardware is reaching end of life and it also turns out that it requires a great deal of effort to port this COBOL app to be compatible with newer hardware due to limitations of the initial design or limitations of the development environment, then I would say that this is a serious deficiency compared with modern alternatives.

I know all about this. I work at a company that is running an app on vxWorks (an old version) on PPC604 processors. We are already stuck porting software written in C to a new platform (linux x86) and it's already a giant pain. I can only imagine how much harder it would be if it were also written in an ancient language like COBOL.

At some point it makes sense to just bit the bullet and do a rewrite. Yes maintaining something can be cheaper than rewriting it, but you reach a point when you are spending more effort and money every year keeping obsolete hardware and software alive than it would cost to rewrite it.

This.

[mfwitten]

This is why we can't have nice things.

The reason it is still used is simple.

[mindmaster064]

COBOL is one of the few languages that is completely standardized. IO, formatting, everything works the same EVERYWHERE. Certainly, the column nature of coding in the language is annoying, but not much more than BASIC was with it's numbering scheme. As far as the programs that chug through industrial-sized databases go few touch as many records as COBOL does.

Re:The reason it is still used is simple.

[Sponge Bath]

...annoying, but not much more than BASIC

I'm sold!

Re:The reason it is still used is simple.

[T.E.D.]

COBOL is one of the few languages that is completely standardized. IO, formatting, everything works the same EVERYWHERE. Certainly, the column nature of coding in the language is annoying, but not much more than BASIC was with it's numbering scheme. As far as the programs that chug through industrial-sized databases go few touch as many records as COBOL does.

This comment was found in a time-capsule we buried 35 years ago in 1978, along with a six-pack of Shlitz.

Sad to say, the beer had gone kinda skunky, but I think the comment is still good, isn't it?

Re:The reason it is still used is simple.

[AlphaFreak]

Procedural languages are OK for > 90% of needs. You don't really need an OO language nor a fancy framework to read a sequential file and summarize its records to generate a payroll... Oh, and the fixed-column format is optional in the modern COBOL compilers.

Re:The reason it is still used is simple.

[CaseCrash]

COBOL is one of the few languages that is completely standardized. IO, formatting, everything works the same EVERYWHERE.

Hahahahaha!!!! No way. I work in a COBOL conversion shop (simple explanation, anyways) and I've worked with COBOL on several types of machines, and not even all the A series machines act the same with the same code. You would not believe the crazy, undocumented crap that programmers use to make their programs work.

Sure, the basic "COBOL" language is mostly standardized (once you pick your variant) but real life implementations are not coded that way and everyone manages to find the little things that make their stack unique.

Re:The reason it is still used is simple.

[jbolden]

Huh? Data structures differ completely from system to system. Dictionaries are non standard. Calling mechanisms are non standard. Compilation procedures are non standard. Dependencies are non standard.

Take I/O printing are you outputting:
record structures to a print system (of which there are many)
EBCDIC formatted
column 1
ASCII formatted
EPSON
record structures for metacode
record structures for AFP ....?

No it is not standard.

Re:The reason it is still used is simple.

[Crudely_Indecent]

No, that statement is missing some punctuation that no COBOL developer would have missed.

Re:The reason it is still used is simple.

[Crudely_Indecent]

According to MicroFocus - no. Here's what they have to say about it:

Worldwide, 200x more daily COBOL transactions than Google and You Tube searches Five billion lines of new COBOL code are developed every year

Re:The reason it is still used is simple.

[HornWumpus]

1978. Be glad they didn't bury Oly.

Billy beer on the other hand would be worth a few bucks.

Re:The reason it is still used is simple.

[iggymanz]

you have a misconception, COBOL has the means to specify file structures that are platform independent, however there are also system dependent ones you can choose to use. Trivial to move ANSI standard COBOL with proper formats from one system to another, compared to say ansi C which might not even work at all.

Re:The reason it is still used is simple.

[jbolden]

In any language where you platform independent file structures they are going to be portable. C is much lower level. But Java, Perl, Lisp are all equally or more portable than COBOL. I'd say COBOL is one of the least portable languages since so much of its use is tied to dictionaries which tend to be very machine (not just platform) dependent.

Computers protest at being forced to run COBOL

[K. S. Kyosuke]

They abandoned worshipping the Lords of COBOL a long time ago.

COBOL is...

[erp_consultant]

not a lot of fun to program in. It's wordy, it's procedural...generally kind of boring. But...it's imbedded in so many mission critical systems. The ERP system that I work on is chock full of COBOL stuff, mainly in the Payroll processing modules. It works, it's really fast, and nobody wants to mess with it. Sure, you could rewrite it in Java or some other language but it represents risk that many companies are not willing to take.

COBOL programmers are in big demand now and it's only going to grow. I'm not sure how many schools still teach COBOL but I suspect it's not many. So if you can put up with having a little less glamorous coding to do it's a great job opportunity.

Re:COBOL is...

[Qzukk]

I feel that COBOL is the exact opposite of Perl. People call Perl a write-only language because you can write code in it that is really, really hard to read and understand. Meanwhile, statements like

MULTIPLY X BY Y GIVING RESULT

are easy to read and understand exactly what is happening, but I'll be damned if I can ever remember to write that twisted bit of English without looking it up in a reference (and I use this statement as an example every time I make this point about COBOL). For me, COBOL's attempt to be almost but not quite English has made it a read-only language.

Re:COBOL is...

[cdrudge]

COBOL stands for COmmon Business Oriented Language. It's syntax was suppose to be English readable to allow bean counters, actuaries, businessmen, etc to read, write, or at least understand what it was doing using terminology that they would use.

Re:COBOL is...

[Anonymous Coward]

COBOL has had COMPUTE since as long as I've been alive (40+ years). So, you can write algebraic formulae directly: COMPUTE X = X + 2

Also, the MULTIPLY...GIVING and other math verbs were almost assembler instructions: MULTIPLY=math-op-code, X,Y=input-variable-addresses, GIVING=target-variable-address. At the time, that saved quite a bit of programming without fancy parse-trees.

Re:COBOL is...

[nitehawk214]

"Make it possible for programmers to write in English and you will find the programmers cannot write in English."

Re:COBOL is...

[Anonymous Coward]

Exactly this!!

My dad programmed COBOL from the early 70's until he retired. He always came back to this point. You get an auditor comes in and wants to really know what your program is doing, he'd actually look at the listing. He wasn't a programmer, he was an accountant, an auditor. He could follow what you were doing without feeling like you were pulling the wool over his eyes. And if you don't think keeping an auditor happy is important, you haven't been audited.

Re:COBOL is...

[tlhIngan]

My dad programmed COBOL from the early 70's until he retired. He always came back to this point. You get an auditor comes in and wants to really know what your program is doing, he'd actually look at the listing. He wasn't a programmer, he was an accountant, an auditor. He could follow what you were doing without feeling like you were pulling the wool over his eyes. And if you don't think keeping an auditor happy is important, you haven't been audited.

That's probably why it's verbose. But it's probably also where we get a lot of the oddball "ickiness" - just like what you get when you let your boss get VB to do everything.

COBOL code isn't written by programmers, but by business admins - the accountants, management, etc who basically don't want to learn "code" but do something that feels natural to them.

Heck, if you've tried to do some accounting thing and get the wrong numbers, the accountant will probably be able to read the COBOL and figure out the problem. With C or other programming languages, you'll probably need to sit with the accountant and step through the code with them. Maybe even having to translate it to pseudocode (which has its own issues).

You Can Tell COBOL Was Designed By A Woman

[Anonymous Coward]

Pages and pages and pages of foreplay before you get any action.

Re:You Can Tell COBOL Was Designed By A Woman

[seven of five]

And a missing period gets you in a lot of trouble.

Hmm

[Tolkienfanatic]

As a current undergrad studying CS, I've never heard of COBOL in any context other than being a punchline. However, a few days ago at work there was a request for application onboarding for... you guessed it, a COBOL-based application. Suffice it to say I nearly sprayed coffee everywhere.

Re:Hmm

[Bucky24]

Let me guess: you are one of the new breed of brogrammers that think Java and C# are real languages.

I know you're just trolling, but I am curious to know: What is it you think that prevents Java and C# from being real languages?

Java

[hraponssi]

People always say Java is the next Cobol. I program in Java, so I guess I already joined the next COBOL gen?

Re:Java

[nitehawk214]

People always say Java is the next Cobol. I program in Java, so I guess I already joined the next COBOL gen?

And it is your duty as a Java programmer to prevent this prophecy from becoming true. Even if it means destroying Java when it's time comes.

Re:Java

[RightSaidFred99]

Nah, Java is the next C. It'll always be around and it works fine, and even by modern standards isn't all that bad. I find C# to be far superior to Java, but Java's fine and if I had to get a job doing only Java I wouldn't be too upset.

An advert, not even thinly veiled

[mpbrede]

Come on. Why is this even allowed on /.? The RFA has the email address of the recruiter and is really just a solicitation. The piece on /. is hardly any better.

Another good point

[Anonymous Coward]

One of the reasons so much IT outsourcing in mainframe shops is happening is because new workers have little exposure to the mainframe culture. I work in an industry highly dependent on mainframes, but not directly with the technology. However, I do see the fundamental difference between mainframe systems work and Linux/Windows on Intel systems work. For someone who doesn't "get it," mainframes look completely inflexible and definitely a legacy technology. When you're talking about a system that still has references to things like punch cards compared to Windows Server 2012 running in VMWare, there's a huge mindset change. There is also a very strict change control process around everything, usually because messing up something on the mainframe knocks out the company's key business operations. (Example: RBS went offline for days because an (offshore) employee messed up a batch scheduling software upgrade and executed a wrong rollback procedure.)

That's why I think mainframes and COBOL get a bad rap -- they're ancient systems, but only because they work and they're at the core of the businesses that use them. And for the purpose, they're great. Mainframes are designed for maximum transaction throughput and reliability above all else, which is why most people don't use them as a generic computing platform. I'm a systems engineer primarily working on Windows installations, but I'm also flexible and cross-platform enough to understand Linux, UNIX and the other systems our stuff talks to. Because of this, I'm employed -- you wouldn't believe how little effort it takes to stand out in an environment of people who stick to the one system they know. Adding a tool to the tool set isn't a bad thing. I don't know everything about Linux or mainframes, but I can at least ask intelligent questions.

I can also see why people might shy away from learning COBOL, since the MO for most companies dealing with talent shortages is to offshore everything. However, I'm of the mindset that everything happens in cycles. My company is very much "trailing edge" when it comes to IT trends, and we're just starting to figure out that offshoring isn't the magic answer to software development problems. So, I think the trend is coming back around, just like these newfangled "virtual machines" on Intel processors. Wow, what a concept! Sci-fi type stuff! :-)

Re:Another good point

[DutchUncle]

People have been reinventing mainframes - badly - for years. They just call them "servers" and "clouds" and other euphemisms.

Re:Another good point

[blippo]

Strict change control process you say...

It's hard to find anyone thats faster than a bunch of old COBOL geezers to rattle out untested code - or rather code that's not been even run even once - into production systems. But I guess they use changeman to do it, so they do at least know *what* code that's currently is running.

Re:Another good point

[blippo]

True that,

Whole departments exists, inside or outside companies, just to run sql servers, web servers, java application servers, virtual windows machines, etc etc, that's used just for developing and testing, and to get something done with them, like restoring a database backup from before your script messed it up, you need to file a "work order" and hopefully, some dude, possibly in another country, would find the time, within a couple of days, to restore it for you, because, you know, it's *clearly* cost effective to have a rational and efficient organisation for running servers...

We have reached exactly the incitements for the "PC Revolution." Would it be called "Personal Cloud Computing" this time, or will the "cloud" become "the stink" before that happens?

Re:Another good point

[Ultracrepidarian]

Sometimes, when there is a plane idling on the tarmac waiting for the payroll checks, ya do what ya gotta do.

Re:Another good point

[ebno-10db]

When you're talking about a system that still has references to things like punch cards ...

Nothing wrong with that as long as it's been updated to use Virtual Card Decks.

Re:Another good point

[jbolden]

That's not entirely true. Client / server is very different than mainframe. Mainframe culture assumes the client is thin to non-existent client server just sees the server as a data repository that can answer request. The web is pretty close to mainframe.

Re:Another good point

[HornWumpus]

Have all the checks made payable and addressed to yourself?

Re:Another good point

[DutchUncle]

You obviously were not in the mainframe world when editing and display terminals showed up. I was. Yes, there's more CPU power and prettier display now, but the work is being done somewhere else and the control is not local.

Re:Another good point

[inline_four]

Interesting point. My organization is probably neither on the forefront nor stuck in the past when it comes to enterprise architecture and development process. But what I'm witnessing is a desire to empower teams while maintaining a coherent operations structure. We want the best of both worlds -- flexible resource allocation and scaling, yet individualized development environments designed to fulfill needs of teams focused on specific areas of the whole enterprise before getting their stuff to a bigger integration point. Going ever deeper down the VM rabbit hole is how we plan to do it.

Not all organizations have the same needs, but this additional tier of virtualization is an interesting proposition. On the one hand, it has a lot of potential. On the other hand, we are already struggling to understand what goes on in our production environment during critical performance times or when troubleshooting complex problems or incidents. Are we overengineering it? Time will tell.

I'm considering this, actually

[Anonymous Coward]

I've got a pile of various degrees, none in CS, yet I keep ending up coding shit for a living. None of it is all that great - I'm a massive generalist and not a programmer. It's tempting to just get a good intro to COBOL and then dive into it for a career. It's one of those languages that doesn't change much and isn't about to get replaced with the newest and greatest.

After half of my career switching jobs every 3-4 years, I'm thinking about settling down. Compared to what I've had to code so far in life, COBOL doesn't look that bad.

COBOL is plainly superior...

[istartedi]

COBOL is plainly superior... from an evolutionary standpoint. It propagated and survived. Nevermind that it feeds on the souls of developers. That's irrelevant. Evolution only cares about propagation and survival.

Re:COBOL is plainly superior...

[BigFrango]

Weeds are also superior... from an evolutionary standpoint.

Re:COBOL is plainly superior...

[ebno-10db]

Weeds are also superior... from an evolutionary standpoint.

Not true! Why do you think meadows are full of grass instead of weeds? Hell, hundreds of thousands of square miles of the Great Plains were once covered with grass, despite buffalo regularly trampling it. Native grasses are very hardy, they just don't do so well when you regularly cut them to within an inch of their lives. Let grass grow to its proper height (a few feet depending on the type) and it will choke out the weeds.

Re:COBOL is plainly superior...

[HornWumpus]

Native grasses are weeds. Weeds are anything growing where you don't want them.

The weed in my backyard on the other hand, is not a weed.

Hipster COBOL

[Runesabre]

COBOL is a hipster programmer's dream!

Re:Hipster COBOL

[ebno-10db]

Call it retro and everyone will want to learn it.

Re:Nothing does it better

[icebike]

There is on thing every new COBOL complains about in COBOL: Its too verbose.
There is one thin that every COBOL journeyman loves about COBOL: Its so verbose and easy to read.

ask an ANDROID

[nitehawk214]

I am sure Data can chime in on this.

Again?

[Antipater]

An identical story was posted back in February. By the same user, no less. So, Mr. Josh Fruhlinger, how much does Eric Bloom pay you to Slashvertise for him?

not even C?

[ChipMonk]

From the homepage of OpenCOBOL:

OpenCOBOL translates COBOL into C and compiles the translated code using the native C compiler. You can build your COBOL programs on various platforms, including Unix/Linux, Mac OS X, and Microsoft Windows.

So would that be COBOL running on C?

Re:not even C?

[osu-neko]

No. That would be COBOL running on machine code. By the time it's running, compile time (the only time C was involved in the process) is past...

Re:not even C?

[ChipMonk]

It doesn't matter if it's running "machine code," in a JVM, in an LLVM, or in interpreted Bash. That's the Church-Turing thesis. The only difference is how the source code is examined.

we need more

[Toshito]

At my work we're just starting a multimillion dollar project, mostly in COBOL, on a mainframe. And I'm not talking about modifying old code, we're developing a new system. So we'll need about 30 new COBOL programmers very soon. It's far from dead!

Re:we need more

[jbolden]

Why? Mainframes far more modern, powerful languages and features. Why would you develop a brand new system in COBOL? What do people perceive as it getting them?

IF YOU CAN

[cmtuan]

        10 YOU      PIC 9.
            88    READ-THIS VALUE 1.

        IF READ-THIS = 1
            MOVE YOU TO THIS-JOB
        END-IF

Object-oriented

[DutchUncle]

MOVE CORRESPONDING. Try doing that right in any other language. Try figuring out where each different C compiler put your bits and bytes, and what size it made your integers, and what other random changes it made with alignment and ordering. I cannot believe that anyone on /. honestly loves a language that defines which of its behavior is undefined and unpredictable.

You can write both garbage and poetry in any language. Cobol at least *tried* to make some things clear.

Re:Object-oriented

[jbolden]

Move CORRESPONDING is fricking dangerous code. Getting something like that to work right is one of the central objectives of Object Oriented assignment operators. More or less... the equivalent in C++ is new

MOVE CORRESPONDING GROUP-1 TO GROUP-2

becomes

Group-2 x = new (y) // y is of type Group-1

but yes you will need to define how the constructor works explicitly because that is too dangerous otherwise.

Re:Object-oriented

[DutchUncle]

Yes, you need to define the constructor, and it may not work; or it works ever so slightly differently from every other constructor; or it may be incomplete; or it may not keep up with future modifications when somebody adds something to the structure(s). MOVE CORRESPONDING will either work or give a compile error. Simple.

I wouldn't write Cobol again unless there were nothing else to work at; but if you're telling me that a language you make up on the fly by hiding the most important things is automatically better, I'll disagree bigtime. I've seen things hidden in constructors that should have been in open code, with big flashing neon signs for comments, because they were so "clever" that nobody could ever fix them when they went wrong.

Re:Object-oriented

[jbolden]

MOVE CORRESPONDING does not work consistently. Slight variants in the way the objects are defined can cause huge changes in what gets copied.

but if you're telling me that a language you make up on the fly by hiding the most important things is automatically better, I'll disagree bigtime.

I didn't say that. I said that accomplishing overloading of assignment is handled better in OO languages than COBOL. That there should be code for constructors.

I've seen things hidden in constructors that should have been in open code, with big flashing neon signs for comments, because they were so "clever" that nobody could ever fix them when they went wrong.

What does that even mean? A constructor is "open code" for someone debugging the library. For anyone else they shouldn't be fixing it.

good career stability

[KernelMuncher]

In the late 90's COBOL consultants were paid big bucks to fix the Y2K (non) problem. Now they get good money for replacing all of the retiring baby boomers. And since nobody in India seems to know the language (and there's zero interest in universities teaching it), I think job security would be excellent. It's a great niche to fill.

Sounds interesting....

[thewils]

Until you realize that you have to go back to the world of Packed Decimal and EBCDIC - no thanks!!!

Re:Sounds interesting....

[DutchUncle]

True, EBCDIC is a nightmare, but with packed decimal you can have exact numbers up to 10**508 or something (it's not a full 256 bytes, I just forget what the leading key looks like). I started on IBM 360s, and thought EBCDIC was normal; then I moved to DECsystems and realized how much easier ASCII was. But the MVC and CLC packed decimal instructions, especially when modified with an EXecute , were amazingly powerful for the era.

goto has its place

[Chirs]

The best use of goto is for an orderly cleanup of resources. If something goes wrong partway through acquiring all the necessary resources to do a task, you just "goto" the appropriate stage of the cleanup. See http://programmers.stackexchange.com/questions/154974/is-this-a-decent-use-case-for-goto-in-c/154980#154980 for example.

It's also good for breaking out of multiply-nested loops, for checking a bunch of possible error conditions before starting the meat of a procedure, etc.

Re:goto has its place

[Darinbob]

With COBOL you can change the destination of a GO TO on the fly. Some call this self modifying code, but it's more similar perhaps to Fortran's computed GOTO. So you can really get some convoluted spaghetti code this way, much more than if you just had a simple GO TO. Especially if when the program was written in older dialects.

Maybe the developers weren't clever...COBOL did OK

[opentunings]

In the '90's I was working for BigTelCo on an ordering system.

Unix / C system "A" would enquire about account details based on any of various inputs (account number, main phone number, etc.). They sent a transaction to a central system "B" app server for which I wrote about 1/3 of the code. Well over 90% of system B was COBOL. Typically we were running about 0.7 sec response times. During that 0.7 sec, our system would:

ID the type of access inputs, look it up in an IMS database, figure out which datacenter (Georgia / Florida / Kansas / Colorado / Massachusetts) had the account, send the transaction there.

Pull the transaction, call a dynamic table to see what data were required (could be changed w/o recompiling or bouncing system), pull the data, create stream-style (not block I/O as the mainframe was used to) data, send it back to Unix for parsing.

Did I mention that part of the routing, and all the dynamic tables, were provided from software written in PL/1? So our COBOL modules were linked with PL/1 to create the final executables.

That's not the most clever or the least wanky system I've ever been on, but the old COBOL girl did pretty good. The Unix / C folks got intelligible data as soon as they figured out how to tweak HP's EBCDIC-to-ASCII tool so the non-alpha, non-numeric characters would be handled. And at that point the data stream looked just like what they'd been passing one another, from C to C.

And yes, the last time I heard, people were still creating wrappers around the mainframe system's feeds so that other C / C++ systems could use the data.

Good. I can use the help.

[mnemotronic]

I'm working on a git client written in COBOL and need help with the Beowulf drivers.

The very definition of a soul destroying job.

[AmazingRuss]

The money better be very, very good.

Re:This again?

[jbolden]

Agreed. The companies / departments that are using COBOL are the ones that don't want to invest in their infrastructure which means they don't want to hire lots of people. There are going to be a small number of jobs forever but it will never be a job fest.

I used to be a COBOL programmer

[IWantMoreSpamPlease]

that, and assembly.
My assembly I forgot with time, but COBOL will take a 9mm to remove.

Re:I used to be a COBOL programmer

[DutchUncle]

I remember my assembly. IBM macros could do things that C++ templates still dream of. Plus I've worked in embedded systems the rest of my career, so it's always included some assembly on one processor or another.

Still had one of the best UI I have seen.

[will_die]

Spend some time doing COBOL programming after college; it was on a HP of some kind.
About the only thing I remember about it was the UI generator. You could design the screen, move stuff around, etc and it was character based. The best thing about it when you put down a field and then bring up a seperate properties screen and set the input, using a regular expression for custom fields put out different error messages for different condition and testing different condition. You could set what the output would look like, comma, dollar signs, # of numbers after the decimal, etc. and when the user went to edit the field all that output formatting would be removed until they left the field.

Re:Yet. Another. MicroFocus. Planted. Article. Ugh

[lord_mike]

My kingdom for some mod points! AC has got it right. No one cares about COBOL programmers... it's all about the COBOL interfaces. You can learn the COBOL language in a day on a PC, but if you don't have a mainframe environment to write that code in (including JCL), your efforts will have been pointless. COBOL is simply short for mainframe. When an article talks about COBOL programmers with experience, they mean mainframe programmers with experience. So, anyone thinking that they can read a book on COBOL and get a job will find themselves in for a rude awakening.

How to write non-portable code: Lesson 1.

[Valdrax]

Nah, you can do it just as trivially in C, just make a struct mapping the physical record just as in COBOL. People often don't do that, but that's people for you.

Here's a homework assignment for you. What is the layout in memory and total size in bytes of the following struct on x86 and on ARM?

struct account {
      short account_number;
      char first_name[30];
      char last_name[30];
      float balance;
      char account_type[3];
      int ssn;
};

Ignore endianness or, I suppose, continue ignoring endianness.

From what I can tell

[edrobinson]

Nobody posting on this thread has ever evenseen COBOL code!

Is that a serious question?

[CrazyBusError]

Try googling. :0)

Visual COBOL? Fujitsu did that - I have a demo disk from somewhere around 2001.

COBOL++? Well, OO COBOL has been in existence since 1996/7 that I'm aware of and doubtless from before that. Microfocus were the first to do it that I came across, but the above-mentioned fujitsu compiler also did OO.

Did you also know that COBOL.NET exists? Oh yes. Be afraid...

*sighs*

[CrazyBusError]

You realise that's not how a level 88 works, right?

(Hint: It would either be 'IF YOU = 1 THEN' or 'IF READ-THIS THEN').

Train?

[carys689]

TRAIN people to program in COBOL? Why not just HIRE the unemployed COBOL programmers?

Re:How to write non-portable code: Lesson 1.

[lgw]

If your going to code this way, don't use the always-been-stupid "I don't know what size this is" C types. I've never used those in many, many years of C/C++ coding, as you never know what you'll get. There isn't even an explicit type for float (and the standard is useless), but all modern compilers use the same 4-byte format, and freely mix floats and ints in memory (the C standard allows for stuff like special memory banks just for floats that is all history now).

struct account {
    int16_t account_number;
    char first_name[30];
    char last_name[30];
    float balance;
    char account_type[3];
    int32_t ssn;
};

Isn't very mysterious at all. Alignment restrictions vary by platform, but you get used to them.

It's annoying that C isn't as explicit as asm or COBOL when it comes to data structure layouts, but if you work on one platform for a while the compiler won't surprise you. It's more annoying that you have to use odd #pragmas or unions to force explicit alignment, but in practice you just pad stuff out for clarity.

struct account {
    int16_t account_number;

    char first_name[30];
    char last_name[30];
    char _0[2]

    float balance;
    char account_type[3];
    char _1[1]

    int32_t ssn;
};

Most real-world code tends to arrange fields to minimize space lost to alignment needs anyhow, so you don't get much padding.

And if you're worried about stuff like endianness or other cross-platform quirks, you obviously don't want to be rolling COBOL style.

Don't be disrespectful of the elder languages

[dakra137]

Summary:

* COBOL isn't evil. It is good for its domain. It is very good for nested data structures.
* An example is given that goes beyond the typical.
* I claim not to be a COBOL bigot.
* I explain where COBOL programmers came from originally.
* There are some aspects of COBOL I like.

Don't be disrespectful of the elder languages just because their domain isn't what you work on.
COBOL programs are probably handling your payroll, bank, and investment accounts.

Details:

>> For those of us who are unfamiliar, could you describe what it is that COBOL does that other languages don't cover as well?
and
>> Pages and pages and pages of foreplay before you get any action.
Yes, there is stuff at the top that is largely documentation followed by a FILE CONTROL SECTION with information about the files to be used, and then the DATA DIVISION. In many cases, the DATA DIVISION, the part of the program that describes the variables, condition codes, and data structures is larger than the procedural logic.

Most of the discussion here has been about the procedural code in COBOL programs, not the DATA DIVISION and its structures. One can accomplish very interesting things with the hierarchic data structures of COBOL and PL/I. The following example shows how to march through a variable length record containing instances of 2 kinds of variable length segments, each of which could appear many times. It leaves out some of the boring stuff.

77 OFFSET-1 PIC S9999 USAGE COMP-3.
01 LAYOUT-1.
03 LL-1 PIC S9999 USAGE COMP-3.
03 BB-1 PIC XX USAGE DISPLAY.
03 FILLER PIC X OCCURS 0 TO 4096 TIMES DEPENDING ON OFFSET-1.
03 SEGMENT-LENGTH PIC S9999 USAGE COMP-3.
03 SEGMENT-TYPE PIC XX USAGE DISPLAY.
88 TYPEAA VALUE "AA".
88 TYPEBB VALUE "BB".
03 AASEGMENT.
05 FIRST-FIELD ....
05 SECOND-FIELD ....
03 BBSEGMENT REDEFINES ASEGMENT.
05 FIRST-FIELD ....
05 SECOND-FIELD ....

PROCEDURE DIVISION.

open the file

PERFORM UNTIL EOF-1

READ FILE-1 INTO LAYOUT-1
SUBTRACT 4 FROM LL-1 GIVING OFFSET-1

PERFORM WITH TEST BEFORE UNTIL OFFSET-1 >= LL-1

IF TYPEAA THEN
blah blah blah
END-IF
IF TYPEBB THEN
blah blah blah
END-IF
* slide over to the next segment
ADD LL-1A TO OFFSET-1
END-PERFORM

END-PERFORM.

Admittedly, this is not your typical COBOL program, but stuff like this can and is done with COBOL when necessary. My first real COBOL program read 7-track (6 bit characters + parity) tape where there were multiple variable length records within a block. To process the records on an IBM mainframe, I had to deal with the fact that the lengths were 12 bits that had been read into two 8 character bytes, so the length was really byte0+64*byte1. All this was doable in COBOL. Once I got the data out, I did the first level of analysis in FORTRAN and the fun stuff in APL.

I wouldn't try to create and select from the 4 dimensional outer product of 4 vectors in COBOL, and I wouldn't and didn't in FORTRAN, as long as I had access to APL.

When is COBOL a preferred choice:
* When the data structure definitions are many and many are subsidiary to one another.
* When it's what the example is writt

Re:Don't be disrespectful of the elder languages

[DutchUncle]

Elder languages are like elder gods: irate when disturbed.

Free Cobol compiler

[gadfium]

If you want to play with a free compiler, try OpenCOBOL at http://www.opencobol.org/.

There is a list of other free COBOL compilers at http://mainframewizard.com/content/free-cobol-compilers but some of them look pretty old.

Re:This again?

[DutchUncle]

Sorry, you're looking from only one angle. It's not that they don't want to invest. It's that they don't want to make a complete change from the ground up all at once. It would be like renovating your house by bulldozing it. And some houses are historic :-) and aren't gonna get bulldozed anytime soon.

Look at the air traffic control system (NOT in Cobol!). It's old, it's outdated, it's straining under the load. Multiple projects have tried to replace it . . . and failed. I don't understand why - a game industry that could do MMP online Freespace and Wing Commander *decades* ago should have been able to handle tracking real planes by now - but the new projects just don't keep up. And nobody is going to pull the plug on the old system until they're *sure* that the new one can be trusted.

If an old accounting system is still running, still doing its job, just like the pipes and wires in the walls, nobody wants to go change them just because they're not new.

Re:Maybe the developers weren't clever...COBOL did

[Hognoxious]

Very nice, but what does that have to do with the language itself being horrible until they started nailing features onto it?

Re:This again?

[jbolden]

Sorry, you're looking from only one angle. It's not that they don't want to invest. It's that they don't want to make a complete change from the ground up all at once.

They don't have to do it all at once. There are a lot of good tools that help companies bridge over where they end up with a COBOL / Java hybrid for a time. A company with a system consisting of 3000 COBOL programs can be switching gradually. Refactoring is not reconstruction.

Look at the air traffic control system (NOT in Cobol!). It's old, it's outdated, it's straining under the load. Multiple projects have tried to replace it . . . and failed.

That's a different story. That is ground up recreation rather than refactoring. And the reason they fail is that old systems often involve institutional knowledge which the company (or government department) no longer posses. The 1960s air traffic control system was written by talking to air traffic controllers who ran the system by hand. Preforce they understood all the aspects of managing clusters of planes. Today's controllers are a subsystem that handles a particularly complex part of a mostly computerized system. Someone needs to look at that old code and work through what the 1960s air traffic controllers told the programmers of the 1960s.

If an old accounting system is still running, still doing its job, just like the pipes and wires in the walls, nobody wants to go change them just because they're not new.

Absolutely. But if an old accounting system is still doing its job then the company hasn't spent a lot on things like integrating ERP into their accounting system. Which means they aren's spending a lot on infrastructure.

Re:Maybe the developers weren't clever...COBOL did

[opentunings]

Features like stream I/O support were in COBOL in the 80's / 90's. As was linking compiled COBOL to compiled non-COBOL. It was one of the very first portable languages (per Wikipedia). Substringing and multidimentional arrays were easy. And when I took my years of COBOL to C++ class, the instructor told me I was "too structured" - the COBOL I'd been writing was more structured than the C++ he was used to seeing. While a lot of people only needed simple COBOL, it actually had a lot of advanced features available back in the late 80's.

Back in 1961, if you were trying to create a billing system for a big company, your options included COBOL, Fortran, assembly language and not much else. Programmers in the 60's were grateful for the ease of COBOL when used in a business setting, which (back then) consisted mostly of reading punch cards and creating pretty reports for pointy-haired bosses. COBOL made their lives much easier at that time.

Easy to write, easy to structure, very versatile, capable of doing menial tasks to tons of data quickly. Doesn't sound too bad to me.

Most computer languages are horrible if you choose to make them horrible. My point is that you don't have to make COBOL horrible, and most COBOL programmers don't.

It's more typing than most languages...but it's not horrible unless an inexperienced programmer chooses to make it horrible. Or unless you haven't spent much time with it in a business environment.

Missing the point of COBOL

[hicksw]

Yes, the PROCEDURE DIVISION looks clunky.

COBOL lives by its DATA DIVISION. That's where the magic happens.

And good COBOL can be written like unix, small modules that do one thing well.
It just needs a humungous job scheduler to lace them together into a production system.

Been there, done that, fixed it for Y2K.
--
You can trust me -- I'm from the Internet.