Introducing functional programming constructs in non-functional programming languages

Question

This question has been going through my mind quite a lot lately and since I haven't found a convincing answer to it I would like to know if other users of this site have thought about it as well.

In the recent years, even though OOP is still the most popular programming paradigm, functional programming is getting a lot of attention. I have only used OOP languages for my work (C++ and Java) but I am trying to learn some FP in my free time because I find it very interesting.

So, I started learning Haskell three years ago and Scala last summer. I plan to learn some SML and Caml as well, and to brush up my (little) knowledge of Scheme. Well, a lot of plans (too ambitious?) but I hope I will find the time to learn at least the basics of FP during the next few years. What is important for me is how functional programming works and how / whether I can use it for some real projects. I have already developed small tools in Haskell.

In spite of my strong interest for FP, I find it difficult to understand why functional programming constructs are being added to languages like C#, Java, C++, and so on. As a developer interested in FP, I find it more natural to use, say, Scala or Haskell, instead of waiting for the next FP feature to be added to my favourite non-FP language. In other words, why would I want to have only some FP in my originally non-FP language instead of looking for a language that has a better support for FP?

For example, why should I be interested to have lambdas in Java if I can switch to Scala where I have much more FP concepts and access all the Java libraries anyway? Similarly: why do some FP in C# instead of using F# (to my knowledge, C# and F# can work together)?

Java was designed to be OO. Fine. I can do OOP in Java (and I would like to keep using Java in that way). Scala was designed to support OOP + FP. Fine: I can use a mix of OOP and FP in Scala. Haskell was designed for FP: I can do FP in Haskell. If I need to tune the performance of a particular module, I can interface Haskell with some external routines in C.

But why would I want to do OOP with just some basic FP in Java?

So, my main point is: why are non-functional programming languages being extended with some functional concept? Shouldn't it be more comfortable (interesting, exciting, productive) to program in a language that has been designed from the very beginning to be functional or multi-paradigm? Don't different programming paradigms integrate better in a language that was designed for it than in a language in which one paradigm was only added later?

The first explanation I could think of is that, since FP is a new concept (it isn't new at all, but it is new for many developers), it needs to be introduced gradually. However, I remember my switch from imperative to OOP: when I started to program in C++ (coming from Pascal and C) I really had to rethink the way in which I was coding, and to do it pretty fast. It was not gradual. So, this does not seem to be a good explanation to me.

Or can it be that many non-FP programmers are not really interested in understanding and using functional programming, but they find it practically convenient to adopt certain FP-idioms in their non-FP language?

IMPORTANT NOTE

Just in case (because I have seen several language wars on this site): I mentioned the languages I know better, this question is in no way meant to start comparisons between different programming languages to decide which is better / worse.

Also, I am not interested in a comparison of OOP versus FP (pros and cons). The point I am interested in is to understand why FP is being introduced one bit at a time into existing languages that were not designed for it even though there exist languages that were / are specifically designed to support FP.

Answer 1

Notwithstanding any specific ideas on the part of language designers, it bears mentioning that authors and stewards of programming languages are, in the end, pushing a product. So, I might ask why I'd want a camera-phone when my plain phone is a better phone and my camera a better camera, but that isn't going to stop manufacturers of both devices from trying to broaden their product's offering to attract new customers.

Once you look at it from that perspective, then notions of preserving the integrity of the original language become a matter of degrees and tradeoffs. If I'm the author of OOP language AwesomeCode and I see people starting to get interested in new functional language FCode, do I tell my users "sorry, but this is an OOP language only" and risk them going to C# instead to get at its lambas, or do I cave and grudgingly include some of FCode's functionality?

Answer 2

Take a look at LINQ - it would not be possible without those some FP features, whereas it hides all the scary FP stuff under the bonnet.

FP features are very useful for those who implement somewhat complicated libraries and frameworks - it is unreasonable to use a different language for such things. "End users", all the average enterprisey programmers, won't need to know anything about that arcane features, but they're happy to use the libraries built upon FP extensions.

Answer 3

Purely functional programming styles have serious problems with input/output. That's why most functional languages are not pure and Haskell which is has...intimidating I/O techniques. Anything that requires a destructive update like Graphics for instance is harder to do that in functional languages.

Functional constructs are being added to mainstream languages for three main reasons:

1. Pattern Matching: Functional languages typically have extremely compact syntax for dealing with pattern matching. Python has shades of this with its for statements. This winds up very useful in things like Data Mining.

2. Generic Programming/Metaprogramming: These both improve code adaptability tremendously by allowing a program to either be more flexible or to modify itself as it goes along. This can be hugely important in AI.

3. State Control: Functional Programming has no variables whatsoever, it has symbols instead. Every "variable" has a single unchanging value. That means we don't get any kind of ambiguity in terms of what something is. A magic A is a magic A while in imperative languages it could be a Magic A or B or C or D or whatever. There is no chance at all for an undetermined state in Functional Programming because there aren't any states in that sense. What is done instead is the idea of isolation of I/O. You get back what you put in, not some random weirdness and due to isolation there is no way that I/O can corrupt your internal program (ideally). This whole mess comes in hand in particular with Concurrency as you don't need locks or barriers.

I'd argue that Object Oriented Programming is still fully applicable with Functional Programming. OO Programming is a useful way of organizing and structuring code while Functional Programming is a useful way of ordering and structuring computation. OCAML is a prime example here. OO Programming has even been combined with logic programming in the form of Prolog++. So OO Programming can certainly benefit from other styles just as much as they can benefit from it.

Answer 4

Erik's answer is correct for the "why" this is done.

I'd like to add that when selecting a language, pick the one that naturally supports the paradigm. For example, wanting to do FP and picking C++ and wrangling in some strange libraries is inferior in every way to just picking a FP language to start with. Pick the tool that best meets the need. If you really want FP features, use an FP language, don't use the weak half-functional implementation of it with leaky abstractions in another language.

This kind of thing annoys me when people try to wrangle everything into The One True Language, which is the wrong idea. Use different tools for different jobs, don't try to make the ultimate Swiss army knife which doesn't really do any job well.

Answer 5

Who's to say that multiple paradigms can't coexist? There are number of hybrid languages that bridge the gap between OOP and FP like F# and Scala.

The trouble is the last couple decades made OOP the industry standard and so the majority of folks in the industry understand designing software with objects. FP offers some low-hanging fruit (ideas such as LINQ) that can be immediately useful in the OO world. By offering the low-hanging fruit first, programmers can remain productive and gradually cross the bridge, learning to apply FP ideas at their own pace. This gradual induction into the FP paradigm would not be possible if programmers were forced to embrace the entire paradigm all at once -- e.g. dive straight into Haskell.