|
|
|
|
|
|
by Twisol
1750 days ago
|
|
|
I agree with your overall point, but I want to dig in on this bit: > Not all functional languages have typeclasses or an alternative and convenient way to express these concepts, and in those, it's not so important to understand these notions abstractly. This is true only in an especially strict sense. Haskell's typeclasses provide two basic mechanisms: one for associating a dictionary of data with a type, and one for automatically picking / deducing such a dictionary based on a given type. Only the latter is specific to Haskell (and Scala); the first can be performed even in Java, but you have to explicitly pass the desired dictionary (called a "trait") at all call sites. [0] I legitimately use traits all the time in Java, and it even has some built-in ones, like Comparator. There's a great paper on the same fundamental technique at [1] (there called "object algebras"). [0] https://www.haskellforall.com/2012/05/scrap-your-type-classe... [1] https://www.cs.utexas.edu/~wcook/Drafts/2012/ecoop2012.pdf |
|
|
For example, Java lacks higher-kinding which is needed to define a monad abstractly. This can be got cheated around using ideas from this paper (0), but it costs a cast which the compiler cannot prove safe. This is the basis for things like the arrow library in Kotlin, which while impressive, doesn't compare to the ergonomics of Haskell and still misses a bunch of standard abstractions such as Traversable, which are part of the mentioned infrastructure that makes monads (1) so useful to Haskellers.
[0] https://ocamllabs.io/higher/lightweight-higher-kinded-polymo...
[1] applicative functors more generally.