• expr ( expr@programming.dev ) 
      link
      fedilink
      arrow-up
      5
      ·
      1 year ago

      FP has been around a long time, and yes, it is outright better than OOP. Sorry. I write Haskell professionally, and never have I ever felt like something would be easier done in an OOP language. Quite the opposite.

      Unrestricted mutation makes programming really hard, and OOP and mutability go hand-in-hand. If you try to make immutable objects, then you’re just doing FP with worse ergonomics.

        • expr ( expr@programming.dev ) 
          link
          fedilink
          arrow-up
          7
          ·
          1 year ago

          I mean, I have an OOP background. I found FP as a result of my dissatisfaction with OOP. In fact, I used to teach OOP languages to new students and saw the same mistakes over and over again, mistakes that are simply not possible in FP. It’s a very similar story for everyone I work with, too. We all had jobs in various OOP languages before we managed to get jobs writing Haskell.

          Oh, and I’m currently teaching Haskell to someone at work who has a CS degree and has only done OOP languages (and C), and while it’s different than what he’s used to, he’s still picking it up very quickly (working towards making him a junior engineer, which I think shouldn’t take too much longer). In fact, just the other day we pair programmed on a bug ticket I have and he was not only following along with the code, he spotted issues I hadn’t seen yet. Part of it is certainly that’s he smart (which is why I’m doing this in the first place), but part of it is also that, with a bit of familiarity, FP languages are incredibly easy to read and follow. The primary difference is that FP does everything explicitly, whereas OOP encourages a lot of implicit (and hidden) behavior. When you organize code around functions, there’s necessarily more explicit arguments and explicit return values, which makes it far, far easier to follow the flow of logic of code (and test!). Recently I was trying to read through our Kotlin codebase at work (for our Android app), and it was so much harder because so much is implicit.

    • drosophila ( drosophila@lemmy.blahaj.zone ) 
      link
      fedilink
      English
      arrow-up
      2
      ·
      edit-2
      1 year ago

      It’s a tool, useful in some contexts and not useful in others.

      In my opinion this is a thought terminating cliche in programming and the IT industry in general. It can be, and is, said in response to any sentiment about any thing.

      Now, saying what sort of context you think something should or should not be used in, and what qualities of that thing make it desirable/undesirable in that context, could lead to fruitful discussion. But just “use the right tool for the right job” doesn’t contribute anything.

  • It’d be fun to talk shop with the fast code in slow languages folks. I do that for a living. I remember three ways, but I’m sure there’s more:

    • “Just use a better data structure”
    • “My language is a DSL for a faster language” (Polars, Numpy, etc)
    • “My compiler is surprisingly good if I’m careful” (Julia, JVM, etc)