4

What would be a valid reason(s) to use objects in functional programming languages? I see that f# is a functional programming language that lends heavily on the object side when dealing with the .net ecosystem of classes. But apart from this interaction with other assemblies/programs maybe written in c#, why would anyone choose to use objects for decomposition of a program in a function oriented language or style?

Does mixing up a style of program prove a help or a hindrance?

WeNeedAnswers
  • 4,620
  • 2
  • 32
  • 47

2 Answers2

5

Functional and object oriented designs make different types of extensions easy. Given a discriminated union in a functional setting, it's easy to define any number of functions which work on that type, but it's hard to add additional cases to the type, since that would require going back to add the additional case to each function which pattern matches on the type. On the other hand, given a base type (or interface) an OO setting, it's easy to add new subtypes, but adding new operations to the base type is hard, since it potentially requires modifying existing subtypes to add an implementation of the new operation to each one.

Depending on the type of extensibility that's most relevant to the task at hand, either the functional or the object oriented approach may make more sense, so it's nice to have both options available. One popular approach is to use a functional approach "in the small" and an OO approach "in the large" (e.g. it's mentioned in this podcast with Luke Hoban).

kvb
  • 54,864
  • 2
  • 91
  • 133
  • 2
    Possibly see also http://lorgonblog.wordpress.com/2008/09/22/how-does-functional-programming-affect-the-structure-of-your-code/ – Brian Feb 02 '11 at 06:14
  • I also take that popular approach. It helps to encapsulate functions into meaning things i.e. objects. – gradbot Feb 02 '11 at 15:55
  • Does that mean that the functional approach isn't scalable to large systems, using only FOP/FOA methods? – WeNeedAnswers Feb 02 '11 at 17:00
  • its been well known that inheritance is a very fragile extension method for some time, I believe in extension through composition, and replace like for like. I think that f# has a much stronger case when using composition. – WeNeedAnswers Feb 02 '11 at 17:03
  • I listened to the podcast. I don't know, as far as I can tell he refers to objects as packaging. Surely modules and libraries cater for this in much the same way. Correct me if I am wrong, but that was not the original sales pitch of OO. It was all about managing state and ownership of state. I scaled many applications in the large using Delphi without worrying about objects as encapsulation. what gives? – WeNeedAnswers Feb 02 '11 at 17:09
  • Also there needs to be a distinction between a component and an object. They are different. – WeNeedAnswers Feb 02 '11 at 17:12
  • @WeNeedAnswers - one problem that you'll run into is that "OO" is a pretty diluted term at this point, and means different things to different people. You could look at some of the traditional aims of object oriented programming (such as encapsulation), and see that they are well supported by functional programming languages anyway, so OO and FP aren't necessarily incompatible alternatives. – kvb Feb 02 '11 at 17:28
  • @WeNeedAnswers - regarding the inflexibility of inheritance, I think it's often prudent to avoid implementation inheritance but I don't see any major issues with interface inheritance. – kvb Feb 02 '11 at 17:31
  • @kvb Don't you find that the encapsulation principal is void when using immutable values in FOP, or do you think there is more to encapsulation than state management? – WeNeedAnswers Feb 03 '11 at 02:20
  • @WeNeedAnswers - I don't think that "encapsulation" is typically restricted to mutable state, but any information hiding. So to my mind, nested `let`-bound identifiers in purely functional F# code demonstrate encapsulation just as using the `private` modifier in C# does. – kvb Feb 03 '11 at 02:35
  • 2
    Indeed, encapsulation has nothing to do with state. You can even have OOP without state, e.g. see functional object update in OCaml. – J D Feb 04 '11 at 19:53
  • 1
    _use a functional approach "in the small" and an OO approach "in the large"_ looks very much like the approach used by Erlang, if you substitute process for object. – Muhammad Alkarouri Feb 04 '11 at 22:50
  • @Muhammad: Indeed, and processes are arguably closer to what object orientation was intended to be. – J D Apr 10 '11 at 18:02
  • @kvb: I don't think your answer is correct. You are really just talking about functional languages that provide nothing more than ordinary variant types. Languages like Standard ML, Haskell and F#. In particular, it does not apply to OCaml, Lisp or Mathematica that each have other features that allow these kinds of extensions. – J D Apr 10 '11 at 18:06
  • @Jon - Sure, it's fair to quibble with my argument. However, I think that it's reasonable to say that open recursion is much more commonly used in popular OO languages than analagous techniques are used in "popular" functional langauges. The quesion of what constitues a functional or OO style is somewhat subjective anyway - if you use the features that you're talking about, would you consider the program to be written in a functional style (particularly in the context of the question that was asked)? – kvb Apr 10 '11 at 18:25
  • @kvb: All popular functional languages are multiparadigm and offer OOP so people are likely to just use that for open recursion. – J D Apr 10 '11 at 23:41
0

Objects provide encapsulation that makes large-scale programming easier.

What would be a valid reason(s) to use objects in functional programming languages?

Objects are used in functional languages for a variety of reasons:

  • Large-scale structuring of programs.

  • Interoperability with existing OOP code (e.g. on the JVM or CLR).

  • Problems for which the ability to extend class hierarchies with more classes is a natural fit.

Does mixing up a style of program prove a help or a hindrance?

Can be a help but it would not be a good idea to do it without good reason.

J D
  • 48,105
  • 13
  • 171
  • 274
  • Thanks for your reply. Your answers tend to via off to other areas which I have issue with, such as scalability and the use of inheritance as a brittle approach to programming in the large. I will add though that I have recently been looking at code "smells" and an interesting point that I came across was that design patterns are signifies to a language that is not catering for all areas. I think this whole programming in the "large" and the "small", in my mind is a bit outdated. I do not see functional programming in the small, in very much the same way as C is used in the small. – WeNeedAnswers Apr 13 '11 at 11:41