<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000066">
<font face="Calibri">Should there be any interest I would like to
discuss tracing and if it may be more valuable for the actor model
than unit tests.<br>
<br>
A couple of days ago, during Jesper Louis Andersen's very
enlightening debugging and tracing tutorial at Ericsson, Joe
Armstrong asked whether showing visual traces <i>first</i> may be
a good approach to <i>teaching</i> Erlang, book-side.<br>
<br>
I would like to propose again that trace-driven development may
possibly be <i>the</i> way to teach andalso <i>program</i>
Erlang. <br>
<br>
In the instance, we were talking about visual traces, like these:<br>
<br>
<a class="moz-txt-link-freetext" href="http://www.erlang.org/doc/apps/et/coffee_order.png">http://www.erlang.org/doc/apps/et/coffee_order.png</a><br>
<br>
</font><font face="Calibri">I mean it in the slightly unrealistic
way that most people probably appreciate test-driven programming
as a great idea but seldom execute it as dogmatically as preached.<br>
<br>
But I realize that what I <i>actually</i> do when programming a
new app, or when looking for truly nasty bugs, is almost always
pretty 'trace-driven'. Writing traces into the program has become
a routine step for me when coding medium complicated stuff that
uses supervisors, monitors and multiple process that come to live
at various times throughout the lifetime of an Erlang (OTP)
application -- and most of all, during the <i>start up</i>. And I
have always found surprises, which process comes to live when. I
think Jesper related a similar story how they found tons of bugs
that no-one had realized were there when using tracing (not sure
any more.)<br>
<br>
I believe that the main aggravating factor is that you don't
construct an OTP application from scratch </font><font
face="Calibri">that often. You'll have to look things up again
every next time. My guess is that this is true for the vast
majority of Erlang programmers. Of course, for the ultimate
expert, it may be hard to grasp what I am even talking about
because it's all so 'obvious'.<br>
<br>
But what I really find myself currently doing, before writing
tests, is writing traces. I also haven't found out how to plan out
and write meaningful stateful tests up front, before I even made
it to architect the application.<br>
<br>
My concrete order is: writing first, get to compile, put in
traces, try to run, debug.<br>
<br>
I am so sure meanwhile that I will need the traces that I don't
wait anymore until I have gotten lost in searching for a bug and
not even knowing what happens before the crash and what parts of
the program may have silently died and what other parts may have
waited for which other part. <br>
<br>
These things will be obvious for expert Erlang programmers who
have set up applications time and again. But few people using
Erlang for productivity reasons will <i>ever</i> come into that
position. And for finding bugs: that's exactly the moment when
reality doesn't follow your fantasy and a reality check in the
form of a trace is one of the first tools to turn to. Is it not?<br>
<br>
So trace-driven development sounds like it could be a useful
recommendation. And if it is, a new best practice of waterfalling
your application into existence could maybe emerge, similar to
what Joe describes in his book (if I remember well) how he almost
always starts out.<br>
<br>
I learned a lot in Jesper's tutorial. For example that because
Erlang and OTP keep growing, there are now three distinct
mechanisms, with respective modules and function calls, to trace
and debug. And despite me using traces a lot, I hadn't used any of
them, for the wrong reasons it turned out. (And for productivity,
a simple io:format can beat getting tied up into using more
powerful but less simple minded options.)<br>
<br>
So I am asking this out of honest ignorance:<br>
<br>
Instead of tracing, is there a way to write meaningful, concise
tests that are meant or at least good for checking the sequence of
process communications? In other words, are there better
alternatives to follow traces with the naked eye? I do not mean a
heavy construct, or an also-possible use, but a test-package made
for that and/or a useful practice that someone is in fact
applying?<br>
<br>
And it need not be the visual traces as the image linked to above.
A ping-pong output in the terminal may do (if not skewered by
delays or re-sequences or contentions in io:format.)<br>
<br>
For trace-driven development, what concrete procedure with which
concrete calls and parameters to erl can be a best practice for
starting out? I am sure it' s 'obvious' for many, but at least for
me, not. What could be the hello world case for a trace-driven
approach?<br>
<br>
And finally, how do <i>you</i> approach setting up a new app,
finding a bug -- how much tracing does everyone use in these
things? And is anyone also using io:format instead of the OTP
goodness, if so, for a good reason?<br>
<br>
Best,<br>
Henning<br>
<br>
<br>
<br>
</font>
</body>
</html>