Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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
4  
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
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. –  dan_waterworth May 27 '12 at 16:28
1  
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
add comment

5 Answers

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
4  
You can develop any kind of application with any kind of programming language That's a very weak argument, beware of Turing tarpits... –  Yannis Rizos May 27 '12 at 22:16
4  
@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
1  
@YannisRizos can != want to –  user1249 May 28 '12 at 22:39
    
Haskell is used in the industry, but so is HTML. Is Haskell used to develop the kind of applications that many think it can't? 3D games, large GUI applications, large-scale web servers? –  Zippoxer Aug 13 '12 at 17:14
1  
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
show 1 more comment

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
add comment

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
add comment

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
add comment

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.

share|improve this answer
1  
+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
add comment

Your Answer

 
discard

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.