My first reaction to the intial code

type Position = (Int, Int)

class Player p where
  playerPosition :: p -> Position
  playerMoveTo :: Position -> p -> p
  -- etc. and lots more

class GameState g where
  getPlayer :: (Player p) => g -> p
  getMonsterPositions :: g -> [Position]

checkForCollisions :: GameState s => s -> [Position] -> Bool
checkForCollisions s ps =
  let
    p    = getPlayer s
    pPos = playerPosition p
  in
  pPos `elem` ps

was "How is that expected to work?".

After that I though:

Now, now! This is someone writing a blog post about Haskell. surely they know Haskell (and math) better than me and I'm just overlooking something kind-of-obvious-but-also-kind-of-subtle here.

Then I took a closer look at things and my train of thought went like this:

1. getPlayer constructs a representation of the player.
2. An instance of GameState needs to be able to construct different player representations irrespective of their concrete type.
3. This can only be done if the Player class has an API versatile enough to build arbitrary valid player values using it (and something in the post's tone made me immediately think that wasn't the case).
4. In checkForCollisions, how should the compiler choose a type for p?

Then I scroll a little bellow and I see the post explains why things don't work out, comparing type classes with interfaces. I lose interest, that kind of comparison isn't helpful to me.

Now, what I gather from this experience is:

1. There exists a certain feeling associated with the experience of seeing something that looks fishy, assuming it's your own misunderstanding and, upon closer examination, being surprised that your intial gut feeling was wrong. I wonder if that has a name.

2. There are people to whom the author can offer better explanations than I can, through their expectations and familiarity with more mainstream languages. I've had similiar musings talking to people on Elm's slack, where I often either couldn't find the right words to explain something, or had trouble deciphering questions that used some JS-related terminology and ways of thinking.

In pursuing non-mainstream languages more I might've hurt my ability to communicate with most programmers. And it's not like I have an abundance of that to start with. This is likely to negatively impact my employability.

1. Being able to reason about a high level why the type class was fishy is tells very little about my practical ability. I can still spend a day trying to beat very concrete code in a functional language into submission because I struggle with structuring it, even if it's just supposed to show a ball bouncing inside a box.