Unfortunately you have fallen into the common trap of comparing bad COBOL with good C#. If you had written good COBOL using Micro Focus products it would look like this:
method-id. “button1_Click” private.
procedure division using by value sender as object e as
type “System.EventArgs”.
set button1::“PropTest” to "Call COBOL"
end method “button1_Click”.
Which has almost exactly the same number of syntactic elements as the C# version.
You have also chosen an example of something C# is very good at. How about something extremely useful and at which C# is not very good? How about writing large precision calculation software? This is the sort of thing that stock exchanges, banks and many other ‘heavy lifting’ applications have to do all the time. If COBOL is so clunky, show me how C# would do this (I think you will find you need a third party class library and a page of code to do what COBOL does in a few lines):
program-id. Program1.
01 a pic 9(30)v99.
01 b pic 9(30)v99.
01 d pic 9(30).99.
01 i binary-long.
procedure division.
perform varying i from 0 by 1 until i equals 35
compute a = a * 9 + i / 91
compute b = b * 9 + i / 101
end-perform
move a to d
display "First number " d
move b to d
display "Second number " d
add a to b giving d
display "Sum of the two " d
end program Program1.
Not only is this a simple and clean implmentation, it will compile and run native on almost any major platform as well as .net.
The point being that one reason COBOL has been around for so long because it does what it does very well. Not only that, but modern versions of COBOL do everything else well in addition.
The next generation of COBOL from Micro Focus will be able to do even more with even fewer syntactic elements required and even more features C# and other similar languages lack.
it’s probably not your opinion, but it’s more like comparing the iphone/every other phone with a straight forward oldschool calculator
what would you use to do some simple calcs?
cobol programs are often used in banks or companies like that
if you just have to put in a couple of numbers - and calculate them/or transfer them to other banks - which is actually pretty much what banks are doing - then cobol is far better than using a 4gl language
This goes back to the root cause of all legacy software problems in my opinion “All software should have a shelf life”, “All software should come with an expiry date.”.
“I have never, in my entire so-called “professional” programming career, met anyone who was actively writing COBOL code.”
There are many young ( you don’t believe though) people who are developing / supporting COBOL code, for the bank / corporations around the globe (not only North America but all over the world) – can be found in INDIA.
Program1… I would be interested to know how well it compiles and runs in actual practice. My concern is that 936 should have at least 34 digits to the left of the decimal, and you only appear to have given space for 30. (The actual number will be higher than 936, of course, because of the variance introduced by ‘i’).
(I would also be curious about the bank that needs to measure decillions of anything, but hey, to each their obscurely large numbers, yes?)
The sample code you used to show COBOL code in .net is not typical for COBOL applciation , (NO GUI) .COBOL is used for modeling business and transaction. I worked in very large project using COBOL for 3 years, and I have been working with.NET as well recently.And I can guarantee you that working in businness transaction with .net is not compared to COBOL. COBOL seems to be more concise and more ATOMIC. I’ve experienced a situation where Green and black terminal are more usable and bug free than fancy gui with bunch of button.
(think command line vs GUI) I think more developper find command line more productive than GUI ,same apply to end users.
The program compiles and runs just fine. The overflow characteristics of the calculation are defined. However, increasing the size of the fields to 9(32)v99 gives this result:
First number 04302298532283486384640958153141.48
Second number 00043457560850577111133950902536.17
Sum of the two 04345756093134063495774909055677.65
Now, as to who requires large numbers like this? The following COBOL uses large numbers to compute the geometric mean of 5 tax returns to five decimal places. I realise it is a bit artificial, but it proves the point that high accuracy numbers can be required quite easily.
program-id. Program1.
01 a pic 9(28)v99999 occurs 10.
01 b pic 9(28)v99999.
01 d pic 9(28).99999.
01 i binary-long.
procedure division.
move 125621.23 to b
*> generate some numbers - these would be from a data source
*> in a real application
perform varying i from 1 by 1 until i equals 5
compute b = b * 1.11176
move b to a(i)
end-perform
*> compute the geometric mean
perform varying i from 1 by 1 until i equals 5
multiply b by a(i) giving b
end-perform
move b to d
display "Working variable " d
compute b = b ** 0.2
move b to d
display "Geometric Mean " d
end program Program1.
Which gives:
Working variable 0137870017292352733686651403.77949
Geometric Mean 0000000000000000000000169002.82570
As with any example, this one can be attacked, however, I believe it to be illustrative.
OK, no way am I reading 200+ comments, but I submit this:
Most of the COBOL workforce is retired, dead, or dying. There exists little to no interest in young Developers to go the COBOL route. Companies better start migrating, lest they find themselves in a pinch to find any COBOL people.
That said, the average salary for COBOL Developers (Sorry, “Programmers”) is poised for a steep hike in the next decade or so.
