1. 7

Author makes a brief case that both functional and object oriented have domains of application and shoe-horning one into the other leads to ugly code.


  2. 19

    This piece is dumb, and I should probably have just flagged it, hid it, and moved on, but I can’t bear the idea that people would read this and think they’ve learned something about Haskell.

    First of all, there are well-known deficiencies when it comes to records in Haskell–there’s been enough written about it, the author could certainly have done the tiniest bit of Googling before writing this.

    Secondly, even considering the issues with records in Haskell, you can just write

    import Lens.Micro.Platform
    -- or import Control.Lens if you're not into the whole brevity thing
    data Person = { _personName :: String }
    data Pet = { _petName :: String }
    makeFields ''Person
    makeFields ''Pet

    …and all those Has-instances are generated for you. You’re done and can do stuff like view name (Pet "Spot") or view name (Person "Barbara") or (Pet "Spot") ^. name if you’re a fan of lens operators…etc. And this doesn’t even scratch the surface of what is possible in Haskell with records, and let’s not forget the amazing shit that is also possible like https://lobste.rs/s/kuuqh5/higher_kinded_data.

    Holy fuck! Who the hell does this?

    Nobody! Do more research before writing posts like this, please.

    1. 8

      In haskell, we cannot say that a Person has a name and a PetAnimal has a name

      I haven’t actually tried it, but I thought this was possible already in ghc 8:

      I’ve found annoyances with Haskell, but maybe I have no sense of aesthetics or something because the records never bugged me. I much prefer Haskell records to C++ fields, where I have to deal with public/private/protected/const/static/immutable-unless-there’s-a-bug etc.

      1. 6

        You can do it in Haskell98 if you use typeclasses instead of record syntax.

      2. 6

        We are not bound to one or the other. But the programming languages which we use bind us to one, arguing that the other is ugly.

        I wonder if the author here is being willfully oblivious to the existence of multi-paradigm languages. Picking Haskell to argue that a functional language creates ugly code when one needs a more OOP approach seems to me like pure laziness. I think he should’ve at least used another language which isn’t purely functional, but also not historically OO.

        1. 5

          I am not a Haskell programmer but I did not find the Haskell version ugly. F# gives you functional programming and classes.