Live data from Hacker News

Don't hate COBOL until you've tried it

opensource.com

121–130 of 139 posts

Re: Don't hate COBOL until you've tried it

#121

> 5 billion lines of new COBOL code are written every year. Are you sure about that? Sounds like rather a lot.

It doesn't sound too off to me - I can believe that there are a million legacy COBOL users around and that each writes on average a thousand lines of maintenance code each year. Or maybe fewer users and more lines - COBOL is a notoriously verbose language.

I'm the author of the article, and I linked to the source of those numbers. The numbers seem reasonable to me too for the same reasons dcminter gave. One other reason is COBOL is a language that lends itself to copying and pasting old code instead of writing subroutines, so that leads to a lot of lines of code.

Re: Don't hate COBOL until you've tried it

#122

Earlier quoted context omitted.

> one of the biggest productivity improvements in the history of programming, comparable to the introduction of Java and VM-based programs in the 1990s. If languages like Smalltalk, APL and Lisp aren't counted, then sure, Java was big productivity boost in the history of programming.

I think that the reach of a language need to be considered, as influential and lovable those language might be most of the effect they had was by influencing other languages.

There's nothing wrong with that. Algol heavily influenced the design of scheme, but I've never seen an Algol program in the wild. That doesn't mean it wasn't influential.

Einstein got the Nobel for the photoelectric effect, which we take advantage of continuously every day. I'd say that was influential.

Re: Don't hate COBOL until you've tried it

#123
I give credit where it's due: In 1959 this was a breaktrough; made easy for non-technical people to support business operations using code that was easy to write, easy to understand, massively better than assembly in this regard. Also, record definition and manipulation was an innovation in itself (in an era without RDBMS), not to mention the builtin support for "accounting" decimal arithmetic. It was really "Batteries-Included".

But programming evolved and Cobol did not evolve at the speed of the times. In 1968 (Cobol-68) it was already outdated compared to IBM PL/1 (a big monster of a language, similar but much more powerful).

And in 2017, "Try COBOL"? You mean, try a language where I need to deal with record access as if I were rolling my own DBMS system, with almost no module support, and copious need for copy/paste of code at every file (little chance of code reuse)? Where separation of concerns is almost zero?

No, i think writing in INTERCAL-72, Brainf_ck or LOLCODE would be more fun.

Re: Don't hate COBOL until you've tried it

#124
There have been some very interesting comments made in these comments. Having used COBOL to write communications and networking programs, I found the version we used to be useful in the context of the work being done. I know of people who so hate the language that you could offer them $1,000,000 an hour to work on a project and they would refuse. Others would just as happily take up the offer.

What I do find interesting is the attitude of some who classify COBOL as ancient (etc) and have not yet realised that there are a number of major modern languages that are the spiritual descendants of COBOL. These being ADA, Java, C#, C++ and the rest of their ilk.

They each have a place to play in the computing world, but they each are the wrong language for many purposes. Too oft I find, many programmers know one or two languages and they are the worse off for that. Different languages give different insights into specific problem domains. Every language allows some things to be done easily and other things to be done hard.

Decades ago now, as CompSci undergraduates, we were expected to learn (or at least use) every available language, from Fortran to COBOL, Algol 60 to Lisp, assembler to Simula, Snobol to Pascal, Basic to Algol 68, etc., etc., etc.

These days, undergraduates seem to be taught one or two languages and that's it. It shows up in their later inability to solve certain kinds of problems in a problem space specific way.

Re: Don't hate COBOL until you've tried it

#125

I worked for one of those companies using COBOL. This strikes me: > Once I discovered what the problem was, the fix was easy: I deleted one character of white space from the beginning of line 19, which put the period at column 72. Although I'd never encountered it before, this was such a common bug that many mainframe COBOL programmers would tape a piece of thread between columns 72 and 73 on their terminals. Why wou…

This is trivially solved by linters.

Re: Don't hate COBOL until you've tried it

#126

Dates fixed in a YYYYMMDD representation. Seems like very ad-hoc representation. If you need "sixty days before such and such a date", ouch. Shipping price conforms to a "pic 99v99". So what happens if a really big shipment needs to be made for which $100.47 needs to be charged?

When I wrote the article I didn't have access to code I worked on 2 decades ago, and if I did I couldn't have used it in the article anyway. This was indented to illustrate the problem with problem with column 73, not to handle all possible cases.

Having said that, situations like would come up sometimes. You really did have to decide ahead of time how big field could be. You could leave extra filler bytes in your tables (literally named "filler") but it was still a big hassle to deal with.

Re: Don't hate COBOL until you've tried it

#127

I worked for one of those companies using COBOL. This strikes me: > Once I discovered what the problem was, the fix was easy: I deleted one character of white space from the beginning of line 19, which put the period at column 72. Although I'd never encountered it before, this was such a common bug that many mainframe COBOL programmers would tape a piece of thread between columns 72 and 73 on their terminals. Why wou…

This is trivially solved by linters.

It's also solved by modern editors that do syntax highlighting. Both emacs and vim flagged that period as an error when I was working on the example in the article. But sadly the editor I was using at the time did not.

Re: Don't hate COBOL until you've tried it

#129

I have not used COBOL for 30 years but the language deserves respect. The transition from assembler to COBOL was one of the biggest productivity improvements in the history of programming, comparable to the introduction of Java and VM-based programs in the 1990s. COBOL is still pretty efficient for tasks like scanning data on magnetic tapes--not that most of us do that any more. In fact it was pretty good for any pro…

Fortran's older and Lisp is as old (it can be argued about whether COBOL or Lisp are older). Fortran and Lisp seem to have held up much better. ALGOL is another contemporary, and arguably the one that has the biggest impact on popular languages.

Just a note on FORTRAN (which I also used for about a decade) vs. COBOL. It's important to remember that FORTRAN could not deal easily with character data until FORTRAN-77 which introduced the CHARACTER type. Prior to that you stored character data in arrays of 4-byte words, INTs if I recall correctly. It was really painful to use for data manipulation and reports which were among the main forms of output at the time.

I'm also a big FORTRAN fan, especially the VAX-FORTRAN variant DEC introduced in the 1980s. It was great for numerical analysis but also included library calls to access the operating system, much like C. Some of us were late to the Unix party, so this was a huge step forward.

Re: Don't hate COBOL until you've tried it

#130

I once had to port COBOL to Java. It presented some interesting problems because of EBCDIC, nibbles, non IEEE arithmetic, and alien data formats. A long story short: there are problems where COBOL is better suited than Java.

Were you also moving from a mainframe to a server? I would have thought that Java on a mainframe would handle EBCDIC just fine, but I have never tried it.

the 'mainframe' (a prehistoric Siemens BS2000) no longer really existed as Siemens no longer gave hardware support. Instead, it was virtualised and emulated on a desktop x86.
Post reply on HN