[erlang-questions] Trace-Driven Development

[Michael Turner]

Michael Truog:
"The tendency to use print statements is a habit from other languages
and is often the common denominator when debugging, so making tracing
as simple as a print statement (documentation-wise and usability-wise)
seems like a sensible goal."

A very sensible goal.

Early on in using seq_trace, I mixed the styles, but it was annoying
because my io:format() calls resulted in message passing in the io
module, which got traced by seq_trace when tracing was on, and my
trace collections were often trashed with distracting stuff about io.
Clearly, I needed some way to filter my traces, or I had to give up
print-statement-style tracing. But because I'd been scared off of
trace-matching, and didn't want to give up prints, I decided instead
to write something like this, in my improvised layer over seq_trace
called "ts":

format(Fmt,Args) ->
    Save = seq_trace:set_token([]),  % turn off tracing, if it's on
    io:format (Fmt, Args),
    seq_trace:set_token(Save).  % turn tracing back on again, if it was off

Wherever I had an io:format call in my code, I replaced the "io" with "ts".

This is just a stopgap. My ts can't wrap everything in OTP. It shows
only what a relative Erlang newbie (i.e., me) would do with a
non-mainstream tracer package (seq_trace) while grappling with a mix
of styles. And that I mixed styles is probably important too: I think
newbies will want to cling to the old life-preserver while they grope
for the ladder. Unless I'm out in left field yet again.

-michael turner


On Wed, Jun 6, 2012 at 11:47 AM, Michael Truog <mjtruog@REDACTED> wrote:
> On 06/05/2012 05:40 PM, Henning Diedrich wrote:
>
>
> One Open Source loving word regarding the 'hell' quote:
>
> I'm hardly the only one who should be embarrassed:
>
> "Erlang tracing is a seething pile of pain that involves reasonably
> complex knowledge of clever ports, tracing return formats, and
> specialized tracing MatchSpecs (which are really their own special
> kind of hell). The tracing mechanism is very powerful indeed, but it
> can be hard to grasp."
>
> Obviously, that kind of statement has no place in the official
> documentation of a professional product.
>
>
> Honest statements like the one you are citing may be the actual luxury and
> strong value of Open Source efforts, which are not directly a commercial
> product. Possible only because they /are/ not a product. For one user, fresh
> air like this only creates trust and allows to (even very precisely) set
> expectations and alertness to shortfalls in both documentation and package.
>
> That is not to paint the situation rosy, it would be lovely if it was
> better. But I appreciate the honesty, very much.
>
>
> I agree that honesty in the documentation is much more beneficial, due to it
> being Open Source, rather than the duplicity that might otherwise be present
> in corporate documentation ("Politics-Oriented Software Development":
> Documentation, http://www.kuro5hin.org/story/2005/1/28/32622/4244).
>
> The issues mentioned previously in the email thread seem to indicate that
> Trace-Driven Development would require more documentation and details,
> especially documentation that is immediately relevant to the beginner.
> Putting redbug into OTP seems like it would help reduce the learning curve,
> just since it is the popular approach to Erlang tracing and has existed for
> some time.  The goal with such changes would be to make tracing simpler in a
> way that discourages the natural programmer reaction to information
> discovery during interactive debugging (of systems that are not yet live),
> which is inserting print/logging statements.  The tendency to use print
> statements is a habit from other languages and is often the common
> denominator when debugging, so making tracing as simple as a print statement
> (documentation-wise and usability-wise) seems like a sensible goal.
>
> - Michael
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>