eed3si9n

Thanks for the detailed response and concrete examples!

Reading signatures is one thing (and zip is "easy"), but without examples it doesn't really help in most of the cases. Because even if I know the concept, I don't know when it comes handy. (For example I just looked at Forall ( https://static.javadoc.io/org.scalaz/scalaz_2.12/7.2.24/scalaz/Forall.html ... Forall is an endofunctor in an endofunctor category ... ah yes!), and then there are tools that come with labels (DList's doc page: nice for append heavy workloads, eg. logging; yes, great, what's Forall good for? What's Strong? Why Alpha exists? What's =>: ? That's not even documented :( It cannot be searched for https://github.com/scalaz/scalaz/search?utf8=%E2%9C%93&q=%3D%3E%3A&type= ... It's not on the cheatsheet http://eed3si9n.com/scalaz-cheat-sheet .. .I mean it's on it, but it is only used, not defined. etc.)

That's not a type reading thing. That's the bad documentation, and the learner-unfriendly naming convention.

I think it would be great if we could replace implicits by:

1) a simple mechanism for "enrichment" (aka. retro-active extension, virtual classes)

2) functional type-level computation (as opposed to the mini-prolog engine that is implicit search + type inference).

Reducing complexity is complicated, unfortunately. We [have been|are] thinking about both of these alternative features, though.

---

ps: The following part of the article is inaccurate: "Turns out that Scala will search up to one level up the type hierarchy for a matching shape for the implicit."

Check out the "implicits without the import tax" part of http://eed3si9n.com/implicit-parameter-precedence-again. The implicit scope includes all the superclasses (and their companion objects) of all the parts of the type of the implicit value that's being resolved.

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-overview%3A-shapeless-2.0.0

2 - http://milessabin.com/blog/2011/12/19/shapeless-preview/

3 - http://eed3si9n.com/learning-scalaz/

4 - http://eed3si9n.com/learning-scalaz/Isomorphisms.html

The thing with Scala is it depends on the pattern you want to use. I am a big advocate of it, and the function pattern being used fully with something like Cats or ZIO. However I would not suggest starting there.

I would start by playing about with the syntax and writing standard OOP code, as its probably what you're most familiar with.

When you want to dive into the power of FP then I recommend http://eed3si9n.com/herding-cats/. Its basically a companion to the Haskell book 'Learn you a haskell' (http://learnyouahaskell.com/) that takes the theory coming up in that book and translates it to Scala. I found it the most direct explanation of the different types and theories (Monads, Functors, Applicative, etc).

There is an awesome book called "Functional Programming in Scala" that has a lot of great questions to work along to, and is great for somebody interested in both Haskell and Scala but doesn't assume prior experience with things like combinators and monads. If you are pretty far down the Haskell route and want to learn about one of the more advanced type-level libraries, You may want to jump into http://eed3si9n.com/learning-scalaz/ and use https://twitter.github.io/scala_school/ as a quick reference or intro. If you have the time and desire, a lot of people swear by a cover-to-cover reading of Odersky's "Programming in Scala".

If I understood John's motivation from the video, it's that this enables the Flatten structure to be inspectable, because the innards are not hidden behind an opaque closure (A => F[B]), as is the case in regular Monad.

Btw, this is a problem that the "Selective applicative functor" too aims to alleviate.

You can read more about the inspectability problem (and Selective) at http://eed3si9n.com/selective-functor-in-sbt

The context there is sbt, which is a build tool, but I'm sure the inspectability plays role in many other areas. Note, how he contrasts "Applicative composition" and "Monadic composition".