Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

How To Become a Millionaire with Parrot and COBOL 8 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.

  • I used to know a couple of people who decided to go into COBOL development because they could see the way the salaries were trending back in the early nineties :-)

    Last time I talked to one of them (around 2000 I think) she told me that she knew of two large orgs that had taken their compiler development in-house - because they couldn't take the risk of not being able to keep the code running on newer boxes as time went on... so folk maybe playing this sort of game already.

    • What you're talking about is one of several strategies (Mad Max) to deal with the problems companies are facing.

      • Ignore it.
        The hope here is that you'll not be working for the company by the time the problem is critical (Passing the buck).
      • Future-proof it.
        This is the "Mad Max still has gasoline" strategy.
      • Supplement it.
        This attempts to retain your COBOL programmers but allow their systems to more easily integrate with others (let's hook a turbo-charger up this Model T and hope we don't need more parts).
      • Repla

  • This is already being done, compiling for a VM that is a little more widely deployed than Parrot ;-)

    • It's possible you've seen something different, but what I've seen is COBOL to Java translators which then run on the JVM. I have not seen native COBOL running on the JVM. Nor have I seen an ability to migrate the code in place by embedding a modern language in it. If you've an example of either of those, I'd love to see it!

      • They have had production quality COBOLs on the .NET platform for a little while now. Given how the CLR works it becomes really easy to either have your COBOL call other libraries or your other libraries call COBOL.

        • Ah, the CLR is definitely a different story. I suspect that this would be a more attractive choice for COBOL developers as modern COBOL runs very fast and performance is often extremely important. I don't think Parrot would fare well if that's important. If easy of implementation and flexibility are important, though, then Parrot, I suspect, would crush the CLR.

          • Actually the CLR is pretty flexible, it used to be that ILASM was very much just C# written in Assembler, but recent efforts to make the CLR more dynamic (IronPython, etc) seem to have really pushed it forward. While I am not a fan of their OS, Microsoft Research has some really *really* smart people working there who are doing a lot of very cool stuff.
      • Check out isCOBOL @ http://www.veryant.com/ [veryant.com]
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.