Debugging is a hard task, because either too much is hidden (this is when we want to invoke the debugger), or too much is visible (this is when we give up on tracing the problem through the debugger, and resort to print Data::Dumper::Dumper($thing) every few lines of code).
Given the complexity of layering in todays programs, lets take a web app for example (search for __skip__ if you want to skip): request enters glue code to environment MVC framework builds request object controller actions dispatch, object moves around model queried, changed view dispatched request luggage data munged, or model requeried template module invoked This involves, framework code, we typically don't care about, which in turn is just glue around other frameworks and libraries: - our POOP library - on top of DBI, which we also don't care about - lots of hackery to create an OOP data view - lots of lazy accessors, doing big work under the hood - our template library - uses a bajillion plugins, probably - uses has a complex pipeline, to process a template, with caching (memory, files), translation, parsing, inlining, and outputting, like any modern system - our environment glue library - mod_perl / CGI - HTTP::Headers, etc We are also introduced with a new control flow paradgim, probably one of: - a run loop - callbacks - continuations - beh __skip__ programs that are written by the user are hard to debug. Lots of the code actually being run is far from the code that we wrote. In this day and age of complex application writing debuggers are hard to get right. Lets briefly discuss their evolution: 1. machine code dissasembly + tracing 2. source debugger ... That's where they stopped i think. The big distinction between the two is that the latter is at the user's level - it discusses the thing that the user wrote. The next step is to allow a debugger to hide library code when it's beyond what the user cares about, since although it's at the same level, it's still not what the user wrote. I think the way to do it is to make a debuggable role, which knows to provide a million and one hooks to the thing that `does` it. Aside from that, I don't really know how to think farther. The two implications I'd like to see: 1. Code ownership marked at runtime: Framework providing several levels of how to skim through control flow. Probably usually boolean (calls within a namespace omitted). Also defines a policy about instance data it filled in, and so forth. This allows the user to skim through only their code, or only some of the libraries mechanisms if that helps. 2. Data summarization Complex structures should know how to display themselves well to a debugger. Of course, for this stuff to work, it has to be part of the grand unified tracing and introspection capabilities Perl 6 will offer a debugger writer. I'd like to see this in use by N debuggers, possibly with a role like mechanism (in a graphical debugger some objects may know how to draw themselves). Also, lets remember not to hinder full transparency. Furthermore, full transparency should, again, not be all or nothing. I believe developers will be tempted to write implementations of the Debuggable role, since they will probably use these tools to debug their own code anyway ;-) Adios! -- () Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker & /\ kung foo master: MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM: neeyah!
Description: PGP signature