[erlang-questions] Trace-Driven Development

[Ulf Wiger]

On 4 Jun 2012, at 17:10, Michael Turner wrote:
> 
> The copyright on the manual starts with the year 2001. Over two
> decades after Lamport famously wrote, seq_trace implements exactly
> what's typically described, and the AXE document -- which doesn't
> supply nearly enough detail to verify independent invention -- is the
> best you can offer as evidence of independent invention?

Well, FWIW, it was introduced before 2001. I'm guessing 1998
or even 1997 (OTP R4, I believe).

Listen, I tried to politely point out to you that the *requirements*
for sequence trace in Erlang grew from Ericsson developers'
experience using "forlopp tracing" in AXE. Much like Erlang itself
was created - as Joe has described it - as an effort to "make something
like AXE, only better".

This is also why it is called "sequential tracing" (let's call this an
educated guess, as I was not part of the naming discussion,
although I *was* in the loop when the requirement came up).

The people who asked for the feature, and helped finance the 
development of it, did not ask for Lamport clocks - they asked for 
something like "forlopp tracing" in AXE. "Forlopp" is a bastardization 
of the Swedish word "förlopp", which means "sequence". In the
world of AXE, it was a way to associate events to a "transaction",
which could be restarted if something went wrong.

Sequence tracing was therefore a perfectly logical thing to call
it in Erlang, as it is one of the correct ways to translate "forlopp
trace" to real English.

There was no deceit, sloppiness or arrogance behind it.

I have told you that the details of AXE's implementation are 
proprietary. I provided one link to a document that *was* publicly
available, and that mentions "forlopp tracing". Take that as a
form of existence proof of "sequence tracing" in AXE.

As for "independent verification", am I to understand that I'm being
chided for not revealing secret Ericsson design details in a public
forum just so you can independently verify my claims?

(However, ordering may not have been a terribly difficult problem
to manage in AXE, as it was a single-CPU system, never distributed.
When the OTP team implemented similar support, obviously they
had to make something that worked in a distributed system).

>> A question is of course how many people are helped by the seq_trace
>> documentation mentioning the relation to Lamport clocks. Some might,
>> but others couldn't care less; they just want to know how to use the
>> functionality.
> 
> OK, so now the defense is "who cares who invented it?" There is reason
> to care. When there's decades worth of literature referring to its
> uses, *everybody* should care. Anything else is an encouragement to
> reinvent wheels.

I did agree that the reference to Lamport clocks could be added to
the documentation, since it is not without interest. The one thing
I don't agree with is that the OTP team deserves infamy for not 
having done so already.

When publishing research, it is extremely bad form not to mention
prior art. When writing a user guide, one has to consider whether 
describing details of the implementation actually helps the user,
*and* whether those details are something one wants to commit
to as part of the interface.

I hope you can appreciate the difference:

- Kenneth agreeing on a mailing list that Lamport clocks are used
  is a service to the community, but not a commitment to stay with
  this design choice indefinitely (not that I think there are that many
  other good ways to do it).

- Inserting details about the implementation in the Reference Manual
  elevates that information to become part of the interface.

Another, perhaps more appropriate, place to insert the reference is
as a comment in the source code. It isn't there, however.

Granted, the interface *as described* pretty much commits to Lamport
clocks. It does seem reasonable to mention that, although I'm still
not convinced that many will find it that helpful.

> As it happens, so far, I haven't used the Lamport's relative timestamp
> feature. But I'm coming up to the point where the fact that they help
> describe a partial ordering of events is an essential part of my
> testing. I *will* be looking to the literature to see what's been done
> on this subject. Who wouldn't, given that people have over 30 years of
> experience with it now, and must have written about it?

Perhaps this thesis can be of interest then?

http://www.student.nada.kth.se/~nstahle/staahle_niklas.pdf

(Interestingly, the thesis project was run at Ericsson, on real-time
'transaction' or 'sequence' tracing. While it mentions Lamport and
a few other techniques, it fails to mention that both the AXE and
Erlang - both established Ericsson technologies at the time -
already supported this feature. ;-)

>> The OTP team is known to accept patches to the documentation,
>> so please feel free to contribute to a more helpful way to describe
>> the tracing support. I'm sure it would be universally appreciated.
> 
> The one time I tried to get a patch into anything in Erlang (something
> that was causing a build under FreeBSD to segfault), it didn't make it
> into the next release -- even though other people helped get it into
> shape for submission. Pardon me for being a little leery of the
> process.

Patching can be pretty hairy, but note that patching the documentation 
is much easier than patching the emulator. ;-)

> And I suggest that you NOT take the opportunity to add any supposed
> "history" about how AXE implemented Lamport clocks until you can
> demonstrate that it did. From what I can see in the documentation you
> pointed to, AXE did not.

Actually, there is some mention of it in the seq_trace docs already:

"A possible output from the system's sequential_tracer (inspired by AXE-10 and MD-110) could look like:

17:<0.30.0> Info {0,1} WITH
"**** Trace Started ****"
17:<0.31.0> Received {0,2} FROM <0.30.0> WITH
{<0.30.0>,the_message}
17:<0.31.0> Info {2,3} WITH
"We are here now"
17:<0.30.0> Received {2,4} FROM <0.31.0> WITH
{ack,{received,the_message}}"

(MD-110 is another proprietary, PLEX-based, Ericsson system).

More Ericsson history than that is hardly needed, but does 
somewhat strengthen my claim that these systems were the main
source of inspiration.

BR,
Ulf W

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