> Imagine a program which begins by asking, "Which game do you want to play?" and includes a card guessing game, blackjack, Uno!, go fish, and crazy eights. We want the values of the cards to lie in their use within each game, not where we shuffle and deal and discard from hands.
I maintain that you gain nothing (except the possibility of errors) by representing the cards as int-or-string here. Think about how you'd actually use the cards in implementing those games. With my enum-like scala representation you could do anything you could do with the clojure version, and you'd get the advantage of e.g. compiler warnings if you defined incomplete match/case statements.
The author's point isn't that int-or-string is a good choice, it's that there are a lot of choices and none of them allow natural abstraction over a deck of cards, the static typing encourages the abstraction down to a lower level - like ints or into a mashup like string-or-int.
And this is the really important point, this pushing the abstraction down to a lower level causes it to leak into the implementation of card games in ways that make the card games themselves harder to reason about.
Decks of cards have Kings, not 13's, and using 13 to represent the King is of type leaky abstraction. It's a muddy road leading into the swamp.
When I implement blackjack I get to write little balls of mud:
If card = 13 then 10
And in my card guessing game
If card = 13 and guess = King then "Yes, the card is a King!"
All that for a warning when I don't have a card 7, which is going to make Pinochle have to work around the abstraction - probably by bypassing the entire implementation when it chokes on two Jacks of Diamonds etc. in a deck.
I said the enum-style approach is what you want for something like that. "case KING | QUEEN | JACK | TEN => 10; case ValueCard(x) => x" is just as readable as anything you'd do in clojure, and the warning (not error - you can ignore it if your game really doesn't need to handle that card) if you forgot one is valuable.
The enum is a bad abstraction because when I play GoFish, the computer asks, "Do you have any 13's?" and when I ask, "Do you have any Jacks?", I am always told to GoFish. It's an abstraction that sometimes returns a meaningful value, and other times doesn't, and the abstraction is built to optimize exactly the cases that are easy for me to reason about when writing a program and returns something that only looks correct in all the difficult cases, such as the Ace and so I wind up having to do all the heavy lifting myself anyway but only after having been misled to the wrong assumption that the abstraction was robust and well thought out.
There's no value to a warning that's irrelevant and perhaps even negative value if it encourages the idea of adding a wildcard last case just so I don't have it interrupting my thoughts each and every time I build my program since doing so opens the door to very run time errors it was supposed to prevent or conversely creates the habit of ignoring the compiler warnings in the very worst situation - when I think I know what I am doing.
If enums were good enough and I wanted to ignore compiler warnings, I could have used C.
> The enum is a bad abstraction because when I play GoFish, the computer asks, "Do you have any 13's?" and when I ask, "Do you have any Jacks?", I am always told to GoFish.
What? No it doesn't. Scala case objects don't have numerical values.
I am having an incredibly difficult time understanding why int-or-string cards are desirable also. You'd end up with multiple functions like heartsGameCardValue and euchreGameCardValue but with int cards you need to write the same thing and without a type system to catch errors. If it was truly simpler to reason in terms of int, you could also do a cardIntegerRepresentation function and it would add very little length to the codebase.
I maintain that you gain nothing (except the possibility of errors) by representing the cards as int-or-string here. Think about how you'd actually use the cards in implementing those games. With my enum-like scala representation you could do anything you could do with the clojure version, and you'd get the advantage of e.g. compiler warnings if you defined incomplete match/case statements.