[erlang-questions] FOP (was: Re: Trace-Driven Development)

[Michael Turner]

On Fri, Jun 8, 2012 at 9:04 PM, Ulf Wiger <ulf@REDACTED> wrote:
>
> On 8 Jun 2012, at 12:46, Michael Turner wrote:
>
>> On Fri, Jun 8, 2012 at 6:55 PM, Ulf Wiger <ulf@REDACTED> wrote:
>>>
>>> On 8 Jun 2012, at 09:19, Michael Turner wrote:
>> Nothing I wrote up there about getting seq_trace documentation to
>> mention that it implement Lamport clocks could reasonably be construed
>> as your own idea, particularly since you initially seemed pretty hazy
>> in your response my statement that seq_trace implements Lamport
>> clocks.
>
> I suggest we don't revisit that discussion, esp. in this thread.

And then what do you do? You start revisiting that discussion.

> Robert's comment, I think, described it well:
>
> [Robert:]
>> I really think there are two issues here: what they are, or what
>> they are commonly known as; and the generating idea behind them.

"Generating idea" isn't a well-defined term. So I disagree: this
doesn't really say much of anything, because there's apparently no way
(under your NDAs) to distinguish the supposed "generating idea" from
what Lamport clocks are "commonly known as": Lamport clocks.

Lamport clocks are integral to the seq_trace API. The wording of the
documentation makes that very, very clear. The only "beta" caveat is
about possible *interface* changes.

End of story.

> I'm sure there is much more that could be said to expand on
> that, and I could give some other examples of where mixing
> up purpose and implementation in the crafting of API and
> docs can lead to problems (the 'ets' module, for one), but
> I don't think I will, since you and I seem to differ completely
> on what the purpose of seq_trace is, what the word 'tracing'
> (and more so 'sequence trace') actually implies, so I think
> we would just continue to talk past each other.

You say we "differ completely", but you base your differences on
things you say that I can't know because you can't tell me: customer
requirements generated under NDA. This makes no sense. If seq_trace
actually directly reflects customer requirements, I'd say it's pretty
obvious that the customer wanted (among other things) Lamport clocks.
Perhaps they expressed them as, "we have clock skew problems in our
distributed system, and we need some way to correctly sequence our
traces in spite of that." Lamport clocks are a simple, classical
solution to that problem. If that customer (and others) are using that
solution, all YOUR talk of possible alternative implementations is
moot: you'd be introducing an incompatibility.

You might opine otherwise, but since you can't tell me the difference
between the customer requirement and what the seq_trace documentation
says (two things that, at times, you've equated, more confusing
still), you might as well be talking about some divine inspiration not
communicable to mere mortals like me.

> If Gustav meant something other than the obvious interpretation
> that you were most welcome to insert an advanced example
> describing how seq_trace implements Lamport clocks, and
> how that knowledge can help you make good use of them, he
> should hasten to clarify that.

That's your idea of "the most obvious interpretation"? I don't know
how I could have made myself clearer: I've REPEATEDLY suggested adding
four words - "seq_trace implements Lamport clocks."

There's no need to "insert an advanced example describing how
seq_trace implements Lamport clocks." The documentation ALREADY
DESCRIBES HOW IT IMPLEMENTS LAMPORT CLOCKS. I want to see credit where
it's due, because (a) that's the right thing to do, and (b) it gives
people who already know what Lamport clocks are the advantage of
instant familiarity.

Which I've said at least twice before.

>> And I have it (second-hand from you) that he has himself
>> thought of a good place for this mention, in the seq_trace
>> documentation. To which I replied: if he's got a good idea
>> for that, why doesn't he just do it?
>
> No, first-hand from Gustav, as he replied in the thread,
> cc to the list.

A bland and vague solicitation for "improvements" still leaves room
for interpretation of the term "improvement." (As I've already said
probably three times now.) If giving credit to Lamport is finally
judged to not be an improvement, then Gustav's solicitation is NOT a
specific, explicit request for that crediting of Lamport.

> Also, his comment made it clear that he invited
> you to expand on the topic - not just insert a one-liner.

First things first: stop making the seq_trace documentation look like
plagiarism. In four words. Gustav replied with dozens of words when he
himself could have just added four to the documentation.

>> As far as I can tell, NOBODY at Ericsson has, in writing, said
>> directly, "We need to fix that." Until then ….
>
> What I was trying to convey with my last post was that you
> have actually received more indication that your patch
> will be accepted than most people who have submitted
> documentation patches have.

No, what I've received is a lot of words with no definite commitment.
What is so hard about being direct and saying, "Yes, the documentation
should say that seq_trace implements Lamport clocks"?

[snip long passage]

The issues here are so basic.

-michael turner