Comparing Paradigms

This is to clear up issues regarding comparing different software engineering paradigms.

First, one must be clear exactly what is being claimed. Possibilities include:

A is better than B
The benefits between A and B are unknown
The benefits between A and B are subjective (BenefitsAreSubjective)
The benefits between A and B are the same
A is more popular than B
A fits the internal mind of more people than B (even if subjective)

Burden of Evidence

One viewpoint is that the burden of evidence is on the person or group who claims that their given choice is objectively better than another. A second viewpoint is that the most popular paradigm is the default, and that anybody challenging that it deserves the popularity must show objective evidence that their challenging paradigm is better.

One problem with the "popularity" challenge viewpoint is that things may be popular in different circles or perspectives. For example, software engineering celebrities may favor a given technology, but rank-and-file IT workers may not. Also, it opens the possibility that fads could get stuck at the top by default with no way of coming down if the competitors are equal or if benefits are largely subjective.

If somebody claims that the differences are largely subjective, do they need to provide evidence of the subjectivity? How can it be proved that something is subjective?

And supposing that the differences were somehow "proved" to be subjective, what of it? Unless we know why it matters to know if these differences are subjective or objective, we have no reason to care one way or the other. "Subjective" seems to be being used almost as a term of abuse here.

It is important in order to distinguish between things like PersonalChoiceElevatedToMoralImperative and objective benefits. Someone might say, "It works better for me, therefore it is better for everybody". If you say, "there is no evidence for it being better beyond your AnecdotalEvidence?", then you may offend somebody. If the BenefitsAreSubjective, then the problem is partly solved. It can both work better for that person, yet still not be objectively better.

In my experience, a major problem in prgramming today is the application of a paradigm to problems which it is poorly suited to. Every paradigm has a very small domain in which it is advantageous, outside of which it neutral or even a hindrance.

It is no coincidence that OO rose to prominence at the same time that GUIs did, as visual interfaces happen to be one of those problems at which OO really shines - it is essentially a form of modelling, and modelling was what OO was first developed for. However, it rarely is very useful for, say, data processing - objects are too fine-grained and atomic, and poorly reflect the relationships between different types of data. It is also poor at numeric analysis, for much the same reasons.

Conversely, FP never caught on except in a handful of areas because it's great strengths - numerical analysis and symbolic processing - are rarely in the public spotlight.

Relational programming, being the strongest approach for handling vast quantities of loosely structured, DeeplyIntertwingled data, makes up the vast majority of real-world coding; but outside of that one area, it's fundamental assumptions simply don't apply.

NotationalDesign (one of my own favorite approaches) is usually complementary to some other paradigm, and works best for problems with a complex set of highly-parameterized interfaces - in other words, those places where a script language is called for. For most problems, it is simply too heavyweight an approach, and would add too much complexity.

The only paradigm that is equally applicable to all problems is low-level procedural programming, as typified by CeeLanguage and AssemblyLanguage - and that only in the JackOfAllTradesMasterOfNone? sense of being equally mediocre for all types of problems. This 'default' quality, along with the large number of existing algorithms for it, and the low design and implementation hurdles, are the real reasons why the majority of 'object-oriented', 'relational', and 'functional' code is really thinly disguised procedural code - the 'official' paradigm doesn't match the problem domain, so the programmer is forced to 'cheat' in order to force-fit a solution.

The solution? I think that what is needed is a system of ParadigmaticAnalysis - a meta-methodology for determining the best-fit paradigm for a given problem. Such a discipline would also require a method of recognizing the 'edge cases' where two different paradigms collide, and how to cross the boundaries gracefully.

Of course, these assertions could easily reflect my own multi-paradigm bias. It is probably telling that of my current favorite languages - Scheme, Python, Perl, and C - three of them are multiparadigm languages, while the fourth is a very-low-level procedural language. - JayOsako