I don't know whether this idea has already been put forward in the reams of pages about computer go. Anyway, I remember reading that Alan Turing devised a chess-playing program that he could execute himself from instructions on a piece of paper. This was before the days of readily available programmable computers. It enabled him to test the strength of his approach to chess programming. It played very poorly (a "caricature of my own style"), but nevertheless it worked.
Could this be applied to go in a useful way? Much of the effort in programming go must be in the coding. However, wouldn't it be good to know in advance that the strategic and tactical algorithm?s are going to be effective?
Therefore, I suggest a way to develop a strong go program might be to write down a series of instructions or priorities (a kind of super-checklist) and to follow them strictly when playing a game, to find out if these would be worth encoding. Obviously it would take too long to play many complete games like this, but a number of runs up to move 100 or so should provide useful information.
HolIgor: Actual coding of the algorithm is not so difficult, even though the calculations may be quite involved. Formulation of the algorithm is on the other hand a very difficult thing. If the rules are formulated I can try to implement them.
One can first ask a simple questions: what data should be collected from the board position. For example, the number of liberties of the stones, Manhattan distances etc. The second question is what can one do with all that information.
WilliamNewman: Many programming languages support a style of just writing down a set of instructions or priorities as easily as you might do it on a set of cards, if I understand correctly what you mean. (It sounds rather like a simple case of what's called "functional programming". If you look at section 5 of http://homepages.inf.ed.ac.uk/wadler/papers/sigplan-angry/sigplan-angry.ps, you might find that it sounds similar.) But any time you specify behavior to something without common sense, you end up needing to be very pedantic about what you mean. Whether with ordinary code or with cards (assuming that the instructions are going to be followed by a machine, not by your human buddy), you can't just write your rule to do one thing if, e.g., a move is urgent and another thing otherwise. You can still use high level concepts like "urgent", "sente", "miai", or "thick", but only if you can define them precisely to the machine. Generally such precise definitions have to ground out somewhere in terms of trivial concepts like the number of adjacent stones or the distance from the edge, which makes things difficult. Even defining medium-level concepts like "dead" or "connected" or "surrounded" at the level that humans use them seems to be very difficult. (If you had good definitions of them you could solve general tsume-go problems, which no one knows how to do...)
Matt Noonan: I think that Dieter did something like this, though not as extreme. If I remember right, he played for a while using only proverbs when possible. I seem to remember him being disappointed with the results, but maybe he can give his own impressions here.
Dieter: I did play several games trying to stick to principles. The conclusions were more on the mental aspect than the rational aspect of playing a game: