Cobol is also used for air traffic control, yes really.
R is widely used in banks, but no-one "cares" about it because if you can do this sort of work, it is assumed that you can pick it up on the way.
Kartik may have missed the point.
The list of languages was those for which the supply and demand is moving in favour of people with that skill. That's a different question to whether the language is "good".
The Cobol market reflects the fact that very few people put in the effort to learn it, but that there is a still a colossal amount of it in use. That code is really important, and would cost a vast amount to replace, indeed discovering all the business logic and reasons why it is the way it is would be hugely difficult. The chance of the replacement working as well is very small because the old system has been tried and tested at great length.
That's not unique to Cobol, applies to Fortran, and has happened to VB faster than many expected.
It will happen to Java, and the m0ost important thing to realise about that is that it will happen within your career and suxch is the pacew of change, the thing that replaces Java which now currently does not exist or has a user base <0.01% of programmers will also go that way within your career.
Maybe even the successor to that...
Thus Merrill Lynch has a very important fixed income system based upon Cobol, and JP Morgan is critically dependent upon a system written in SmallTalk 80, (the clue is in the name). I know people who've been working on the same C/
C++ program for 20 years in a very large bank.
As a simplified example for why you leave it alone:
Some bond yields are worked through 360 day years, but someone who didn't know that might see it, and think it a typing error, changing it to 365
That's close enough to produce reasonable results, but far away enough to cost real money, and finding the bug later could take man months.
Of course people here know about the 360 day count issue, but are you
really sure that all instances of 360 refer to bond day counts , in a program with hundreds of thousands of lines of code ?
You feeling lucky punk ?
Also, just to make it more fun, different languages calculate the same expression differently. Some will give different results for expressions as simple as
x = a* b /c
Also if b and c are integers but a is floating point, they may choose to give different results even if they apply the same rules of precedence.
But not always
JavaScript is a gravely misunderstood language, not really being a form of Java for a start, and it can express things that are really hard to express in any compiled language.
Some languages allow "computed goto"
In VB, C,
C++ Java et al you write
goto label:
label : DoStuff
Which is what was chosen for C and so function pointers were set up to give a 'safer' version of jump tables, necessary for operating system implementation.
A goto is of course a jump to a different piece of code which lives at some address, hence the function pointers in C,
C++, and VB
But some languages allow you to go to the result of any expression that returns an integer, thus
goto a*b+1
is perfectly valid (done it myself)
One language was more friendly, and allowed you to use floating point values so that
goto Sqrt(x)
worked
But of course that meant you sometimes tried to jump to 7.99999
So to be helpful, it would goto the nearest line of code.
Think about that for a while, if it doesn't hurt your head then you will never be a real programmer.
There is the infamous "wormhole bug" discovered by my gang at IBM's labs, where some malformed function declarations in C could cause you to return to a different function than the one that called you.
Turned out to be in some working code, (OK,
nearly working). You port that code to
C++ or C# and it will behave correctly, but the program won't work.
I could talk about this sort of stuff for days, and it's not even what I do for a living.
Fortunately the wormhole bug can be watched through a standard debugger, without having to use an In Circuit Emulator, or other hardware assistance, but many
interesting behaviours disappear under the debugger. A good % of all programs in use today will not work if they
aren't compiled for debugging support, trying to porduce a release version will result in a program that won't run, for no obvious reason.
A big % of the asset value of any firm is the software that runs it, you screw with it at your peril.