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?
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++.
You can develop any kind of application with any kind of programming language That's a very weak argument, beware of Turing tarpits...
!= want to
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:
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.
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.
Edit
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.
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)
