Mutually Inclusive

When reading a page which is supposedly a comparison of two methods, whether they be of editing, reading, writing, programming or other artifacts, often presented are the strengths or weaknesses of one or the other. The supposition is that one might use the information to select one over the other. I propose that rather than considering "exclusion" exacting a cost of losing something valuable, that it is possible to be inclusive, not ruling out the use of the supposedly "inferior", or "less desirable" choice. Thus, when comparing such things as Wikis versus Blogs, or Vi versus Emacs, in fact one may usefully employ both involved in the comparison. There are benefits to be gained from supplying the strengths for which each is known. -- DonaldNoyes 20071126

I don't see that the XVsY pages support only a mutually exclusive position. E.g.

ApiVsProtocol is quite balanced
AwikiOrAblog provides a synthesis as an option
CgiVsServlet shows that the two are identical under a certain view and even ends with that they address different needs.

So either you overstate or WikiWiki is a bad example:-) Or maybe my sample is too small.

Otherwise I agree that one should be careful with mutually exclusive positions in general. I would even go so far as to state that there is no binary choice but often a continuous solution space and one can find ones sweet spot in the middle. -- GunnarZarncke (yeah and I already hear you David: "Gunnar and his vagueness.")

When you're working with digital software, solution spaces only appear 'continuous' from afar. Up close, they're quite discrete. But even up close, they're rarely binary. Anyhow, I only see a real problem where two tools really do compete to occupy the same niche at the same time. There are a lot of 'versus' pages that involve nothing of that sort. E.g. 'ApiVsProtocol' - these are different things and don't at all occupy the same space. There are often protocols for using APIs... e.g. initialization and finalization and setup code. And there are often APIs to support protocols. Dropping them into a boxing ring and declaring competition between them is just silly, though moderately entertaining.

I agree that the continuous spaces can be 'made' discrete as needed. I didn't bring up the versus pages. Donald did. It was meant as counter examples to his thesis. The problem of the same spot at the same time depends on what is 'same'. I guess that is what would need clarification. -- .gz

I wasn't talking about actual continuous solution spaces, so I'm having troubles figuring out what you think you agreed to. Unless you deal in analog computation and analog source-code, there are no continuous solution spaces even in theory. With digital software - software written or executed using 'characters' or 'bits' - there are only discrete spaces. There are no UnknowableNumbers. Ever. These discrete spaces just appear continuous from the 30,000 foot view - but that's an illusion, like frames in a flip-book producing what appears to be a continuous action. It is not a reality. The mind may model digital software solutions as fuzzy and continuous, but the mind is wrong. If anything is 'continuous', 'fuzzy', or a little 'vague', it's likely the problem-space, not the solution-space.

Anyhow, 'same niche' or 'same task' is however you decide to describe the task. If the task is 'hand-editing C++ file xyz.cpp today' or even generically 'editing C++ source code' I see very little need to learn, utilize, MutuallyInclude both 'vi' and 'emacs' (and nano, textpad, write your own editor, IDE editor, etc.) to do so - the benefit isn't anywhere near sufficient to the cost of obtaining and learning and lugging around the wide array of tools. Therefore 'emacs vs vi vs roll-your-own' is a very legit question - you need to make a choice prior to editing source code. You need to obtain and learn the tool(s) you choose well enough to perform the task. Of course, you can change your mind, and learn or create other editors later. But being MutuallyInclusive about it is entirely impractical as a principle.

Other things like ApiVsProtocol aren't associated with the same tasks. A protocol, simply put, is a predictable pattern of communication with predictable consequences. An Api, simply put, is an interface for integrating modular source code. They're completely different abstractions, and are standardized for completely different reasons. Thus, since there is no single 'task' they both compete to fill, a big argument about ApiVsProtocol and which should be standardized is rather pointless (though perhaps enlightening to those who don't already comprehend the difference). For things like these, being MutuallyExclusive is simply a misunderstanding of the principles involved.

Thus, since MutuallyInclusive is impractical for tools you need to make a decision on (especially when taken beyond binary decisions), and being MutuallyExclusive is just a misunderstanding for tools where both are needed, I'm left feeling that 'MutuallyInclusive' isn't a worthy concept. Unlike 'Encapsulation' and 'Actor' and 'Golden Rule' and 'Computation = Calculation + Communication' and 'Law of Noncontradiction' and 'Occam's Razor' and others, 'MutuallyInclusive' simply doesn't get a place on my list of useful principles. I find myself unwilling to... include it mutually.

Discussion about the tradeoffs of using multiple alike tools:

When you are comparing two utilities that provide the same service, the cost of learning and employing both is rarely greater than the benefit of utilizing one where the other shows slight weakness. Wikis vs. Blogs, at least, are not at all the same service (Wiki is a medium, and may be a medium for blogging). I doubt you'll find the same is true Vi vs. Emacs when utilized in their capacity as editors of text and source-code.

The point I am making is that in the choice of exclusively employing one vs the other, choice is made to exclude something, whether it involve the same, or different services, as well as different environments, different times, or different users. In an age that values "diversity", "openness", and "freedom of choice", is ironic that some still employ "exclusion" of useful alternatives, whether it be because one may expend time and resources in "learning" how to make use of them or other excuse. Use the pages found in the CategoryComparisons, (particularly those employing the term "Vs" in their titles) when deciding that it can be quite useful on occasions if not frequently to be "MutuallyInclusive"

Any choice always selects a few possibilities and excludes all others. Freedom to choose is freedom to exclude. And you'll have to excuse me for thinking you a hypocrite when you call time and resource expenditure an unidealistic "excuse" for making a choice. Shouldn't you be busy MutuallyIncluding by writing your own editors (one choice), learning Vi (another choice), learning emacs (yet another choice), etc.? Don't you value "diversity"?

Write your own editor? Yes, I have. I didn't mean to make it about me. But I speak from the experience of being MutuallyInclusive. When I am using Linux, I use both Vi and Emacs, When I use Windows Xp I uses NysEdit?, Textpad, WordPad?, MicrosoftWord, when I am developing software, I use the editors supplied with the compiler or development system as well. The choices I make in being inclusive is an additive process. I add to what I can use. My computer is filled with thousands of programs and 100s of Gigabytes of computerArtifacts. These are the result of "inclusiveness" combined with a desire for preservation of artifacts, including those which have fallen out of favor and have been superceded by later developed artifacts. I can appreciate that some do not have the luxury of doing so, for many reasons, and are forced to make compromises which their circumstances and equipment may impose. Nevertheless, I believe the process of inclusiveness and adding to ones exposure to various alternatives to be a GoodThing.

You seem to be a collector. I suppose if you cherish diversity for diversity's sake, you might call an enormous piles of unique but functionally identical hammers a GoodThing. Stamp collectors say the same of their stamps, and coin collectors of their coins. Most people, however, benefit not at all from frivolous choice; a standard claw hammer, a rubber mallet, and perhaps a ball-peen hammer are all they'll ever need. For text editors, people need certain functional services: reports, letters, scratchpad, source code editor, story authoring, etc. - and there is rarely a benefit in having two tools in the toolbox for purpose of the same job. No need for Textpad as a scratchpad if you use Wordpad as your scratchpad. I can appreciate diversity where it provides choice, artistic value, or aids where one size really doesn't fit all. However, I am not a collector; I do not believe that diversity for its own sake is a GoodThing.

I don't use, because I don't own a ball-peen hammer, even though I made one in a metal-fabrication class in high-school. It may be because I use a hammer mostly to hammer (and pull) nails, and do none to little metal-working. I usually leave that to others.

This might be said of most of the (software) artifacts one might collect or preserve:

ItWorks (now)
One has used it sometime in the past and can visualize a use in the future
One has room to keep it and can find it if needed.
Others have said that it is good, if not the best of its type. (this for things which haven't but might be used)
One might have the same thing in two places because they are used there. (Thus one might have the same type of screwdriver in the garage toolbox and in a kitchen drawer)
One shouldn't consider what the collection "stuff" that must continually require more physical space. (having room for artifacts is no longer expensive and requires the same or less physical space as time passes.

One can say the same thing of any particular hammer; there are no problems with doing so unless one attempts to keep also every prior hammer that 'works', has been used once and might see use in the future, and that has been called the best of its type. One ends up with a giant pile of hammers only if one isn't willing to obsolete hammers that no longer provide a useful function after new ones enter the pile.

You focus on space, but (given rising disk space, and ignoring money) time is certainly the more precious resource regarding software artifacts - time to learn to use new software sufficiently well that it advantages one over other software. If you use two pieces of software the same way to the same effect, one doesn't need to spend any time to learn it... but one also doesn't gain any advantage: the same things are done the same way. Advantages are only gained if one can do the same thing more easily or can do a new thing, and it takes time to learn either. People simply don't have time to learn all the 3D studio software out there (Studio Max, Blender, Cheetah, Houdini, LightWave), all the different Compiler utilities or IDEs (Borland, VC++, Metrowerks, etc.), all the different word processors (MicrosoftWord, OpenOffice, AbiWord, etc.), etc. etc. etc. And that's even ignoring roll-your-own solutions, which takes far more time and training.

If what you are saying is, "find the one thing which will do the thing you require and use it", I agree. What I am saying is that if you have not, then find it and use it, at least once. Then if you anticipate future uses, include it by preserving it in a place you can find it.

At some point you'll need to select one or a few solutions from the near-infinite set of possibilities. At some point you'll need to become exclusive. That's what I'm saying. You can delay the choice, but you can't avoid it. If all you're saying is 'attempt foresight' and 'be prepared', I'll offer partial agreement (though YouAintGonnaNeedIt and AllThingsInModeration? should be reviewed, too). But the impression I received from what you are saying is that, given multiple (at least two) possibilities for doing the same function (e.g. emacs, vi, roll-your-own editor), one shouldn't make any real decisions... that, rather, people should just sit around on the fence and collect software options like packrats because any real decision always involves exclusion. With this I disagree.

I do not and did not advocate "not making any real decisions" or that "one shouldn't make any real decisions" when I say clearly:

"find the one thing which will do the thing you require and use it"
- if this involves trying different artifacts in differing situations and taking the time to determine usability, so be it.
"if you anticipate future uses", (of what you have used and found functional(at least once)), include it by preserving it in a place you can find it."

I find beauty in simplicity and orthogonality. One toolbox shouldn't have two tools that do the exact same job, or even unique tools to do jobs for which a pair of tools already exists unless the unique tool provides some rather magnificent improvement. There only needs to be one good way to do 'it', whatever 'it' happens to be. Perhaps this is because I'm a language-designer; I view the gestalt toolbox, not the individual tools.

A toolbox is a perfect example of a collection of useful artifacts. One may in the case of the tools included have more than one kind and size of screwdrivers based upon the screw driven. One used to tighten the miniature screw in an eyeglass is different as well as necessary as is one designed to drive a screw of 1/4 inch diameter. The important thing is that "ItWorks" and that you will have found that "it will do the thing you require". The important thing for the tool-box designer is to make sure the tool can be found when needed for use.

I have to agree with both of you: There is nothing wrong with learning and using mutiple alike tools if history so happens. But I'd also prefer the right, preferrably the ideal tool for the right job. And for efficiency: Even thinking about the ideal tool costs your time let alone building it. -- .gz

Compare for MutualExclusion

CategoryComparisons