Life In 19x19

uPWarrior wrote:Personally, I've changed my mind over the years from "start coding", to "plan thoroughly" and later to "don't make plans you know you won't follow".

I've always been pretty much halfway in between. Plan a bit, start a framework as an example to see if it still makes sense, and then go back to planning on each individual part. You end up in a path where you do planning->code->test->planning->code->test... etc until done.

Last month I started using Greenfoot to make a 9x9 'Tibetan' Go program. (not an AI)

Mention of things like "flowcharts" and "pseudocode" (though that is closer) indicates many of you don't understand what I mean by "abstract design". For example, using a flowchart implies that you have already chosen "process" over "evaluation" (of a function).

On way of thinking about this is the reverse of "coding". Try to visualize the "machine" that just happened to have as its primative machine instructions and data storage exactly what you would want to make solving the problem trivial. Once you have reduced the problem to this abstract machine using its abstract operations/evaluations on the abstract data structures you have broken the problem part into pieces that are probably the right size. You now just code whatever implements these abstract operations/evaluations and data structures on your real machine.

The danger of "jumping right in" is that the way the problem is defined (or the way that you see it) might lead you to make premature choices. Choices that mean your solution will be clumsy, inefficient, slow, hard to test, etc.

In my experience, that approaches frequently leads to "perfectly solving the wrong problem".
Especially in home-made projects, one should not be too attached to the initial requirements in order to keep the motivation high with new and different ideas.

uPWarrior wrote:In my experience, that approaches frequently leads to "perfectly solving the wrong problem". Especially in home-made projects, one should not be too attached to the initial requirements in order to keep the motivation high with new and different ideas.

With that statement I am beyond disagreement. I don't comprehend it. What do you mean by "wrong problem"? How would coding enable you to discover this? You set out to write a go playing program but decided you really wanted one that played chess? Do bookkeeping?

The definitions/decisions about what your program is supposed to do have to come long before you dive in to code it. Nor does it make all that big a difference whether this goal is set by "management" or yourself. ROFLOL back in the days when it was management deciding what I would be working on rarely was that fixed in stone (I was a critical resource and so only very rarely ended up doing what was planned for the next six months --- I think only Y2K went as planned and even then I had to jump over to redo the first "done by tools" system when it went into production and serious problems surfaced).

After retiring I decided what programming to do and in what languages (when you are already fluent in half a dozen and can at least read most any adding a new one is easy). But if I chose to write a progam to do this or that (say a finite implementation of the 2nd Lempel-Zev Universal Data Compression Algorithm directly from the definition -- the "case problem" I chose for deciding if I had learned C) I would be disappointed (consider it a failure) if did something else. Even if that something else was a perfectly good (but different) compression algorithm. Or even the very useful/practical closely related alternative that used a fixed size dictionary (instead of one starting at the character set and growing to some finite max size). Because not the problem I chose to solve.

Writing an LZ is a concrete algorithm, just like implementing the AES encryption scheme. Writing a go program, much like writing a game, or any other big project with fuzzy definitions is not solved by planning. I can plan on writing a neat MC scheme and decide what data structures to use, and what the memory management is, and whatnot. And when I'm finished (because with a thorough planning there is no point in prototyping unless you want to spend 2x time) find that the data structure I used has bad scaling for an MC engine. Then, to redesign the data accessors and structure. The new one works better, but tweaking of the tree genersting loop was needed, making it use 2x memory, making it nom-scalable. Repeat ad-nauseam.

When I started programming in my degree, we were assumed to plan ahead and "all this". Then I found out that in real world problems (mathematics in particular) it's better to get it done and then refine than plan and get it perfect. Because these plans rely on assumptions on what will work without having any working knowledge on the problem domain.

This is going nowhere, clearly more a confusion of terminology than anything else, central to that the meaning of "abstract".

AFTER a complete abstract plan there may be a need for intermediate planning. I say may, because now we are talking about the experience and skill of the individual programmer. When you mention making an unwise choice of (real) data structures in your planning that can only be in this intermediate sort of planning. At the abstract plan level, data structures are still abstract, not committed to any particular real representation.

You (perhaps rightly) describe LZ2 as "simple". But even that has some subtleties that had best be noticed while still at the abstract level or likely to be bugs that are very mysterious and hard to fix (and unlikely to be detected by testing because you won't be testing for that special situation).

Michael