Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

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?

share|improve this question
Why would a representation of an employee have to be mutable? It probably has state, but that's another question entirely. – delnan May 27 '12 at 15:25
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. – dan_waterworth May 27 '12 at 16:28
Functional programming has side effects, otherwise you would never be able to print anything. – user1249 May 28 '12 at 22:39
@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 '12 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 at 16:27

6 Answers 6

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

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 usefull 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++.

share|improve this answer
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 '12 at 22:16
@YannisRizos I think he was generalizing for the sake of a to-the-point answer as opposed to exploring every tangent of the problem. – Jacob Krustchinsky May 28 '12 at 19:41
@YannisRizos can != want to – user1249 May 28 '12 at 22:39
Sometimes it feels like to me that language even shouldn't be Turing complete for certain kind of Enterprise solutions... – shabunc Aug 13 '12 at 18:31
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 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.

share|improve this answer

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.

share|improve this answer
+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 '12 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!

share|improve this answer

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.

share|improve this answer

Yes, FP can be used in enterprise applications. Clojure is one example of an FP language with success in enterprise:

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

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

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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