[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-
>