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!

Attachment: pgp6DQYqPlvr8.pgp
Description: PGP signature

Reply via email to