Clarity vs. code reuse/generality

[David Smith]

kj wrote:
> In <7x4otsux7f.fsf at ruckus.brouhaha.com> Paul Rubin <http://phr.cx@NOSPAM.invalid> writes:
> 
>> kj <no.email at please.post> writes:
>>>     sense = cmp(func(hi), func(lo))
>>>     assert sense != 0, "func is not strictly monotonic in [lo, hi]"
> 
>> bisection search usually just requires the function to be continuous
>> and to have its value cross the target somewhere between the endpoints,
>> not be monotonic.
> 
> Try the algorithm I posted with lo = -pi/4, hi = 2*pi, func = cos,
> target = -1, and see what you get...
> 
>>> I regard the very special case of func(hi)==func(lo)==target as
>>> pathological (analogous to the fact that a stopped watch is "exactly
>>> right" twice a day), and not one I care to support.
> 
>> I do think you should support that case, under the "do 'nothing'
>> gracefully" principle.
> 
> You keep missing the point that this is an *internal* *helper*
> *convenience* function, meant to abstract away common logic from
> a handful of places and thus eliminate some code repetition within
> a module.  It is *not* a library function intended to be called
> from elsewhere.  So talk of "supporting" anything is besides the
> point.  Any internal use of this function that applies it to a
> non-strictly-monotonic function is, by assumption, an error.
> 
> kj

First, let me say *I got the point*.  I use asserts, but only in unit
testing where I want to test the result of some action for correctness.
 In the course of programming product code, I personally don't think
they should ever be used exactly for the reasons everyone else is
pointing out.  They can be disabled with the -O option and that changes
the program's behavior in ways that could break in production.

If you insist on teaching the assert statement, teach it in the context
of writing unit testing code.  Its an extremely valuable skill.

--David