[plt-scheme] ATTN: Neil Van Dyke (and some philosophical musings on debuggers)

Will try, as I'm not familiar with Chez Scheme's debugging facilities.

> From: Matthias Felleisen <matthias at ccs.neu.edu>
> Date: Thu, 16 Sep 2004 17:28:27 -0400
> To: Paul Schlie <schlie at comcast.net>
> Cc: <plt-scheme at list.cs.brown.edu>
> Subject: Re: [plt-scheme] ATTN: Neil Van Dyke (and some philosophical musings
> on debuggers)
> 
> Please get your hands on Chez Scheme. It's not cheap, so go to a
> university close by and see whether you can find one there. It comes
> with a debugger that you'll love. Play with it. Let me know -- Matthias
> 
> 
> On Sep 16, 2004, at 4:51 PM, Paul Schlie wrote:
> 
>>   For list-related administrative tasks:
>>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>> 
>> For the hell of it, my basic thoughts are that a debugger's critical
>> role
>> in life to enable the programmer to more easily disambiguate between
>> what
>> they meant, vs. actually expressed; as we all know it's often more
>> difficult
>> than may appear at first glance/attempt; often because input domains
>> are
>> more subtlety complex than originally perceived, resulting in
>> unintended
>> result ranges or discontinuities which may or may not OBSERVABLY
>> violate the
>> input domain assumptions of dependant expressions of intended behavior.
>> 
>> I've HIGHLIGHTED "OBSERVABLE" because the critical functionality of a
>> debugger must be able to enable the programmer to "OBSERVE",
>> experimentally
>> "CONTROL", and ideally alter, any arbitrary expressed behavior within a
>> program to aid in the identification and corresponding refinement of
>> desired
>> expressed behavior to increasingly comprehensive input domains, without
>> having to alter the program itself to do so.
>> 
>> As data invariably affects conditional control flow, which in turn
>> affects
>> dataflow, and therefore state; a debugger must then also ideally
>> enable the
>> control flow state and history to also be both observable, and
>> controllable
>> to aid in the programmers identification of their insufficient or
>> erroneous
>> expression of intent beyond the programs natural points of observably
>> and
>> controllability.
>> 
>> Although contracts assist in the confinement of anticipated data
>> domains
>> and ranges; they are themselves expressions subject to programmer
>> errors,
>> nor do they attempt to typically quantify the correctness or the value
>> discontinuities of transformations that exist between their
>> boundaries, as
>> if they did, would be fully redundant to the transform descriptions
>> themselves.
>> 
>> Although I profess to being strongly biased toward the scheme
>> programming
>> language/style, most/all scheme programming environments severely lack
>> any
>> comprehensive debugging (arbitrary program/data control/observably)
>> facilities; as such, they often relegate the task of "debugging" to the
>> programmer's own wits, which often limit's the commercial use of
>> scheme to
>> relatively simple problems, academic exercises, or the curious; as
>> without
>> a reasonably comprehensive means to observe, isolate, and remedy
>> "bugs" in
>> reasonably complex programs with correspondingly complex datasets, it's
>> difficult to leverage in environments where programmers are use to,
>> and rely
>> (for good or bad) on such conveniences. I for one would love to have
>> access
>> to a more nimble way to arbitrarily observe, control, and refine the
>> behavior of a scheme program, and spend less time (often invasively),
>> making
>> due otherwise (as if I knew how to always comprehensively express what
>> I
>> meant with sufficient precision, I would, but admit to not being
>> omniscient).
>> 
>> No prejudice, conflict, or disparity intended, just my two cent
>> thoughts,
>> 
>> -paul-
>> 
>