7 ms·

> it's a Fortran or Cobol situation, only maybe three or four orders of magnitudes bigger. You underestimate the amount of COBOL code that is still out there r

• kpil 9y ago
  I've done work for a fair number of banks and insurance companies, and my anecdotal impression is that there is always a java system siphoning data from the cobol systems... Both stay around for the same reason: backwards compatability and a stable api+abi. If you find and old Java system it's often trivial to do changes and recompile. Even a few years old C program is often problematic due to changes in the OS or libraries. I have no idea if it's possible to compile a couple of years old js code...
  • ido 9y ago
    Js isn't usually compiled at all! And old sites using old js generally still work in modern browsers.
    • kpil 9y ago
      ... but modern js almost always have a build step. But yeah, the fair deal of time I have spent on fixing old web pages was more related to fixing the html and CSS and just minor problems related to js.
• shagie 9y ago
  That is very true - there is a lot of cobol out there. Fortunately, it has a JVM target too. http://documentation.microfocus.com/help/index.jsp?topic=%2Fcom.microfocus.eclipse.infocenter.visualcobol.eclipseux%2FGUID-DEAFFCA6-6D75-4AEA-A3B6-6DF0BDCF3E2F.html http://documentation.microfocus.com/help/index.jsp?topic=%2F...
  • pjmlp 9y ago
    And .NET as well. http://www.coss-solutions.nl/index.php/2013-11-18-13-59-23/netcobol/microsoft-net http://www.coss-solutions.nl/index.php/2013-11-18-13-59-23/n... It can even target Azure deployments!
  • shakna 9y ago
    Wouldn't the JVM's warmup time make it untenable for most places COBOL is used?
    • rusk 9y ago
      What places are these? I thought Cobol ran on server-side mostly? JVM is always warm.
      • shakna 9y ago
        Maybe I can better explain with an example, but it comes from the only time I've worked with Cobol professionally, and I have avoided it since. My experience is limited, and might not be the norm. It was a bank, and transactions were processed through a pipeline. Part of that pipeline was handing off transaction data from an always-active system, but then into many, many short-lived Cobol processes, and then into another always-active system. The Cobol processes basically munged, pulled and pushed to database/s, and then killed itself. In this case, I could see warm-up time being a huge issue, though a switch into another language might bring a change in architecture to threading and the like which would remove that problem, but I can't see a bank changing architectures easily. From my limited exposure, several financial companies connected with the bank had similar processes. Something like Java or C running a server, Cobol when numbers need serious crunching, and then back into another server application. (Incidentally, both the server processes were Fortran, if that's interesting to anybody).
        • rusk 9y ago
          I think I understand what you're saying but cobol runs in an environment that is optimised for cobol, and I'd expect where this were to be java you would have a similar arrangement in place. For a trivial example of what I'm talking about check out nailgun [0] [0] http://www.martiansoftware.com/nailgun/ http://www.martiansoftware.com/nailgun/