First of all I don't care how a library is written - what I care is only its interface. Functional is more black box - if the abstraction suits you then it is g

First of all I don't care how a library is written - what I care is only its interface. Functional is more black box - if the abstraction suits you then it is great. OO is more manipulable, adaptable - you can override methods, set state etc. I also suspect that imperative programming is more natural (think cooking recipes and other instructions how to make something). In many cases the optimal solution is to provide two APIs - a functional, simple one, that covers most of the cases - and an OO one for the cases when people need to adapt the solution (this is often related to providing good defaults: http://perlalchemy.blogspot.com/2012/04/breaking-problems-down-and-defaults.html http://perlalchemy.blogspot.com/2012/04/breaking-problems-do...). It is very nice if all you need is a simple function - and in that case sure you should use a library with functional API - but what if your needs are more complex? This is why I don't buy the "functional programming at the low level" idea. The thing I would like to see is a way to mark a function as pure in imperative languages which would be checked by the compiler. That check would enforce that all variables are local and that no system function is called - but it could still call imperative code and also OO code that uses state manipulation - the only restriction would be that all that state is local (that is it is on the stack of the outer function that we mark as 'pure').