Mixing Paradigms

A discussion about when, where, why, and how much to mix paradigms.

There is an argument that it is not practical to mix too many paradigms into an application. To keep our tool-kit clean, tools should be more or less orthogonal. If we have a socket-wrench set, then we may not also need a regular fix-sized wrench set. Maybe in some circumstances multiple paradigms would reduce the code size or maintenance effort by a few percent, but is it worth mixing paradigms to get this few percent? It may take twice the training to get that few percent. IMO it is best to learn a few orthogonal tools well than to learn many semi-overlapping ones in mediocrity. Perhaps if programmers lived for 500 years I would change my mind.

There is also an argument that it is impractical to focus on only one paradigm to the exclusion of others. Most programmers have little problem mixing procedural, functional, relational, OO and all sorts of other stuff within a system. Purists may object to some of the mixings, or argue that the ConceptualIntegrity suffers, but people who just want to get things done in the simplest way rarely suffer the supposed problems.

I don't understand what a good set of "orthogonal tools" would be, but using multiple tools with overlapping functionality is not a bad thing. Refusing to learn Java just because you already know C++ would be idiocy, as would refusing to learn about alternative persistence mechanisms just because you already know about relational databases. It doesn't take 500 years to become proficient with a wide range of methods and tools. SpecializationIsForInsects.

Often, the justification for avoiding a mixing of paradigms comes down to "I understand paradigm A, but I don't understand paradigm B. Therefore, we should use only paradigm A."

You seem to be bragging that you can master everything and that everyone else should therefore do the same thing. I find that some approaches/paradigms feel "natural" for me and some don't. Many others seem to be the same way in my observation. They gravitate toward certain organization techniques that best fits the way they think. I suspect that an Everything Person like you claim to be is relatively rare. IOW, I don't buy your argument, at least not in the macro sense.

I'm not bragging; most developers I have worked with are capable of mixing paradigms and of knowing more than one way of doing things. It's my experience that the Everything Person is more common than the One-Thing Person (except among recent college grads). Using a variety of approaches is often the best way to solve a set of related-but-different problems. Trying to squeeze all solutions into one paradigm is unnatural and limiting, as is trying to force all members of a team to think the same way.

It is not all-or-nothing. It may be that a few paradigms can cover a pretty wide area. Plus, companies want PlugCompatibleInterchangeableEngineers. Lack of orthogonality means more expensive training. (Although companies may overdo the plug compatible thing, I do see some of the logic in it from their standpoint.)

An object A contained in B, which "thinks" it's in C may exhibit behavior which is appropriate in C, but not in B...like an play actor. This system does not exhibit SymmetricalReference.

What does this have to do with MixingParadigms?

Suppose that operations on the container of an object such as 'copy', 'divide', 'embed', reflect in the contained object. The features of the object in B are partially determined by B. To command an object A in paradigm B, syntax and semantics must be relative to A as in B. If commands are not suited to A in B but to A in C, they will fail if A is actually in B, because A will not be the kind of thing it has to be to satisfy the command. If MixingParadigms, both B-relative and C-relative commands work. The discussion above is concerned with the problem of managing objects which have different reflected properties at different times. It is conceivable that an object will have B given properties which are incompatible with C given properties. In such a case, a command to A might tell A to do two things at once that cannot be done at once, or that can be done at once but toward conflicting ends.

This appears to be saying "Components designed under different paradigms may be incompatible". Such fears are common, but are often unfounded.

A paradigm is something that a person uses. The comment assumes this. The above paragraph, I think, however, makes use of "paradigm" in an odd sense. It presupposes two things: that some linguistically constructed objects are like people in that their behavior is constrained in definite ways because they are the kind of thing that they are. And it requires that the kind of thing that a person or object is depends partly upon context, real or program bound. Mixing paradigms then means being two kinds of person or object at once, and that means potentially behaving in incompatible ways. A program may call the same object from different contexts (simultaneously or not). If the object introduces something into one stream, something different into the other, when the program integrates the streams, bugs might come.