
Type classes and generic derivation - lelf
https://meta.plasm.us/posts/2015/11/08/type-classes-and-generic-derivation/
======
AdieuToLogic
Travis Brown has written up some great articles on advanced Scala topics and
this one does not disappoint. Well done and worth the read.

Some may find the Shapeless feature overview[1] a good read as well. And for
people interested in history, I found Mr. Sabin's announcement of Shapeless[2]
to be both interesting and valuable for its links related to higher-kinded
programming topics.

I also found "learning Scalaz"[3] a very good read, with the page discussing
Isomorphisms[4] relevant to Mr. Brown's article.

1 - [https://github.com/milessabin/shapeless/wiki/Feature-
overvie...](https://github.com/milessabin/shapeless/wiki/Feature-
overview%3A-shapeless-2.0.0)

2 - [http://milessabin.com/blog/2011/12/19/shapeless-
preview/](http://milessabin.com/blog/2011/12/19/shapeless-preview/)

3 - [http://eed3si9n.com/learning-scalaz/](http://eed3si9n.com/learning-
scalaz/)

4 - [http://eed3si9n.com/learning-
scalaz/Isomorphisms.html](http://eed3si9n.com/learning-
scalaz/Isomorphisms.html)

------
acjohnson55
This is a really awesome post for demystifying typeclasses -- which are
incredibly useful -- as well as some of the really basic stuff you can do with
Shapeless-style type-level programming. The play-json library is how I first
started messing with this stuff, but the circe library the author wrote seems
to take this to another level. The latter not only seems conceptually and
functionally simpler, but is more powerful, given its direct support for
sealed trait hierarchies, a core feature of Scala. And it seems to do so in a
pretty intuitive way, representing a subtype as a JSON object with the subtype
name as the key and a subobject as the value set, as opposed to synthesizing a
`type` field of some sort to disambiguate the cases.

My biggest complaint is with some of Scala's ergonomics for working on the
type level. I'd argue that built-in tuples should simply support the HList
operations natively, which seems like it could save on a whole lot of complex
looking type-level code. I'm right with the author until `hconsParser` and
especially `caseClassParser` started bending my brain. But I guess the good
news is that those only need to be written once.

------
malcolmgreaves
Wow! This is an excellent post that really showcases the elegance and
expressiveness of a functional programming approach. I personally stumbled
upon type classes a few months ago. The pattern upended my style of thinking;
definitely greatful for that!

I really love how this concept keeps a clean separation between data and
functionality. It lends itself to programs that have clear semantics. And
makes extending them quite straightforward.

Overall great post Travis!

