Heh, same time as my edit. Those methods should be private (i.e. they just exist for building the deck, its the consumers responsibility to shuffle / split into multiple decks etc, as well as assigning value to each card).
So what then does 13=king get me over king=king? And does forgetting to privatise implementation details suggest that the necessary language idioms make the data structure complex in a way that is orthogonal to the real world complexity of the objects it represents, and wasn't the opportunity to avoid that complexity the advantage suggested by the author. To put it another way, private and sealed and trait don't reflect characteristics of a deck of playing cards. They are overhead from the language. It is a case where a static type system, because it is biased toward it's and strings and objects, makes it more difficult to reason about our code - leaving jokers aside, how much of the Scala code makes sense if I want to play Pinnocle versus the data approach advanced by the author? Now I'll admit that Lisp has shaped the way I see the two approaches to representing cards. and this may be why I see implementation of jokers and pinnocle as easy extensions of lists and rather more complex under an object system with static type checking. But I will point out that this model got me to thinking about card games rather than card data types pretty quickly, and card games are probably the reason we're draining the swamp.
Yep, valuation can be simply a function, but wrapping in a typeclass might work as well.
Does that 'or' method actually exist in a library somewhere or was it just for illustration?
Just for illustration. But to the author of the article's point that programming languages structure our thinking, the idea that "or" must be either in the core language or part of some library illustrates the constraints imposed on expressing our ideas absent the ability to introduce new syntax via a lisp-style macro facility. In a sense, Clojure's light weight data structures can be seen as extending up into the language.
In blackjack:
and and poker with "Dr Pepper" It is sometimes better if the data type provides abstractions over the messy details of the world rather than adding another one to it and planning for the possibility of a Joker in the deck might make sense.