Intention Not Algorithm

We might also say, WhatNotHow, or WhyNotHow?.

The most important thing about any (without loss of generality) method is what it accomplishes or why one would call it, not how it does whatever it does.

Yes, as I've said so many times, IntentionalityAndHermeneutics? are all there is to good code. Any ideas why this catch phrase hasn't caught on? Perhaps because few know what hermeneutics means (or how to pronounce it) without a dictionary. -- AttributionMissing?

The above was previously attributed to SethKlein. Is there a reason why it has been changed to AttributionMissing? -- WikiGnome

Note also that the How of this level becomes the What/Why of the next level down.

Also could be called PolicyNotMechanism? (as opposed to MechanismNotPolicy).

Isn't the name of the method the intention and the body of the method the algorithm? Shouldn't one be able to determine the intent from the algorithm and vice-versa? Another restatement of this would be that "If the intent and algorithm diverge, there is a problem."

But the intent is not always sufficient to determine the algorithm. My intent may be to sort a list, but the algorithm I use may be crucially important. Others may wish to call a sort method, why should they have to say "Sort_with_quickSort" or "Sort_with_smoothSort"

In this particular case, intention alone is insufficient - algorithms are a necessary addition.

Actually, intention is sufficient, it is, however, incomplete as stated, since intention includes whatever we think is important. The full intention is "sort with such and such attributes, such as stable/unstable, importance of simplicity vs speed, data is random versus might be mostly sorted, etc."

[This is where testing comes into play. One can select any algorithm that meets the requirements of the test. It is too unwieldy to name a method in a way to identify every important characteristic, but it is equally inappropriate merely to identify one specific algorithm as the one and only solution. Alternative algorithms probably do exist that solve the problem as well or better than the one initially chosen.]

Au contraire. For instance, how would testing help with the intention that the sort use no extra space? (Merge sort of arrays needs O(n) space, by contrast.)

Testing isn't likely to assert complexity requirements in time *or* space. I'd assert that such things are irrelevant to the correctness of the implementation from the point of view of the client code. In the end, your choice of algorithm may be motivated by time or space requirements (if we're in the embedded world, then space complexity is often a make-or-break factor...), but specifying that is unimportant from the point of view of client code. The client code wants the list sorted.

Perhaps so, but the client's requirements have specified a substantial list of needs that must be met, and sorting is only one of those needs. Both space and time figure into the assessment of which algorithm will be implemented to accomplish the sort. Unless the intent is stated in such a way as to specify the space and time constraints (as is typical in an embedded environment) then the intent is insufficient to describe the algorithm to be used. If the intent is described to that level of detail then the client is elbowing into our terrain and needs to be reminded that We Are The Ex-Spurts and such technical matters are best left to professionals. [cough]

Above: Except for linear_insertion_sort and binary_insertion_sort--which are really only used as the initial or final stage of another sort anyway--you should never need to specify the mechanism of the sort; you can instead use calls to things like stable_sort [TimSort, MergeSort], stable_sort_constant_mem [WikiSort?/BlockSort?], unstable_sort [Production-quality QuickSort, or TimSort with element-run requirements relaxed], numeric_sort [RadixSort], stable_sort_adaptive [TimSort], unstable_sort_adaptive [TimSort, SmoothSort], and so on.

See: IntentionRevealingSelector, WhatIsIntent