• j_z@feddit.nu
    link
    fedilink
    arrow-up
    3
    ·
    2 hours ago

    Is it a dig against C# only being good when using it from F#, i.e. OCaml for .Net or am I overthinking this?

  • Kangae_Hishiryo@scribe.disroot.org
    link
    fedilink
    arrow-up
    3
    ·
    5 hours ago

    In Horse64:

    import horses from horses.horse64.org
    
    func main {
        var my_horse = horses.Horse(color="brown")
    }
    

    And in Horse64 Root:

    import horses from horses.horse64.org
    
    func main -> bool {
        var my_horse <- horses.Horse
        my_horse.init("brown")
        if failed(my_horse.init) {
            return no
        }
    
        defer my_horse.destroy()
    
        my_horse.run()
        if failed(my_horse.run) {
            my_horse.stop()
            return no
        }
    
        my_horse.stop()
        if failed(my_horse.stop) {
            return no
        }
    
        my_horse.eat("hay")
        if failed(my_horse.eat) {
            return no
        }
    
        return yes
    }
    
  • dasrael@lemmy.zip
    link
    fedilink
    arrow-up
    7
    ·
    8 hours ago

    This is no time for joking around…I just wanna know if I can turn my webserver back on yet?! Hello?!? Anyone?!

    • NotAnOtter@lemmus.org
      link
      fedilink
      English
      arrow-up
      11
      ·
      edit-2
      7 hours ago

      If you keep it off, it’s significantly harder to get hacked.

      Until your hosting service gets pwned…

  • tetris11@feddit.uk
    link
    fedilink
    English
    arrow-up
    9
    ·
    edit-2
    11 hours ago

    The Fixed Point Expression / Y Combinator expressed in horses:

        Y = (λ f. (λ x. f(xx))(λ x. f(xx)))
        ;; so then, give Y a horse argument with apple parameters:
        Y🐎️ = (λ f. (λ 🍎.  f(🍎🍎)) (λ 🍎. f(🍎🍎))) 🐎️   ;; [1]
            =       (λ 🍎. 🐎️(🍎🍎)) (λ 🍎. 🐎️(🍎🍎))      ;; [2]
            = 🐎️(   (λ 🍎. 🐎️(🍎🍎)) (λ 🍎. 🐎️(🍎🍎))   )  ;; [3]
            = 🐎️(Y🐎️)                                       ;; [4]
    
    Explanation
    • 1: x is 🍎, but could be anything. It’s just a function parameter nested within another.
    • 2: λf gets executed and vanishes from the left, substituting f internally with 🐎️. This is now a new function, with left group as the function body, and right group as the function argument, despite being identical.
    • 3: λ🍎 gets executed and vanishes from the left, substituting 🍎 with (λ 🍎. 🐎️(🍎🍎))
    • 4: Everything within the main brackets at [3] has been seen before at [1], but with f being 🐎. Thus we have bred a new horse. We can breed infinite horses this way
  • Y|yukichigai@kbin.earth
    link
    fedilink
    arrow-up
    112
    ·
    20 hours ago

    When I first saw this comic I was a relatively new COBOL programmer. It felt accurate.

    I am now my employer’s senior COBOL dev. It still feels accurate.

    • Madagaskar_sky@lemmy.world
      link
      fedilink
      arrow-up
      16
      ·
      13 hours ago

      What’s the biggest hurdle to porting old systems written in COBOL to newer languages? Besides the glaring conflict of interest for you.

      • Y|yukichigai@kbin.earth
        link
        fedilink
        arrow-up
        5
        ·
        5 hours 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.

      • WhyJiffie@sh.itjust.works
        link
        fedilink
        English
        arrow-up
        5
        ·
        7 hours ago

        the cobol system was already tested for years or decades, important bugs are already fixed, it’s other quirks have became part of the workflow for people using it, and for other systems interacting with it, some of them likely also cobol. if you write a new system, it has to work the exact same way. same features, same bugs, same everything. but realistically it will have brand new bugs, it will miss some functions and do some others differently enough that it sometimes causes problems, and nobody knows why.

      • Fmstrat@lemmy.world
        link
        fedilink
        arrow-up
        39
        ·
        13 hours ago

        Hahaha port. Get a load of this person thinking COBOL is being ported! I bet they like the number 4.

      • Lyrl@lemmy.dbzer0.com
        link
        fedilink
        arrow-up
        19
        ·
        12 hours ago

        I think just the size of the projects. My employer has had a team of ten-ish people working full time on porting a piece of our COBOL program (the full thing was deemed not possible to port to a single modern application, so it’s getting split up) for about a year now. I was peripherally involved in four rounds of increasingly integrated testing environments. Go live was yesterday. They rolled it back three hours in.

        It’s hard for a company to invest multiple people’s salaries for many years on reworking software that currently mostly works.

  • OwOarchist@pawb.social
    link
    fedilink
    English
    arrow-up
    64
    arrow-down
    2
    ·
    19 hours ago

    Needs a python horse in there.

    Probably something about “why build a horse when you can just import horse from field?”