[erlang-questions] Trace-Driven Development

[Ulf Wiger]

On 5 Jun 2012, at 09:47, Michael Turner wrote:

> All I know is: if that's what you're doing, that's
> what you should call it.

An alternative, as I expanded on in my last email, which I sent just 
before reading this one, is that perhaps they should be doing something
else instead. Seq_trace is not well understood for the purpose it was 
intended for. It should perhaps be reworked entirely.

If so, it does seem like a good idea to change seq_trace to 'lamport',
make it clearly a generic implementation of Lamport clocks, for 
whatever purpose.

This could be done today. As it affects the VM, it should be an EEP, I think.
The initial implementation of 'lamport' could be completely based on 
seq_trace, but renaming functions and changing the documentation so 
that it clearly references relevant papers and illustrates how it could be 
used. It ought to be perfect for e.g. "model tracing", similar to what 'et'
does (another API that is woefully under-used since the documentation
turns people away). Code could be inserted as "executable comments"
basically indicating "we are now in <this state> in the model". With such
code in place, one could do quite sophisticated visualizations of a 
running system

It doesn't seem like such a module ought to have a system_tracer()
function. Rather, tracing on Lamport clock events should then be 
more intuitively integrated into the tracing BIFs (halfway there already).

Actually, 'et' handles seq_trace events and processes them for use in
the visualization. However, the documentation doesn't make the 
connection. The seq_trace events are included in the type signatures,
but never mentioned elsewhere.

This is interesting. It seems as if 'et' could rely entirely on seq_trace.
Instead, it more or less mandates global tracing. Why?

> And speaking of what to call things: I don't think you should still be
> calling seq_trace "beta", if (as Ulf says) it originated ca 1997.  I'd
> do the interface differently, but the more important thing to me now
> is stability and correctness.

I agree this is a problem, like with parameterized modules. You shouldn't
have beta or unsupported features lingering for years. Either make them
supported or remove them and possibly provide something better.

BR,
Ulf W

Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.
http://feuerlabs.com