Learn You a Haskell for Great Good (2008)

Heh it's not your fault, my ire/confusion was directed at the article not at you. This is all subjective anyway and as a sister comment indicates I may have been unique in my feelings towards it

I think you are exaggerating somewhat, I was just saying I didn't like it and even caveated that this could be just me being oversensitive.

However if you can't see why someone may feel a bit weird reading "You'd be there, banging away at your regular girl" then I'm not sure what I can say. It's not rolling-in-the-aisles piety, it's just that our community already has a bad image and stuff like this isn't helping.

The point, I think, is that the original description leaves out the easiest monads, which makes learning about them a lot more difficult. See: List, Maybe, etc.

>You realise that this is the most useless description ever?

Which is perhaps why many people have a hard time understanding it. That is, however, the true definition.

>Why's it a good abstraction for doing <X>

That depends on <X>. I can't answer that question unless you tell me what <X> is.

> If it abstracts over a gazillion different things, why not have special-purpose abstractions like other languages (and thus probably make the language a lot simpler to use)?

Why would a special-purpose abstraction be easier to use? If you only understand monads in terms of state, you can just use them that way.

I feel like you're trying to be a dick. Since you're doing this, could you explain why? I'm super curious.

Because for most of the cases people really care about, it's easier for you to change your language then it is for every offended person to not feel upset when you offend them.

This might not be the case if there's a downside to the alternative language, or if the feeling of offense is unreasonable, but this is a decision you should actively make, not passively dismiss as "not my problem".

In this case, I think the language could easily have been changed without significantly weakening the text.

That's a pretty common feeling, and one that I certainly had as I entered college. What finally changed my mind was four years of gender studies classes.

So let me do my best to provide something of an explanation. It isn't really a problem that there's one tutorial or one website that pokes fun at weight issues or assumes it is serving a primarily male audience. The problem comes when those tropes become universal, or at least fairly wide-spread.

Sexual harassment might be a good place to look for examples. A single sexual comment or a single locker-room butt-tap, in most cases, is not that big a deal. But these small acts don't happen in isolation! They happen in a context that has structurally disadvantaged[1] entire classes of individuals (predominately women, in this case). And no, these acts are not the only thing that created such a structure, but they work to make individuals in those classes feel uncomfortable, threatened, and generally unsafe. That's why you'll often hear such acts called "micro-oppressions." And they don't just make their victims feel bad. They also teach the privileged class that the victims belong to a class that it is OK to denigrate. No, not on their own, not in isolation, but in combination and spread over enough time.

As an upper-middle class, cis white male who dates women, I didn't really buy this argument until I had a very particular experience. I was at my university's gym using a cardio machine, and some very muscular athletes were lifting weights behind me. I had forgotten my earbuds that day, so I could hear what they were saying. Mostly, they talked about women and parties. But eventually, they started talking about how all the "non-athletes" on campus really hurt the aesthetics of the place. "Especially those CS majors with their screen-tans," I recall one saying. This turned into a myriad of jokes that I felt were absolutely directed at me personally. They commented how "tech types" only show up to the gym to do cardio and always wear "ridiculous T-shirts with company logos on them," which, at the time, I was. I tried to ignore it, to just have "tough skin," but as they kept talking it slowly wore me down. I left, took a shower, and headed to the computer lab and had a great conversation about Golang.

Now imagine you didn't have a computer lab to go to. That no matter where you went, you had to hear those comments and those jokes. Every time you went to work, you'd hear it from your boss. Every time you turned on the TV, you'd see it in ads and in sitcoms. On billboards, on the street, in movies, and even in programming language tutorials.

Further, imagine that if you were to ever speak up and talked about what was making you uncomfortable, you'd be told to "grow tougher skin" or "just learn to take a joke". Personally, I can't even imagine what it must be like to live life as one of the classes that America structurally oppresses. But I feel like it must suck. A lot.

So what can we do? Well, we start shifting the culture. We start creating safe spaces. We hold people accountable for their comments and jokes while understanding that they didn't mean any harm. We educate and explain.

But most importantly, and I cannot stress this enough, we need to listen. We need to listen to people when they tell us that we are doing something that bothers them. We need to understand how our actions transform spaces that we love -- like functional programming -- into hostile areas for so many people. Because honestly, if we don't listen, we won't know. The author of LYAH isn't a bad person. Those athletes weren't bad people. No one does this sort of thing intentionally.

Yet we have to take responsibility. We have to learn, we have to get better. And the only way to start doing that is to make everyone's sensitivities our problem.

edit -- Perhaps I'm wrong. I'm open to that possibility. I'm the product of a very liberal gender studies education from a university in Arizona, where there were plenty of examples of undeniable xenophobia and homophobia. After all, if the sum of our experiences doesn't fully constitute us, it certainly plays a big role.

[1] It is very difficult to argue that this isn't the case, considering the wealth disparity amongst men and women, especially in the tech industry. If you've got yourself deeply rooted in some sort of MRA thing, then just think about race instead. Wealth disparity between white and black men is pretty wide.

Its never been possible to be humorous without content that would alienate someone; nowadays, its just that communication is more ubiquitous so you're more likely to reach that person and hear back from them.

If we're talking about motives and proof, then The fact that you understand what you said is harmful and you choose to do it anyway is the legal definition of intent.

> Non-exhaustive patterns error was disappointing after being told that "if it compiles it will run".

Yes, it's somewhat strange this is only a compiler warning rather than a compiler error.

> * Non-exhaustive patterns error was disappointing after being told that "if it compiles it will run". It seems to be the Haskell equivalent of NullPointerException (I'm told OCaml doesn't have this problem).

I agree that this should be an error by default, however -Wall would fix this issue for you now.

> * Installing libraries is slow

It is slow, but can be made much faster by using "cabal install -j${num_cpu_cores}". I also use -O0 to disable optimizations during development.

There is also Halcyon, which I believe allows you to do some caching of libraries.

A little more extreme (but complete imo) solution is to use the nix package manager or if you want to go all in, NixOS.

> * The Haskell platform is not batteries included

I keep going back and forth on how I feel about this. It's harder in the beginning because you aren't sure what to use. Once you get a feeling for what libraries are best though, it's a great advantage that those libraries move forward so quickly without being tied to GHC development practices which have to move more slowly.

> * JSON parsing seem to be more complicated than it needs to be

Really? Here is some JSON parsing code I wrote the other day[0] to show how pattern matching and exhaustiveness checks in Haskell are useful:

    {"purchaseType": "Rent","price": 0.99,"title": "inception"}

Here is an implementation in Haskell:

    {-# LANGUAGE DeriveGeneric #-}
    {-# LANGUAGE OverloadedStrings #-}
    
    import Data.Aeson
    import GHC.Generics
    import qualified Data.ByteString.Lazy as BL
    
    data PurchaseType = Free | Rent | Buy | Subscriber deriving (Show, Generic)
    instance FromJSON PurchaseType
    instance ToJSON PurchaseType
    
    data Media = Media { title :: String, price :: Float, purchaseType :: PurchaseType} deriving (Show, Generic)
    
    instance FromJSON Media
    instance ToJSON Media
    
    jsonData = "{\"title\": \"inception\", \"price\": 0.99, \"purchaseType\": \"Rent\"}"
   
    main = print $ (decode jsonData :: Maybe Media)
    -- running main gets:
    -- λ> main
    -- Just (Media {title = "inception", price = 0.99, purchaseType = Rent})

> * Also got confused by keywords naming: https://news.ycombinator.com/item?id=5689951

Those are just things you have to get used to and imo don't really seem like a big deal. Every language has these kinds of things, but Haskell has less than most. To qualify that last statement, once you've learned their very different set of abstractions you know everything you need to know. It is less work in general dealing with programmer defined abstractions built on top of functor, monoid, etc because those custom abstractions more closely resemble them, which is an effect of them having to follow laws.

> * I found Yesod API to be inelegant. I found it odd that it needs so many non-standard compiler extensions, which might be a sign that the language is not expressive enough.

Looking at a Yesod example[1], the most language extensions I saw were:

    {-# LANGUAGE MultiParamTypeClasses #-}
    {-# LANGUAGE OverloadedStrings #-}
    {-# LANGUAGE TemplateHaskell #-}
    {-# LANGUAGE TypeFamilies #-}

TemplateHaskell and OverloadedStrings are both just conveniences, I suppose there could be an argument that MutliParamTypeClasses and TypeFamilies mean the language is not expressive enough. One of the reasons for use of language extensions so much in Haskell is that it is designed by committee, it's quite possible that other languages might have already deprecated these language extensions and moved them into the core language.

> * One-letter variables seem to be idiomatic. This is unappealing to me because I try to make my code readable.

The only place I usually see one letter variable names is where it's quite obvious what they are. I don't think anyone would argue it's better to use something besides x and y in this function definition for instance:

    add x y = x + y

To check out your claims, let's grab a few random snippets of code (I'm hitting the spacebar randomly then choosing first function I see) from the most popular[2] Haskell libraries:

containers[3]:

    isSubmapOf :: (Ord k,Eq a) => Map k a -> Map k a -> Bool
    isSubmapOf m1 m2 = isSubmapOfBy (==) m1 m2

bytestring[4]:

    -- | Add a list of non-negative numbers.  Errors out on overflow.
    checkedSum :: String -> [Int] -> Int
    checkedSum fun = go 0
      where go !a (x:xs)
                | ax >= 0   = go ax xs
                | otherwise = overflowError fun
              where ax = a + x
    go a  _         = a

directory[5]:

    setOwnerReadable :: Bool -> Permissions -> Permissions
    setOwnerReadable b p = p { readable = b }

What I personally take from above is that while Haskell does use single letter variables, the types make it obvious what those variables are. As a test, I'll go to the next popular library and look for a longer function to see if this line of thought breaks down.

text[6]:

    fromString :: String -> Builder
    fromString str = Builder $ \k (Buffer p0 o0 u0 l0) ->
        let loop !marr !o !u !l [] = k (Buffer marr o u l)
            loop marr o u l s@(c:cs)
                | l <= 1 = do
                    arr <- A.unsafeFreeze marr
                    let !t = Text arr o u
                    marr' <- A.new chunkSize
                    ts <- inlineInterleaveST (loop marr' 0 0 chunkSize s)
                    return $ t : ts
                | otherwise = do
                    n <- unsafeWrite marr (o+u) c
                    loop marr o (u+n) (l-n) cs
        in loop p0 o0 u0 l0 str
      where
        chunkSize = smallChunkSize

Alright... str is obviously string, marr is mutable array.. o, u, and l... what could those be? Well it's getting set from the Buffer type, so it looks like I'll have to see what the type of that is.

    Prelude GHC.IO.Buffer> :i Buffer
    type role Buffer phantom
    data Buffer e
      = Buffer {bufRaw :: {-# UNPACK #-} !RawBuffer e,
                bufState :: BufferState,
                bufSize :: {-# UNPACK #-} !Int,
                bufL :: {-# UNPACK #-} !Int,
                bufR :: {-# UNPACK #-} !Int}
             -- Defined in ‘GHC.IO.Buffer’

    Prelude GHC.IO.Buffer> :t Buffer
    Buffer
      :: RawBuffer e -> BufferState -> Int -> Int -> Int -> Buffer e

I'll concede that names other than o, u, l, and k would have helped here. Perhaps even renaming ts as texts would have been more clear.

> * For the same reason, frequent use of special characters in operators (, <>, ///, etc.) in the standard library and in third-party libraries was not appealing.

"Special characters" in operators? When most people say special characters they mean unicode. <> and /// look to be normal characters to me. With that said I go back and forth between finding operators appealing/unappealing. For instance I find this to be understandable and a good choice:

    "home" </> "cody" </> "Downloads"

I also think that making users learn a few symbols isn't so bad, as long as you don't go to far. The main symbols I'd say you need to know are >>=, <$>, <>, and maybe <> and >=>. >>= doesn't have a non-symbol alternative I don't believe, <$> is fmap, <> is ap, <> is mappend, and I'm not sure if >=> has a non-symbol alternative.

> I was disappointed because I was attracted by referential integrity, strong compiler checks, pattern matching and function composition

Those are many of the reasons I was attracted to Haskell and still use it today, are you claiming Haskell doesn't have those things? If you are making that claim just because exhaustiveness checking isn't an error by default, I'd say that seems disingenious.

> but overall I was left with the impression that the Haskell environment was not very well polished from a software engineering point of view.

Was it just the above that left you with that impression, or was it other things as well? Can you give an example of a language that is well polished from a software engineering point of view and what makes it "polished"?

0: https://news.ycombinator.com/item?id=9037452

1: https://www.fpcomplete.com/school/project-templates/file-ser...

2: http://kwangyulseo.com/2014/02/03/top-30-haskell-pakcages-wi...

3: http://hackage.haskell.org/package/containers-0.5.6.3/docs/s...

4: http://hackage.haskell.org/package/bytestring-0.10.4.1/docs/...

5: http://hackage.haskell.org/package/directory-1.2.1.0/docs/sr...

6: http://hackage.haskell.org/package/text-1.2.0.4/docs/src/Dat...