Functional in the small, OO in the large

The most recent episode of Software Engineering Radio is an interview with Luke Hoban, program manager for F#. The interview mentioned the idea of using functional programming in the small and object oriented programming in the large. In other words, individual methods might be implemented using a functional programming paradigm, say in F#, but the code would be bundled into an object for other parts of an application to use. The grand structure would be object oriented, but the small structure would be functional.

I suppose “functional in the small, OO in the large” makes sense, but I could imagine someone arguing for a different way to combine the two approaches to programming. Any thoughts?

13 thoughts on “Functional in the small, OO in the large

  1. I feel like this is just an excuse because F# doesn’t have a good module system yet full of functors and stuff. You cannot program in the large and VS (as a whole) is still largely OO. And how good is the garbage collector that it can handle lots of allocations/deallocations necessary for a large functional project?

    I guess the main question I see is. Why can’t I program in the large with F#? Currently, I’m getting a reading of: it’s too young and it doesn’t play easily with the rest of the libraries at large and lacks large features. And this makes sense, but that doesn’t mean that it is the ultimate methodology that he intends his F# programmers to use. So, what is the goal of the project? Functional programming in VS only on the small or eventually on the large?

    //didn’t listen to the interview –but will shortly–, so if he did go over anything I mentioned, please inform!

  2. I am having problems downloading the podcast (only see first 14minutes), but I’ll just append my opinions above with the following.

    I think my questions still stand, I see some of the goals emerging (Algorithms and Parallelism). But, unlike Luke, I don’t believe OO is a great paradigm in general, and he definitly thinks that it should be how a project is designed –possibly the only way. I haven’t used F# more then just on the small, the little functions and algorithms (the on the small, he talks about), but I am an ocaml programmer and have experience with large projects in ocaml. I agree with him that OO and Functional programing can work together (we do a little bit of OO as well), but I also think that the main design of your project doesn’t have to be OO; a module design can be equally powerful. I think it might be tough for the F# team to operate the current C# libraries with F# due to the immutability/language constraints.

  3. Logtalk uses a similar approach: logic in the small, OO in the large. In this programming language, OO is used basically for code encapsulation and code reuse, two essential features for both logic and functional programming languages when programming in the large.

  4. there’s not exactly about small-large, I believe – rather FP for calculation parts, OO for reactive stateful parts

  5. And if I do otherwise? OO in the small and FP in the large. What I want to say about FP in the large is about orchestrating objects always bringing them to the main program like in FP. Combining small components (OO objects) in a FP way. What you think?

  6. I Just discovered your blog and I wish to thank you for all the useful informations and insights you took care to post, it’s great!

    Despite the article being old, I’ve started to apply this approach to my programs, due to pure FP being next to impossible to implement in real world situations on my part. I must say the benefits are really noticeable. Functions are easy to test (or self-test by asserting input and output arguments) and can safely turned to static if needed, in languages which support the feature. Objects become smaller and easier to manage, and the overall system becomes easier to understand at every level.

  7. Sorry for being late, but I only recently understood that OOP should be used in the small and FP in the large. “In the large” I mean system of many processes, each with its own address space, distributed and/or fault tolerant.

Leave a Reply

Your email address will not be published. Required fields are marked *