[erlang-questions] Trace-Driven Development

[Ulf Wiger]

On 5 Jun 2012, at 08:01, Michael Turner wrote:

> We're not talking about whether AXE was "the main source of
> inspiration". We're talking about whether the seq_trace documentation
> (especially given how confusing it is to begin with) should mention
> that it implements Lamport clocks, since, after all, (a) it does, and
> (b) lots of people who do concurrent programming know what Lamport
> clocks are already -- including about half-a-dozen in the Erlang group
> (at least if what they cite in their publications is any indication.)

*You* are talking about that, and in the process, firing off rants
insulting people who have worked much harder than you to make 
Erlang a solid platform, implying that they are lazy, possibly dishonest
and ignorant. I claim that seq_trace implements Lamport clocks "by
accident", and that it was not the original purpose, nor a complete
solution to the problem. It may be "all it does", but it's not all it should
do. I don't say that out of ignorance, but because I still recall many of 
the discussions before, during and after the implementation of 
seq_trace.

Meanwhile, you tried to submit a patch once, and since it went 
badly, you can't be bothered to submit a suggestion for how to fix
this documentation bug that upsets you (but apparently not that
many others, judging by the lack of sympathetic uproar).

Still, you are making some good points. If you would dispense with
the sarcasm, chances are people would be more inclined to listen.
Also, if you would be less focused on defending your position, we 
might actually be able to agree on something.

The reason I reply to you is not because I want to get back at you 
for insulting me (I think even you could agree that I have a track 
record of favoring constructive dialogue here), but because I think 
this is an area that really needs improvement.

There is a clear process in place: either ask the OTP team nicely to 
do this - understanding that they have a ton of higher-priority tasks 
on their plates, or figure out how to build a documentation patch yourself. 
The bar of acceptance is much lower for documentation patches.
Having patched the docs myself, my own experience is that the biggest
frustration is dealing with FOP - it runs out of heap and throws exceptions
everytime I try to build the whole docs. That, and of course the problem
of writing good documentation in the first place.

I've made this suggestion to you before - I even suggested that your
documentation patch would be universally appreciated (provided it 
improves on the current docs of course). You have declined. In my book,
this leaves you with the "ask nicely" option. That, or you can try to pay 
someone money to make your itch their priority. Erlang Solutions actually
offers that service (and no, I work for neither them nor Ericsson).

But please consider this: seq_trace was never intended as a general
implementation of Lamport clocks. It is a tracing facility, and the purpose,
as I've been trying to tell you, was to allow for tracing selectively on e.g.
a call setup sequence in a phone switch*. You shouldn't rely on it for
any other purpose. The reference to "beta status" remains there, I would
guess, because people still find the API and descriptions confusing.
I think that confusion goes much deeper than just lacking a reference
to Lamport clocks. Maybe the API should really change into something
that no longer looks very much like Lamport clocks?

That seq_trace is completely independent of the built-in tracing is also
misleading. While you can run seq_trace without tracing enabled, the 
match specifications for the trace BIFs have support for seq_trace.
The seq_trace functionality is also at least partly implemented in 
erl_bif_trace.c

(Actually, not requiring tracing is a great feature, not least if it's to be
used for other purposes - which it shouldn't in its present state - but
one can turn it around and note that one of the biggest drawbacks
of erlang's tracing support is that only one tracer per process at a time
can be supported. This makes it hard to make broader use of tracing.)

It might well be that the best way forward would be to provide a clean
API for Lamport clocks - and seq_trace is pretty close to that already -
and then rework the sequence tracing support (which is badly needed,
and shamefully under-used) to make clear and intuitive use of it.
This could achieve two good things: making Lamport clocks available
in Erlang (not just by accident, but as a documented and supported
feature), and making sequence tracing more intuitive to use.

But now we're looking at a slightly larger and more difficult task.

I venture a guess that this is very close to what you've been trying
to say, but your refusal to accept that the seq_trace API was not 
meant to implement Lamport clocks, and might well depart from them
if it makes it more fit for purpose, reduces the chances that your
suggestions for improvement will actually be accepted. You need to
accept the whole picture.

* Just to expand a bit on what the challenge is: in a phone switch,
or similar, operating under potentially high load and with fairly 
extreme availability demands, running a sequence trace is not 
primarily a question of ordering concurrent events - for practical
purposes, the trace timestamps are often sufficient for that - 
the big problem is to selectively triggering trace output at just
the right places and turning it off as soon as it is no longer needed.
In this respect, Lamport clocks are one brilliant and convenient 
technique that can be built on to solve part of the problem. The 
thesis I linked to lists a few other approaches.

(And no, the failure to mention Erlang's support for real-time
tracing in that thesis is more likely to be due to internal rivalry,
or simply lack of interest in technologies that they can't use 
anyway - Erlang due to past policy issues and AXE since it's
a legacy system using a weird programming language). 

BR,
Ulf W

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