4 ms·

There is a deep desire in the OO world to make custom, domain specific ontologies for every domain. The FP approach attempts to do the opposite: create as few

There is a deep desire in the OO world to make custom, domain specific ontologies for every domain. The FP approach attempts to do the opposite: create as few new names as possible (or when we do create them, they should not be exclusive unless they are truly domain specific). A modern way these meet in the middle is called "named row polymorphism" as demonstrated in PureScript. All three of these approaches have tradeoffs. It's not a very good idea to say any of them are uniquely suited even to a domain.

jcelerier 9y ago
> There is a deep desire in the OO world to make custom, domain specific ontologies for every domain. well, yes. A big selling point of OO was to allow big services company to have a crazy turnover, where everyone working on a codebase is fired and new hires can start being productive the next day on it. So everything has to be documented and named. Write the class you're assigned and don't do more ; you're just a microscopic cog in the machine.
chubot 9y ago
I think you're talking about a different issue regarding names (maybe because the original post got taken down.) I think he was just referring to lack of names in type declarations in OCaml. type expr = | Sum of (int, int) | Negation of int A sibling comment pointed out that this is now possible: type expr = | Sum of { left: expr ; right: expr } | Negation of { child: expr } The former style looks OK for this simple example, but I sympathize with the OP because "real" type declarations are more complicated, and that's where the problem with lack of names surfaces. You can imagine C WITHOUT names in structs, but WITH destructuring assignment of structs. That means you have to write the same names every time you destructure! That leads to inconsistent programs. ----- But I know what you are talking about with regard to names. I would say it is more of a Lisp approach than an FP approach in general. (There seems to be a resurgence of statically typed languages in FP in the last decade, so I distinguish them from Lisp. There is a good talk called "Observations of a Functional Programmer" which I link in this post [1], which talks about the schism.) Anyway, I have heard Rick Hickey (of Clojure) argue passionately against domain-specific ontologies, and I get his point. Another way I've heard it said is that "Java is like legos where none of the pieces fit together" (I think from Steve Yegge). Those criticisms are totally valid, but it's a different issue than the one OP was complaining about. If anything, OCaml has the same problems as Java. You need to "jump out of" the language to do metaprogramming, whereas in Lisp, metaprogramming is just programming. That is essentially what my blog post is pointing out. Thanks for the pointer on PureScript -- I will check that out. ------ Another thing I came across recently was libraries in statically typed FP languages to do simple visitor tasks, like: https://wiki.haskell.org/Scrap_your_boilerplate https://wiki.haskell.org/Scrap_your_boilerplate In Lisp this is not something "special". It doesn't require a named solution or "innovation". I don't use Lisp for other reasons, but I appreciate this aspect of it. [1] http://www.oilshell.org/blog/2016/12/05.html http://www.oilshell.org/blog/2016/12/05.html
- KirinDave 9y ago
  > I think you're talking about a different issue regarding names (maybe because the original post got taken down.) I think he was just referring to lack of names in type declarations in OCaml. type expr = | Sum of (int, int) | Negation of int A sibling comment pointed out that this is now possible: type expr = | Sum of { left: expr ; right: expr } | Negation of { child: expr } It's difficult for me to work out the specifics here, but I think my point stands. In general, you just don't add nested ontologies the way you do in the OO world. There's a lot to be said about that with lenses, but there's strong incentive in both Haskell and Ocaml to use module-level separation and minimal accessors. As for type constructors, I think this was one of Rich Hickey's complaints from his now infamous interview too, and yeah, in some cases it can be confusing. This is in the same sense that order-of-arguments for methods without required names (and tooling combinators like -> vs ->>) as well. Style problems exist with every syntax! But from my perspective, it's pretty rare to not use record syntax or lenses AND be pattern matching on very deep groups of Things In Sum Types. The incentive to not do this is very high now. My perspective is not so uncommon in the circles I run in; We Avoid Doing That Because It's Easier Not To Do It: the Musical. When folks point this out, it feels somewhat like arguing with a time traveler who hasn't really examined the state of the art and common techniques in 2017. It'd be like me demanding lambdas be added to Java or suggesting Javascript needs a better lexical scoping assignment primitive. It was a problem, but now we have new problems.

jcelerier 9y ago

> There is a deep desire in the OO world to make custom, domain specific ontologies for every domain. well, yes. A big selling point of OO was to allow big services company to have a crazy turnover, where everyone working on a codebase is fired and new hires can start being productive the next day on it. So everything has to be documented and named. Write the class you're assigned and don't do more ; you're just a microscopic cog in the machine.

chubot 9y ago

I think you're talking about a different issue regarding names (maybe because the original post got taken down.) I think he was just referring to lack of names in type declarations in OCaml. type expr = | Sum of (int, int) | Negation of int A sibling comment pointed out that this is now possible: type expr = | Sum of { left: expr ; right: expr } | Negation of { child: expr } The former style looks OK for this simple example, but I sympathize with the OP because "real" type declarations are more complicated, and that's where the problem with lack of names surfaces. You can imagine C WITHOUT names in structs, but WITH destructuring assignment of structs. That means you have to write the same names every time you destructure! That leads to inconsistent programs. ----- But I know what you are talking about with regard to names. I would say it is more of a Lisp approach than an FP approach in general. (There seems to be a resurgence of statically typed languages in FP in the last decade, so I distinguish them from Lisp. There is a good talk called "Observations of a Functional Programmer" which I link in this post [1], which talks about the schism.) Anyway, I have heard Rick Hickey (of Clojure) argue passionately against domain-specific ontologies, and I get his point. Another way I've heard it said is that "Java is like legos where none of the pieces fit together" (I think from Steve Yegge). Those criticisms are totally valid, but it's a different issue than the one OP was complaining about. If anything, OCaml has the same problems as Java. You need to "jump out of" the language to do metaprogramming, whereas in Lisp, metaprogramming is just programming. That is essentially what my blog post is pointing out. Thanks for the pointer on PureScript -- I will check that out. ------ Another thing I came across recently was libraries in statically typed FP languages to do simple visitor tasks, like: https://wiki.haskell.org/Scrap_your_boilerplate https://wiki.haskell.org/Scrap_your_boilerplate In Lisp this is not something "special". It doesn't require a named solution or "innovation". I don't use Lisp for other reasons, but I appreciate this aspect of it. [1] http://www.oilshell.org/blog/2016/12/05.html http://www.oilshell.org/blog/2016/12/05.html

KirinDave 9y ago
> I think you're talking about a different issue regarding names (maybe because the original post got taken down.) I think he was just referring to lack of names in type declarations in OCaml. type expr = | Sum of (int, int) | Negation of int A sibling comment pointed out that this is now possible: type expr = | Sum of { left: expr ; right: expr } | Negation of { child: expr } It's difficult for me to work out the specifics here, but I think my point stands. In general, you just don't add nested ontologies the way you do in the OO world. There's a lot to be said about that with lenses, but there's strong incentive in both Haskell and Ocaml to use module-level separation and minimal accessors. As for type constructors, I think this was one of Rich Hickey's complaints from his now infamous interview too, and yeah, in some cases it can be confusing. This is in the same sense that order-of-arguments for methods without required names (and tooling combinators like -> vs ->>) as well. Style problems exist with every syntax! But from my perspective, it's pretty rare to not use record syntax or lenses AND be pattern matching on very deep groups of Things In Sum Types. The incentive to not do this is very high now. My perspective is not so uncommon in the circles I run in; We Avoid Doing That Because It's Easier Not To Do It: the Musical. When folks point this out, it feels somewhat like arguing with a time traveler who hasn't really examined the state of the art and common techniques in 2017. It'd be like me demanding lambdas be added to Java or suggesting Javascript needs a better lexical scoping assignment primitive. It was a problem, but now we have new problems.