4 ms·

I have recently given a talk that includes a comparison between OOP and parametric / higher-kinded polymorphism, the hope being to help people choose the proper

I have recently given a talk that includes a comparison between OOP and parametric / higher-kinded polymorphism, the hope being to help people choose the proper abstractions in a hybrid language like Scala. Title is "Functional Programming Inception", slides available at: https://alexn.org/blog/2017/03/15/fp-inception.html https://alexn.org/blog/2017/03/15/fp-inception.html Basically: - OOP is about information hiding and not just when speaking of data, but also when speaking of types, so OOP is about hiding information at the type level. Thus OOP is also really good at heterogeneity, Liskov substitution principle and all that - Parametric polymorphism is compile time, nothing gets deferred, types are very explicit and higher kinded polymorphism is about composition, with plugged-in types altering the capabilities of built instances dramatically ... in other words, it's a very different beast In regards to F#, the problem is that in absence of OCaml functors and Haskell type-classes, plus due to lacking higher-kinded types, you're left with OOP for building abstractions. And in terms of OOP, without interfaces that can have default implementations or higher kinded types for that matter, it's not that good as an OOP language either.

Tarean 10y ago
An insight I found quite interesting: oo style is great at extending types. You can add a subtype at a later date without modifying existing code and it just works. Functional style is great at extending behavior. You can take an existing type and implement new functions on it. This means you can have a lot of functions defined on a basic data type which is amazing for composition but you can't add a new type that works with the same methods if you didn't anticipate this need.
- bad_user 10y ago
  "Function style" can also be OOP, FP being imo orthogonal, although it is true that in practice, with FP, polymorphism is usually achieved with parametric polymorphism because they play well together. Speaking of parametric polymorphism, the need to modify a type's behaviour by implementing a new type is alleviated if you go with higher-kinded polymorphism, where the implementation bits are abstracted by a generic F[_] type and using type classes to go along with that. In the example I'm giving in that presentation, I'm implementing a type named Iterant, for which the plugged-in F[_] can dramatically modify its behaviour. So in practice you don't need to implement a new kind of Iterant, which wouldn't make much sense anyway, you only need to implement a new F[_], which is used to abstract away the details of how Iterant gets evaluated, which is the part that people want to change. Unfortunately most statically typed mainstream languages are not capable of expressing such abstractions due to lack of higher kinded types, or ways to encode / express type-classes, although this part is less problematic than lack of HKTs.
- tjalfi 10y ago
  This is called the expression problem. http://homepages.inf.ed.ac.uk/wadler/papers/expression/expression.txt http://homepages.inf.ed.ac.uk/wadler/papers/expression/expre... http://stackoverflow.com/a/2079678 http://stackoverflow.com/a/2079678 is a great SO answer on this topic.
  - pron 10y ago
    The expression problem has a complete and rather elegant solution in mainstream OO languages with generics, invented in 2012 called object algebras: Video: https://www.infoq.com/presentations/object-algebras https://www.infoq.com/presentations/object-algebras Paper: https://www.cs.utexas.edu/~wcook/Drafts/2012/ecoop2012.pdf https://www.cs.utexas.edu/~wcook/Drafts/2012/ecoop2012.pdf I understand that there is a comparable solution in FP languages called finally tagless interpreters: https://oleksandrmanzyuk.wordpress.com/2014/06/18/from-object-algebras-to-finally-tagless-interpreters-2/ https://oleksandrmanzyuk.wordpress.com/2014/06/18/from-objec...
    - kvb 10y ago
      Vesa Karvonen posted a complete solution in SML here[1] (but LtU seems to be down so the link doesn't work), which I transliterated (directly, not idiomatically) to F# here[2]. [1] http://lambda-the-ultimate.org/node/2232#comment-31278 http://lambda-the-ultimate.org/node/2232#comment-31278 [2] http://fssnip.net/gn http://fssnip.net/gn

Tarean 10y ago

An insight I found quite interesting: oo style is great at extending types. You can add a subtype at a later date without modifying existing code and it just works. Functional style is great at extending behavior. You can take an existing type and implement new functions on it. This means you can have a lot of functions defined on a basic data type which is amazing for composition but you can't add a new type that works with the same methods if you didn't anticipate this need.

bad_user 10y ago
"Function style" can also be OOP, FP being imo orthogonal, although it is true that in practice, with FP, polymorphism is usually achieved with parametric polymorphism because they play well together. Speaking of parametric polymorphism, the need to modify a type's behaviour by implementing a new type is alleviated if you go with higher-kinded polymorphism, where the implementation bits are abstracted by a generic F[_] type and using type classes to go along with that. In the example I'm giving in that presentation, I'm implementing a type named Iterant, for which the plugged-in F[_] can dramatically modify its behaviour. So in practice you don't need to implement a new kind of Iterant, which wouldn't make much sense anyway, you only need to implement a new F[_], which is used to abstract away the details of how Iterant gets evaluated, which is the part that people want to change. Unfortunately most statically typed mainstream languages are not capable of expressing such abstractions due to lack of higher kinded types, or ways to encode / express type-classes, although this part is less problematic than lack of HKTs.
tjalfi 10y ago
This is called the expression problem. http://homepages.inf.ed.ac.uk/wadler/papers/expression/expression.txt http://homepages.inf.ed.ac.uk/wadler/papers/expression/expre... http://stackoverflow.com/a/2079678 http://stackoverflow.com/a/2079678 is a great SO answer on this topic.
- pron 10y ago
  The expression problem has a complete and rather elegant solution in mainstream OO languages with generics, invented in 2012 called object algebras: Video: https://www.infoq.com/presentations/object-algebras https://www.infoq.com/presentations/object-algebras Paper: https://www.cs.utexas.edu/~wcook/Drafts/2012/ecoop2012.pdf https://www.cs.utexas.edu/~wcook/Drafts/2012/ecoop2012.pdf I understand that there is a comparable solution in FP languages called finally tagless interpreters: https://oleksandrmanzyuk.wordpress.com/2014/06/18/from-object-algebras-to-finally-tagless-interpreters-2/ https://oleksandrmanzyuk.wordpress.com/2014/06/18/from-objec...
  - kvb 10y ago
    Vesa Karvonen posted a complete solution in SML here[1] (but LtU seems to be down so the link doesn't work), which I transliterated (directly, not idiomatically) to F# here[2]. [1] http://lambda-the-ultimate.org/node/2232#comment-31278 http://lambda-the-ultimate.org/node/2232#comment-31278 [2] http://fssnip.net/gn http://fssnip.net/gn