Modder, programmer, and all around tinkerer. Yes, I’m that New Vegas and Deus Ex guy.

You can also find me over at lemmy.sdf.org under the same username. Also kbin.social if it ever comes back from the dead.

  • 0 Posts
  • 12 Comments
Joined 10 months ago
Cake day: December 25th, 2025
  • Y|yukichigai@kbin.earthtoProgrammer Humor@programming.dev•The PHP part never gets old
    11·
    3 days ago

    Mostly it’s two things:

    1. COBOL is very good at some specific things that other languages can’t do as well. Not that other languages do them badly, not at all, but COBOL is absurdly efficient for certain operations. You need to do basic math operations on millions of rows of data every minute? COBOL can do that easily. Many other languages can get close to that speed - maybe a few seconds off - but COBOL is often used in environments where a hundred millisecond delay can mean everything breaks. Are there other languages which can match that speed? Absolutely. Are they any of the languages every company wants to upgrade to? No.

    2. COBOL’s best practices are sometimes the literal opposite of what every other language expects, especially when it comes to optimizing code for efficiency. You ever seen Evaluate, COBOL’s equivalent of a switch statement? Rather than being used to Evaluate a variable to check its values, its most commonly used to “EVALUATE TRUE” and then use the WHEN clauses (basically case statements) to check statements or variables that you want to be true. That can be converted to another language directly, yes, but it absolutely will not be efficient best-practices code. Most likely you’re going to need someone - not an AI, not an automated process - to do one-off rewrites to keep the code performance the same. As it is I have never seen any automated tool (LLM or otherwise) convert COBOL without falling victim to this issue.

    There’s also a third issue in that COBOL has some specific minor capabilities that other languages just do NOT, or not to the level of flexibility and efficiency COBOL has. The most common one is COBOL’s “88” picture type (variable) definitions. Think of it like being able to set an automatic evaluation on a variable that returns true if the condition is met, e.g. the variable “05 WS-ERROR-STAT PIC X.” with an 88 of “88 FATAL-ERROR VALUE ‘F’.” would mean you could check “FATAL-ERROR” anywhere in your code to see if the value of WS-ERROR-STAT has been set to “F”. The thing is, this is done basically for free (resource wise) as part of allocation, and furthermore it can be used to get or set, i.e. “SET FATAL-ERROR TO TRUE” will change the value of WS-ERROR-STAT to “F”. You can also use 88s for ranges, e.g. “88 ANY-ERROR VALUES ‘F’ THRU ‘N’.”, though you can’t use them for set operations that way.

    Bottom line: there’s nothing that perfectly recreates its efficiency, the specific way it performs efficiently, and some of its more esoteric capabilities. Anything still running COBOL probably depends HEAVILY on one or all of these things.

  • Y|yukichigai@kbin.earthtoMemes@sopuli.xyz•FireWire
    1·
    26 days ago

    It was great in design but too few peripherals made use of it. The lack of input devices (e.g. mice, joystick, keyboards) meant that for most people it was far less useful than USB.

    Still pretty cool that you could (and still can) use it for networking in a pinch, not to mention the decades worth of video devices that will happily dump their contents to DV video as long as you have a FireWire port. Finding a VCR with DV output is one of the best ways to digitize old VHS recordings if you can’t set up VHS-decode.