4

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.

Improve this question

    5 Answers 5

    Reset to default
    9

    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?

    Improve this answer
    8
    • +1: Yes, I had also suspected that marketing is sometimes more important than good language design. This would not explain lambdas in C++, though. Also, I understand this from the point of view of a company developing a language. But as a programmer, I would not move from Java to C# because of lambdas but rather to Scala. So, I do not fully understand the attitude of programmers.
      – Giorgio
      CommentedMar 29, 2012 at 23:19
    • Yes, that does seem hard to account for, though I freely admit to never having done any kind of study as to what motivates programmer adoption of languages (or really to even having considered it). I agree with you that this would be an extremely odd choice, but perhaps people make it.
      – Erik Dietrich
      CommentedMar 29, 2012 at 23:26
    • 2
      Extending C# with FP features means anyone who is already using C# has one less reason to switch. They're not going to get the Haskell crowd to mass-migrate to C#, but it does prevent C# folks from hitting brick walls and causing them to go looking for alternatives.
      – tdammers
      CommentedMar 30, 2012 at 9:04
    • @tdammers: Yes, but I wonder if a C# programmer who is happy with very few functional features is really interested in FP or just finds it cool because it is the hype of the moment. I sometimes have the impression that coolness factors influence language choice more than real practical advantages.
      – Giorgio
      CommentedMar 31, 2012 at 10:24
    • @Giorgio (and Mr Dietrich) -1 because - C# gains alot as a language from lambdas and their companion LINQ to objects. I feel this answer doesn't really do it justice - it's not just marketing hype - it's actually very useful. You start with it bears mentioning... but as a standalone answer, it seems a bit off the mark...
      – Max
      CommentedMar 31, 2012 at 10:34
    3

    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.

    Improve this answer
    13
    • This is an interesting point. Maybe there is also a lot of scary OOP stuff that did not make it into mainstream programming languages because was it was not considered useful enough (see e.g. the comment about using only single-dispatch in programmers.stackexchange.com/questions/59387/…).
      – Giorgio
      CommentedMar 30, 2012 at 8:42
    • On the other hand, I would not justify FP features because they allow to implement libraries: why would it be unreasonable to use a separate programming language? There is separate compilation for that. Why not implement the library in F# and use it from C#?
      – Giorgio
      CommentedMar 30, 2012 at 8:45
    • For example, isn't the Python sort() built-in function normally implemented in C?
      – Giorgio
      CommentedMar 30, 2012 at 8:57
    • 2
      @Giorgio, another programming language often means using another (or additional) set of runtime libraries. Not everyone ready to carry this burden (e.g., scala-library.jar). Python and C is a different thing - Python interpreter depends on C standard library anyway.
      – SK-logic
      CommentedMar 30, 2012 at 9:15
    • Extending the language and the compiler is also a burden (additional complexity, possibly slower compilation). I am not sure if one of the two approaches has a clear advantage.
      – Giorgio
      CommentedMar 30, 2012 at 9:28
    2

    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.

    Improve this answer
    6
    • 2
      My point is why use, say, C++ with some FP instead of using, say, OCAML? Is OCAML not suitable for the kinds of application C++ is used for? Are C++ programmer too lazy to learn something different? Is OCAML too FP-oriented? Other reasons?
      – Giorgio
      CommentedMar 30, 2012 at 5:49
    • 3
      Actually, I find libcairo, for example, much easier to use in Haskell than in C. In C, you have to drag the Cairo context around explicitly, and you have to be careful about when you can and cannot access it; in Haskell, you explicitly do all your rendering in a Render monad context, and you never have to worry about accidentally trying to render to a dangling surface pointer or something.
      – tdammers
      CommentedMar 30, 2012 at 8:56
    • 1
      "Purely functional programming styles have serious problems with input/output.": I was not arguing about pros and cons of FP and whether one should use pure FP or a mix of OOP + FP. My point is "adding some FP support to an OOP language" versus "designing an OOP + FP language from scratch".
      – Giorgio
      CommentedMar 30, 2012 at 9:14
    • 2
      "Purely functional programming styles have serious problems with input/output.": This idea keeps many programmers away from FP, but AFAIK it is not true, or can you back it with some example?
      – Giorgio
      CommentedDec 28, 2012 at 20:47
    • "Haskell which is has...intimidating I/O techniques" -- Haskell does not have intimidating IO techniques. You should try learning Miranda, the language it replaced, which had non-referentially-transparent IO in a language whose interpreter assumed referential transparency, which made for some entertaining (hopefully theoretical) possibilities...
      – Jules
      CommentedJun 13, 2016 at 23:02
    1

    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.

    Improve this answer
    1
    • +1: "Use different tools for different jobs, don't try to make the ultimate Swiss army knife which doesn't really do any job well"! I think you pointed out two good explanations: (1) companies do not want to change too much the language they sell because of marketing reasons, (2) some developers want to have some FP in their favourite language because they do not want to learn something too different (from the One True Language they already know).
      – Giorgio
      CommentedMar 30, 2012 at 5:37
    0

    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.

    Improve this answer
    1
    • I am in favour of approaches like Scala (I do not know F#, probably it is similar) in which a language is designed from scratch to integrate both paradigms. In other cases the FP features are not well integrated and lead, IMHO, to artificial solutions that would not be idiomatic in FP. For example, I remember an article on how to use lambdas in language X (lambda were added to this language only lately): it was a situation in which a for loop would have perfectly done the job, but the loop's body had been replaced by a large lambda expression. In FP I'd rather have used map or reduce.
      – Giorgio
      CommentedAug 21, 2014 at 11:19

    Start asking to get answers

    Find the answer to your question by asking.

    Ask question

    Explore related questions

    See similar questions with these tags.