The C2 wiki has a discussion of Empirical Evidence for Object-Oriented Programming that basically concludes there is none beyond appeal to authority. This was last edited in 2008. Discussion here seems to bear this out: questions on whether OO is outdated, when functional programming is a bad choice and the advantages and disadvantages of AOP are all answered with contributors' opinions without reliance on evidence.
Of course, opinions of established and reputed practitioners are welcome and valuable things to have, but they're more plausible when they're consistent with experimental data. Does this evidence exist? I know that evidence-based software engineering is a thing, but can I practice it in this context? Specifically, if I have a particular problem P that I want to solve by writing software, does there exist a body of knowledge, studies and research that would let me see how the outcome of solving problems like P has depended on the choice of programming paradigm?
I know that which paradigm comes out as "the right answer" can depend on what metrics a particular study pays attention to, on what conditions the study holds constant or varies, and doubtless on other factors too. That doesn't affect my desire to find this information and critically appraise it.
It becomes clear that some people think I'm looking for a "turn the crank" solution – some sausage machine into which I put information about my problem and out of which comes a word like "functional" or "structured". This is not my intention. What I'm looking for is research into how – with a lot of caveats and assumptions that I'm not going into here but good literature on the matter would – certain properties of software vary depending on the problem and the choice of paradigm.
In other words: some people say "OO gives better flexibility" or "functional programs have fewer bugs" – (part of) what I'm asking for is the evidence of this. The rest is asking for evidence against this, or the assumptions under which these statements are true, or evidence showing that these considerations aren't important. There are plenty of opinions on why one paradigm is better than another; is there anything objective behind any of these?
Best Answer
For the previous take, see Revision 1 of this answer. However, the comments and edits to the question further clarify what the question is seeking and allow me to be more clear.
Yes, evidence based software engineering (EBSE) is a thing. There appears to be a few efforts toward EBSE databases, such as this one at Durham University and SEED, which was started by a professor at Cal Poly. All of these efforts, as well as ones discussed in a number of papers that can be found through the IEEE Xplore server or the ACM Digital Library (subscription or purchase required for many papers in both), are based on evidence-based medicine. They provide literature reviews of published empirical (observation and experiment) data. In fact, including "literature review" in a search string on any publication search yields information on most topics - over 14000 hits on the ACM and over 1000 on the IEEE database (when limited to only computing topics).
Looking at the general types of topics discussed in these EBSE databases and literature reviews, I see a common thread - they tend to be technology-independent. The emphasis appears to be mostly centered around process and methodology rather than the specific tools used to conduct software engineering.
So, this concept exists in software engineering. Academia is aware of the evidence-based concept and can successfully apply it to software engineering.
Specifically, the question addresses applying EBSE techniques to the selection of a paradigm seems difficult, due to the sheer number of variables involved, forcing assumptions to be made as well as reducing the ability to repeat the experiment or observation. It's said right in the question - "which paradigm comes out as "the right answer" can depend on what metrics a particular study pays attention to, on what conditions the study holds constant or varies, and doubtless on other factors too". Although that doesn't mean that studying which paradigm is "best" in a given situation, it makes any kind of literature review of these documents incredibly difficult to complete and still extract information across them.
There definitely isn't a "turn the crank" solution to choosing a paradigm.
Given a programming paradigm, you can find studies in the various academic and industry databases about how that paradigm influences various aspects of software development - quality, defects, efficiency, and so on - under various specific conditions, ranging from the knowledge and experience of the team to the problem domain. Any rigorous paper should clearly identify the conditions under which the data was gathered and the assumptions. The problem becomes trying to isolate the factors that make it good in each of those conditions.
Academically, there are some statements that are easy to research. For example, the statement that the functional paradigm is well suited to applications that require concurrency stems from the Church-Rosser theorem. Because of this, it's likely that a software system written in a functional language will have fewer defects related to concurrency than the same system written in a procedural or object-oriented language.
However, from a practical standpoint, a software team can't always use "the best" tool or technique for the job just because research indicates it. Although we strive for producing the highest quality software systems, we do operate within constraints. Often, I see these constraints minimized (or even removed from the equation) when discussing the effectiveness of any methodology.
As a practitioner, when I'm involved in choosing technologies to use, I try to identify the best possible tools. But then I constrain myself to what is known and well-understood by the team that I have. Going back to my previous example, if I have a team well-versed in building concurrent applications in C++ and no experience in Haskell, it doesn't make sense to propose building the system in Haskell as I likely won't be able to make schedule and budget constraints, and my quality will likely suffer due to a lack of experience in the toolchain.
To recap, evidence-based software engineering is generally a good thing that exists and literature reviews do exist and are readily available. However, there are aspects of software engineering where applying evidence-based approaches offer little value. The selection of a programming paradigm to a large scale development effort is one of these.
If you want to find out about how object-orientation addresses reusability or defects in functional programming - you'll easily find publications on those. However, I didn't find (nor would I put any amount of trust in) a publication that was able to effectively address paradigm selection across the broad range of real-world software engineering projects.