[erlang-questions] FOP (was: Re: Trace-Driven Development)
Fri Jun 8 14:04:59 CEST 2012
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:
> Ulf, at no point in that particular paragraph did I mention you by
> name. We didn't exactly bury the hatchet, so it's not like you're
> digging it up. But you are picking it up.
No, actually, I'm not. I complemented you for your tone and
interesting content in that thread, but did have some comments
on this particular statement. If I mistakenly thought I detected
*you* picking up the hatchet, and it was not so, I apologize.
> 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
I suggest we don't revisit that discussion, esp. in this thread.
Robert's comment, I think, described it well:
> I really think there are two issues here: what they are, or what
> they are commonly known as; and the generating idea behind them.
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.
>> In this particular case, the most relevant passage of our
>> long discussion should be Gustav Simonsson (who *does*
>> represent OTP) saying that your patch was welcome:
> If you mean specifically the idea of a patch mentioning that seq_trace
> implements Lamport clocks, I have yet to see that from Gustav.
That quote came as a response to me saying:
> In this case, I'm pretty sure [a reference to Lamport clocks]
> could be worked in without harming readability, but it is of course
> perfectly possible to use seq_trace without understanding, or even
> being aware of the existence of, Lamport clocks.
> 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.
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.
> 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. Also, his comment made it clear that he invited
you to expand on the topic - not just insert a one-liner.
> 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.
If you want even more confirmation before doing anything,
I understand that. That was another thing I tried to convey.
Nobody expects you to put in the time and effort to improve
Ericsson's documentation. I have decided to not make a
number of patches, since I didn't have the time, and didn't
feel confident that they would be accepted.
But that is your decision. It was suggested in another
comment that you have spent more time debating the
issue than it would have taken you to prepare the patch
and submit it. While that is probably true, well, so have I.
Meta-discussions are also important, perhaps sometimes
even more important than what the docs actually say.
Really, Michael, it would be great if you could write up
a good advanced example for seq_trace, with references
to relevant research etc. Whether you do it as a blog post
or as a documentation patch, really doesn't matter much.
You can do both, even.
Sequence trace deserves more use, and any tutorials or
additions to the docs that can help that are a great
> And I've already responded to that: "improvement" is in the eye (and
> to some extent, the imagination) of the beholder. So long as it's part
> of some internal Ericsson mythology that seq_trace only reiterates
> Lamport clocks as a technique invented independently (and
> concurrently, if not earlier) in "forlopp tracing", the response can
> always be: "we invented that, probably before Lamport thought of it,
> we don't have to credit anybody else, and some of our customers still
> think we invented it anyway, so leaving it unmentioned is what works
> best for Ericsson AS A BUSINESS."
To me, this is a big strawman you're building, but let's try not
to revisit that. For those interested, the debate, and more, is in
the list archive.
> I hope it doesn't have to go to lawyers for approval.
Nothing ever goes to the lawyers for approval, since the
only answer you ever get is "no". ;-)
> I mean, whether
> forlopp tracing, at any point in its evolution, did or did not include
> Lamport clocks ... is that actually something you can't reveal under
> NDA? The mind boggles.
Again, an amazing misrepresentation of what I
(or someone else?) have said.
What I did try to explain was that there is only so much I can
tell, as a former employee, of what went on at Ericsson. Even
when I worked there, I was not allowed to reveal internal
project or product details without approval. When I worked
there, I could of course have picked up the phone and asked
some old-timers what the real story was. Now, I can't.
Why you find this either disturbing or strange is beyond me.
Besides, it has no bearing on whether the seq_trace docs
can say that they implement Lamport clocks - Kenneth has
already said they do. If you do write a patch, and it's rejected,
it cannot possibly be for that reason.
> I can think of reasons why a corporation might be cagey on
> an issue like this. None of them are terribly complimentary
> to the corporation.
I suggested a reason earlier in this mail: the people at the
OTP team have lots on their plate and, right or not, don't
see this as a terribly important issue. Chances are, they are
even too busy to follow this thread in any detail.
(Come to think of it, that goes for me too. Whatever more there
is to say, I have exceeded my time quota, and I'm sure many
on the list would like to see this discussion end.)
Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.
More information about the erlang-questions