I'm not sure this comment actually means that we should prefer a
programming language over an other. As Steve McConnell says in Code
Complete 2:
"Program into your language. Not in it!"
By this he mean abstraction to data types. What the GNU Backgammon code is
missing is real abstraction of backgammon types. There should be a type for
a position/board, there should be a type for a move, there should be a type
for outcome probabilities, there should be a type the dice, there should be
a type for a roll, there should be a type for the doubling cube, there
should be a type for an action, there should be a type for a board point,
there should be a type for a player there should be a type for a game,
there should be a type a match, there should be a type for.....( you get
the point -- fill any _backgammon_ related term. )
There should also be some interfaces. One I can think of on the top of my
head is "evaluate". Evaluate should be an interface and all functions that
can evaluate a position should implement this.
In the above paragraphs "type" does not necessarily mean "class" in C++.
Nor does it mean typdefed struct in C. "Interface" in the above paragraphs
does not necessarily mean an abstract class with only virtual
not-implements methods in C++. Nor does it mean a function pointer to
function in C (or any similar trick to mimic abstract behavior). The point
is that it should be abstracted out of the mind of the coder, such that the
coder can think about the backgammon logic when coding.
A ok code of backgammon in _my_ language will then be like this:
board_t *board = board_new( INITIAL_BOARD );
evaluator_t *eval = gnubg_evaluator_new( STANDARD_CONFIGURATION );
dice_t roll = dice_new( 3, 1 );
move_t best = find_best_move( eval, board, roll );
printf("Best move is: %s\n", move_to_string( best ));
/* I just made up this code based on the abstractions I listed in the
paragraph above. Note the syntax is C. */
/* The code is not tested or compiled or anything since I don't have the
types.... */
Hopefully the above code will output:
Best move is: 31: 8/5 6/5
Let me make up the same program snippet with C++ syntax:
Board board = Board();
Evaluator* eval = new gnubg();
Dice roll = Dice( 3, 1);
Move best = eval->find_best_move( &board, &roll );
std::cout << "Best move is: " << best;
// I just made up this code based on the abstractions I listed in the
paragraph above. Note the syntax is C++.
// The code is not tested or compiled ... And my C++ is a bit rusty, so
there probably bad errors.
As you see. There is really not much difference. The code is in _my_
language, defined by the data types, not the programming language I'm
using. Maybe I can even swig (is swig a verb? www.swig.org ) this and have
a Python interface. If I did, the code would be nearly exactly the same,
just another syntax.
-Øystein
On Fri, Feb 14, 2014 at 12:30 PM, Taper_Mike <[email protected]> wrote:
> To date, I have not been a coder in the GnuBg project, so you should take
> my input with a grain of salt.
>
>
>
> Having said that, I must also confess that the one time I looked through
> some of the GnuBg source code, I was shocked to see that it was coded in C
> instead of C++.
>
>
>
> While it is true that many features of C++ can be implemented through good
> coding practices in C, my preference for C++ is every bit as strong as
> Oystein's preference against it.
>
>
>
> I think we can take a hint from Xavier. He's using Delphi for eXtreme
> Gammon, not Pascal!
>
>
>
> Mike Mannon
>
>
>
> _______________________________________________
> Bug-gnubg mailing list
> [email protected]
> https://lists.gnu.org/mailman/listinfo/bug-gnubg
>
>
_______________________________________________
Bug-gnubg mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-gnubg
