An object debugging infrastructure

An object debugging infrastructure

Posted Mar 7, 2008 18:03 UTC (Fri) by giraffedata (subscriber, #1954)
Parent article: An object debugging infrastructure

This article is a good example of the mistake of explaining something starting with the abstract. People don't develop complex ideas that way, and they can't learn them best that way either. People develop complex ideas by starting with concrete examples. In this case, Gleixner started with some timer usage bug. You add more and more examples, abstracting along the way to accomodate them. Other timer bugs, hypothetical further timer bugs and bugs in other areas, etc. That's how the human brain forms concepts.

But when going to explain the new concept, the inventor often, wrongly, starts with the highest abstraction. If you're lucky, at the end he gives you some examples. I suppose it's a way of stressing the actual invention, which is the abstraction, not the collection of examples. But it just makes it harder to see what the invention is.

I noticed that right away in this article because it talks about creating a debug_obj_descr struct, in full C detail, before I had any idea what it would be for. Nothing to hang it on in my mind. Then it says the next step is to call something whenever an "action of interest" involves a tracked "object," without having said what sort of actions or objects it's talking about. Those are wide-open terms. Much wider than what the author really has in mind.

I'd like to know just what timer related bugs this helps with. And I suspect the facility isn't all that general after all. The timer subsystem uses a rather unique model of communication where concepts of "add to the subsystem" and "remove from the subsystem" (again, too abstract / not defined) exist.

---

(Log in to post comments)

I found the article to be much clearer than your explanation about what you didn't like about
it.