Successive approximation does not imply optimal successive approximation. A random walk that gets there qualifies: a succession of steps. A linear search is generally more efficient than a random walk, but depends on an accurate assessment of the direction and magnitude of each step. A binary search also depends on a global ordering criterion. All that would too much to ask of many users of Go.
>Successive approximation does not imply optimal successive approximation. A random walk that gets there qualifies: a succession of steps.
Your first sentence (quoted above) is right.
But IMO, the two sentences quoted above, together, are not right. Because, even if not optimal, successive approximation means getting closer at each step, which is unlikely or impossible with a random walk.
>With each step, you get closer in time to when you will stop. You don't know, at any step, how far you are from a solution, until after the last one.
Still think the logic is wrong or at least farfetched, but not going to argue it more.
>You may laugh, but more code is written this way than not.
I know that quite well, having been a dev for many years and a manager for some, so seen things from both "sides".
In fact I can say I've seen it from a third and maybe even a fourth side (perspective, really), ha ha, since I've been an independent consultant and trainer for a while now.
"Programming by successive approximation" is more polite to say that "flailing randomly", but it would be a mistake to imagine one being more orderly than the other. But it was good enough for our protist ancestors, so it would not do to say it is wrong, as such.
