I am just beginning to learn Functional programming (FP). I come from a OOP world, where everything are objects, and most of them are mutable. I have a hard time wrapping around the concept that functions don't have side effects.

If something is not mutable, how are common things objects like Employee or Person represented in FP.

Can FP be used to create a full fledged enterprise application?

  • 5
    Why would a representation of an employee have to be mutable? It probably has state, but that's another question entirely.
    – user7043
    May 27, 2012 at 15:25
  • 1
    Mutable data is used represents things. By contrast immutable data has the value of something at a specific point in time (though this is not its only use case). If you have every had a bug where you have two mutable objects that represent the same thing then you know of a case where using objects to represent things can break down. May 27, 2012 at 16:28
  • 2
    Functional programming has side effects, otherwise you would never be able to print anything.
    – user1249
    May 28, 2012 at 22:39
  • 1
    @Thorbjørn Ravn Andersen: In imperative (procedural, object-oriented) programming you use side effects both for communicating with the external world (IO) and for computing data transformations within your program. In FP you separate the two worlds clearly: you use side effects only for IO (a program without IO is normally useless), but you use pure functions to compute internal data transformations. Side-effects cannot be avoided altogether but since they are non local they are more difficult to reason about, so it is good to restrict their use as much as possible.
    – Giorgio
    Aug 13, 2012 at 14:36
  • Something like a "person" object doesn't need to be mutable. Instead, you create a whole new "person" object that's almost the same (but slightly different). You'd have a reference to the "person" object somewhere and change that to refer to the new copy instead of the old copy. Of course that reference might be in some sort of collection, so create a copy of the collection that's almost the same. There'd have to be a reference to the collection somewhere so you can swap the old collection for the new collection!
    – Brendan
    Oct 24, 2015 at 16:27

7 Answers 7


The question is not Can be FP used in the Enterprise ? but Should we use FP in the Enterprise ?

Of course you can. You can develop any kind of application with any kind of programming language, that's why they are called "Turing complete".

Now, to the question "Should be use it in the Enterprise ?" That's up to you or your employers, FP can be really useful in some kind of applications, and in fact, it's used quite a lot: Haskell in the industry

Now, you might be asking "So why is not used more?" mainly because other Imperative/OO languages are more common, and companies refuse to change to a more "exotic" language because they are used to Java or C++.

  • 8
    You can develop any kind of application with any kind of programming language That's a very weak argument, beware of Turing tarpits...
    – yannis
    May 27, 2012 at 22:16
  • 8
    @YannisRizos I think he was generalizing for the sake of a to-the-point answer as opposed to exploring every tangent of the problem. May 28, 2012 at 19:41
  • 3
    @YannisRizos can != want to
    – user1249
    May 28, 2012 at 22:39
  • 1
    Sometimes it feels like to me that language even shouldn't be Turing complete for certain kind of Enterprise solutions...
    – shabunc
    Aug 13, 2012 at 18:31
  • 2
    I would argue that that's not up to your employers, when it comes to languages, it's up to the engineers themselves to push forward with what we see is best from our technical point of view.
    – shmish111
    Jun 3, 2015 at 10:34

I have started learning about FP languages a couple of years ago (Haskell, Scala, Scheme) and, even though I am far from being an expert, I found out that they can make me extremely productive, for certain tasks more than C++ or Java.

IMO, some of the strengths of FP languages are:

  • They tend to be very concise, yet they retain a clear semantics.
  • You can use a declarative style and do not need to think too much about implementation details.
  • A rich type system like Haskell's can catch many logical errors very early (at compile time). As far as I know (not very much, actually), SML and Ocaml offer similar advantages.

Up to now, I have found the switch to the FP paradigm quite exciting and not too difficult once you spend enough time on it. (But how much time did I spend learning C or C++? Quite a lot!)

So I think that from a technical point of view it makes perfectly sense to develop a full enterprise application using a functional programming language.

Unfortunately this paradigm is not mainstream: most companies tend to adopt well-tested technologies only, so they will stay away from FP until they have enough evidence that it actually works, that there are enough developers, tools, libraries, frameworks. Therefore it is (much) more difficult to find a job in which you can do FP programming full.-time right now.

Maybe the current situation will change if the increasing use of multi-core processors will encourage to invest more in FP languages, which seem to be quite strong for writing concurrent software.

Also, there is a tendency to introduce some FP features into mainstream, non-functional languages like C#, C++ so that programmers can use some FP without the need of a complete paradigm switch. Maybe in ten years from now these languages will cover enough FP features that the switch to a purely functional language will be a lot easier.

  • This is one of the nice things about F# as an entry point into the world of functional programming. It's a "functional first" language and works with any .NET library, meaning it is easy to make anything with it that you would use C# .NET for. Unfortunately a lot of those libraries, and specifically the older ones, are very OOP-centric, so when interfacing with them you have to break out of a purely functional style. Luckily F# will let you do this, though the syntax very much prefers FP over OOP.
    – Turksarama
    Jan 19, 2021 at 5:31
  • +1 for pointing out you a complete paradigm switch is not requied, i.e. you can use FP and, say, OOP alongside one another. May 10, 2021 at 14:16

I don't think that it is necessarily the best idea. But it depends on the nature of the specific application.

I believe a lot in the philosophy of Eric Evans as described in his book, Domain-Driven Design, that you should make a domain model that is representation of the problem at hand that can help you solve your problem. Evans suggests finding a programming language that sits will with the particular problem at hand, e.g. he mentions Fortran as a way of solving problems of a mathematical nature. Or even creating specialized Domain-Specific languages for the problem at hand.

When you have succeeded in creating a good domain model, the you will find that the presentation code ends up being an thin shell on top of the domain layer.

Now the thing with enterprise application is that this type of application (if you can generalize about enterprise applications) often involves modifying state of entities of which identity is of importance, and persisting the modified entities in a database. This very generalized type of problem is IMHO a lot better solved by using en object oriented model than a functional model.

This doesn't mean that there are areas of an enterprise application that couldn't be better solved by a functional paradigm. For example a risk analysis module of a banking application, or a route planning module in a shipping application. And perhaps some enterprise applications could be implemented wholly using a functional paradigm.

But in general, I think that the object oriented paradigm allows creating more useful domain models for the majority of enterprise applications.


Due to some upvotes, my attention was drawn to this answer - and since I wrote it, I have learned a lot more about FP - and I am not entirely sure that I agree with my own answer anymore. Some functional languages can very nicely describe use cases. But you need to learn a completely different mind set.

  • 2
    +1: Very good and stimulating answer. Due to my limited knowledge on FP I am not sure if this is correct, but I think that persistent objects could be modelled using monads or unique types (in Clean): in this way a value can get an identity, be passed around your program and transformed by different functions. But I would really need the opinion of a FP expert to back this up.
    – Giorgio
    Aug 13, 2012 at 17:03

Yes, it can. Google a bit and you'll find real software coded in pure functional languages.

As for your question about business objects, I guess your actual problem is with immutability. In that case, consider that you are returning a new "Person" each time you would mutate it if you were using an imperative language.

Note that this technique can also be implemented using imperative languages!


Function Programming(FP) like Object Oriented Programming (OOP) are paradigms. They represent different patterns or approaches to programming problems. These different approaches do not obviate the ability to produce scalable, maintainable and extensible software. That isn't to say the approaches are equivalent for all problems types; they aren't. Certain problems align themselves better (or worse) to particular paradigms, for example FP wouldn't be my first choice for a program which has a dependent sequence of operations with side effects. However such programs can and have been written, and written well.


Yes, FP can be used in enterprise applications. Clojure is one example of an FP language with success in enterprise: http://cognitect.com/clojure#successstories

Representing state can be a challenge in FP and changing paradigms to fit FP can be a bit of a mind warp. Some FP languages completely disallow side affects and mutable state. Clojure allows both but discourages or isolates those paradigms.

In short, state representation may be very similar to OO. It's state modification that is very different. So for instance, in FP state may be represented by lists and maps. A list of employees may look like:

[[name: "James Brown" address: "Barnwell, SC"]
 [name: "Elvis Presley" address: "Tupelo, MS"]]

There are two ways I know of to handle state modification in FP. One is something like functional reactive programming. In this paradigm all state is handled at the highest level only... for instance, an HTML view of your application has state in the view (like the person's name, address, etc.). Now when you click "update name" a function is called that handles every thing about a name update except actually changing the name. This may sound weird... but bear with me. The changed name would then be returned by the function and the view (or persistent data store, etc.) will show the new name. Or, alternatively, an entire new structure with the updated name will be returned. So what does the function do? It validates the name and returns the new name if it is valid, an error if it is not, and possibly a new view or navigation link to follow. For something more complex than a name change it may do a lot more.

So for FRP the object returned by the function is the new state and can be given directly to the view or whatever is at the high level. In some cases FRP takes the whole state passes it to the function and gets the whole state back.

With this paradigm, the container or framework needs to handle the update of the display, database, or whatever else needs updating from the new state. So you can imagine a framework that draws the application on screen. When a user clicks something functions are invoked and the new state is returned. The framework then updates the screen by either redrawing everything or intelligently redrawing parts of the display. See http://blog.getprismatic.com/om-sweet-om-high-functional-frontend-engineering-with-clojurescript-and-react/

Clojure uses the second paradigm that I've come across and that is to isolate state changes but not necessarily restrict them to the highest level. With Clojure all mutable state must be "held" (unless you're using Java objects for state) by an atom, agent, or reference. The way this works is the object held or pointed to or referenced (however you want to call it) by the atom/agent/ref is immutable, but the atom/agent/ref can change to point to a new object. In this case you use special methods on the atom/agent/ref that say "update the object here by doing such and such and reassigning the atom/agent/ref to a new object".

Why is this beneficial you may ask? Because the immutable object referenced by these Clojure constructs may be passed to a function that does something and while that function is running its reference to the object is guaranteed not to change. That is, the atom/agent/ref isn't passed to the function but the immutable object pointed to by them is passed. Atoms, agents, and refs have special properties that handle updates and concurrency in ways that are safe and part of the language. See http://clojure.org/state

I hope this helps. I suggest reading more about Clojure state and FRP to get a better understanding for how employees and persons can be represented in FP. Though, the actual representation would be similar to object oriented programming... it's the mutability that is really different.


I rephrase the question: "Can FP compete with OOP in describing domain models in terms of data storage, transformation and representation"?

Answer is: No, it can't. That's why we have OOP and DSLs.

FP is a simple metamodel for formulating mathematical recursive structures. So as like Prolog is metamodel for formulation and evaluation of complex rule sets.

Update, to explain the thoughts behind; thanks @Andrew for your request.

The reason why we create and use Programming Languages is because we need a "descriptive bridge" between the processor's machine code and human's mind. There is no other reason. Machine code exists as a sequence of steps, iterations and conditions. Human's thoughts on the other hand is a ontological model of the reality.

For this purpose we need a expression transformation chain capable to transform abstract humans thoughts into the machine code. Simply said, the longer the transformation chain the better the programming language. A futuristic advanced programming language can be for example a "interview language", where the compiler asks and the human answers the questions in natural language.

OOP is quite far already. We describe the entities of real world in terms of appearance, behavior, hierarchy and functional identity (=interface).

FP is more simply model to call functions, pass other functions as parameter and return again functions or values. ... and recursion. That is all what you need to express internal (complex) relationship of single entities like mathematical formulas in terms of processing lists by recursion.

I couldn't find any references describing in detail the thoughts above. Here just two of many that explains the core value of functional programming for that purpose: https://softwareengineering.stackexchange.com/a/68847 https://mathblog.com/10-great-programming-languages-for-mathematics/ (all of that named languages are functional in core)

  • Welcome... please elaborate on your answer, citing sources and explaining your reasoning
    – Andrew
    Jan 23, 2021 at 10:24

Not the answer you're looking for? Browse other questions tagged or ask your own question.