comments[]
GV wrote: It's not about FP vs OO, as they are neither opposite nor incompatible. It's about imperative programming vs functional programming. Object-oriented techniques are useful in both paradigms, although they are needed at a much smaller scale in imperative programming. In imperative programming, you are thinking of memory cells and instructing a computer to modify the content of these cells, one step at a time. Imperative programming is based on the Turing machine. In functional programming, you are thinking of applying functions to values to produce new values. There is no notion of modifying anything, and the order in which you execute the steps does not always matter. Functional programming is based on the lambda calculus. Object-oriented techniques (as the term is generally understood today) are about organizing the code in such a way that a data type's structural definition is in the same physical place (file) as the code for the methods that act primarily on that data type. This is a completely orthogonal issue. I'll be a bit assertive and controversial here: imperative programming has exactly two advantages over functional programming, and only the first one kind of matters (for now). I'll first present them both, then explain why they likely won't matter in the long run, and conclude with my opinion on which is better in which situation today.
The first one is performance. I'm not an electrical engineer, so I'm not sure whether this is a requirement or an historical accident (I think it's a requirement), but the fact is that, today, microprocessors are essentially glorified Turing machines, i.e. embodiments of imperative programming, imperative code runs "natively" on them, while functional code basically has to build up a lambda calculus interpreter on top of the microprocessor before it can execute. In particular, as functional programming has no notion of "places" in memory, functional programming essentially requires a garbage collector.
The second is familiarity. Functional programming has only been practical, performance-wise (see previous point), for perhaps two decades at most (the ideas date back much farther, though). This means that the vast majority of computer science professors and teachers have learnt at a time when imperative programming was about the only option, and therefore that's what they know best, and what they've been teaching for all of their career. In turn, this means that most professional developers are very good at imperative thinking and programming, and there is a lot of existing code, libraries, very efficient runtimes, tools, etc. Comparatively, the functional programming ecosystem is just getting started.
On all other aspects, functional programming is better. Unfortunately, in the real world, these two points are far from negligible. Of course, there is a strong hope in the functional community that better compilers and JIT runtimes will obviate the first point, and there has been much progress on the second point in terms of programming mindshare.
So where does this all leave us today ? It's very likely that your team is experienced with imperative programming, and that you'll get much better performance from an imperative language. As Khist Nakhom says below, numerical computations, where performance is very important, are very hard to do in functional languages today. Another example would be 3D rendering.
In conclusion, I'd say that if you are working on a very tight and very short schedule, or if you are in a situation where you will really need to squeeze every last bit of performance from your system, you should definitely go with an imperative approach. If, however, you are in a situation where performance is not that important, e.g. you are considering languages like Ruby or Python, or you have a possibly tight but somewhat long schedule, learning to program in a functional way will pay off.
You should do it.As I said at the beginning, you will still need your object-oriented skills to design "big" functional programs, just like you need them to design "big" imperative programs. OO is about system design (think UML-like schemas), whereas functional vs imperative is about the code itself. However, the definition of "big" will be very different: as there is less hidden dependencies between lines of code in a functional program, you will need more lines for your code to be "big", and as functional languages are generally more expressive, each line will do more, so overall "big" is much bigger in the functional approach.
Notes[]
This whole oop is for "big" projects and procedural is for "small" is an abitrary belief from David Robson original article in Byte Magazine and has the premise that oop isn't procedural . Yin wang insist that oop is procedural programming.