News for hackers. Stuff that matters.
Re:Object Oriented Programming is Inherently Harmful by Ixiaus on Sunday November 30, 2014 @11:55AM (#8677244)
He means pattern matching functions, which are idiomatic in Erlang but "dirty" in Haskell (where you would want to solve it better with a type class, or something else more general).

Erlang

    myfun({duck, "My Duck's Name"}) ->
        dosomething;
    myfun({dog,  "My Dog's Name"})  ->
        dosomething;
    myfun({cat,  "My Cat's Name"})  ->
        dosomething.
Erlang also has arity matching (this function is different than the one above it):

    myfun({cat,  "My Cat's Name"}, cage) ->
        dosomething. 
Case statements are one way of doing that but those are considered a messy style in Erlang because they end up nesting so deeply - keeping it all out in small little functions and using pattern and arity matching is the "right" way.

You can do the same (except for arity matching) in Haskell with function arg pattern matching and Haskell also has some very nice projection tools for it too:

Haskell

    newtype Name = Name { unwrapName :: String }
    data Animal = Cat | Dog | Duck deriving (Eq, Show, Ord)

    myfun :: Maybe Animal -> Name -> String
    myfun (Just a) (unwrapName -> name) = (show a) ++ "'s name is: " ++ name
    myfun Nothing _                     = "No animal given!"

    > let n = Name "Fido"
    > myfun (Maybe Cat) n
    > "Cat's name is: Fido"
    >
    > myfun Nothing n
    > "No animal given!"
There are many problems with that function and I could probably eliminate the multiple function clauses and reduce it to one clause by getting rid of the pattern matching and using the maybe function:

    myfun :: Maybe Animal -> Name -> String
    myfun a (unwrapName -> n) = maybe default formatAnimal a
      where
        default = "No animal given!"
        formatAnimal t = printf "%s's name is: %s" (show t) n
That would be the more idiomatic way I would do it - pattern matching isn't "bad" in Haskell and you'll see it used quite often in utilities and libraries. It's considered good form to move stuff like that into a utility and give it a clear name (like the maybe function above that takes our formatAnimal function) then use that in your application code so it becomes obvious what's going on.

Pattern matching, deeply nested ifs and cases, etc... are somewhat hard to parse for the eye.

Re:Object Oriented Programming is Inherently Harmful by codygman on Sunday November 30, 2014 @01:51PM (#8677632)
What is concept is the:

    newtype Name = Name { unwrapName :: String }
   (unwrapName -> name)
I'm not familiar with this, are you pattern matching on a function type?
Re:Object Oriented Programming is Inherently Harmful by dezgeg on Sunday November 30, 2014 @02:50PM (#8677838)
It's the View Patterns extension: https://ghc.haskell.org/trac/ghc/wiki/ViewPatterns
Re:Object Oriented Programming is Inherently Harmful by thisjepisje on Sunday November 30, 2014 @12:23PM (#8677336)
Just getting into Erlang right now, this is very helpful.