🚀 go-pugleaf

In article <46ff06$1ss@ubszh.fh.zh.ubs.com> jis@ubszh.net.ch (Johnston
Ian (by ubsswop)) writes:

|> In article <dewar.814190504@schonberg>, dewar@cs.nyu.edu (Robert Dewar) writes:
|> |> Ian says:
|> |> 
|> |> "Besides, an interactive debugger is essential in the real world."
|> |> 
|> |> Well in one sense this is true, namely the commercial sense. Since so many
|> |> programmers are lost without an interactive debugger, it is certainly true
|> |> that a compiler must have a debugger to be generally used.
|> |> 
|> |> However, the idea that it is impossible to write code without an interactive
|> |> debugger is rubbish. Indeed, using the clean-room approach, it is quite
|> |> practical to write code under conditions where the devlopers do not test
|> |> the code they write AT ALL, let alone fiddle around with interactive
|> |> debuggers.

|> May be it's just me then :-)

|> Seriously, though, I do find that using a debugger is the only way to start
|> pinning down what is going on with complex system calls, across a client-
|> server link. If something goes wrong, sometimes you don't even know
|> whether it was the client or the server that had a problem.

Just curious, you *do* instrument your code, don't you?  And you do
have an external specification at the link level?  So wouldn't a
message trace at the link level show immediate which side had the
problem?

And maybe I'm just being naive, but I would suppose that a client
server link used some sort of layered protocol, and that each layer
was tested separately, so when debugging layer n, I wouldn't have to
worry about layers 1..n-1.
-- 
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung