Tord Romstad wrote:wgarvin wrote:No, no no no! The engine's job is to play chess. The GUI's job is to display a pretty picture of the board. Resigning, using opening books, tablebases etc. is a part of playing chess and should be entirely the engine's job.
Huge snip
wgarvin wrote:Maybe there should be common libraries for accessing tablebase files that are in a standard format? Each engine can then load them from the same place on disk through this standard library.
It seems to me that you are saying that using a dynamically loaded library written by somebody else to help the program select its moves is OK, but that using a separate program written by somebody else to help it select its moves is not OK? This seems absurd to me. The difference is purely technical. The only thing that should matter is to what extent you use code by others to select your moves, not whether the code is copied into your source code, is loaded as a library, or is running as a separate program.
It's also annoying that people tend to assume that everybody who wants to do non-trivial things on the GUI end intends to use
somebody else's GUI. Some of us write complete chess programs, you know.
Tord
I don't care if two or more engines want to share the same DLLs that access tablebases. That is up to the author of each engine, the author(s) of these potentially-shared DLLs, and whether tournament rules permit it or not.
However, I DON'T want the GUI to use those (at least, not in any way that helps the engine).
A chess engine should not require a GUI to be fully functional at playing chess. You can provide your own GUI if you want to, maybe even with extra functionality for the user that other GUIs don't have---but *please* don't cripple your engine by putting stuff it needs to
play chess into the GUI instead of the engine. All that does is prevent people from using your engine fully with other GUIs or without the GUI, in which case, why did you make your engine and your GUI two separate programs in the first place? The major benefit of modularity between GUI and engine is that we can mix and match them.
That's the whole point of having common communication protocols like Winboard too! I should be able to take two *engines* that speak "Winboard" and put a tournament director or something between them, and they should be fully capable of playing games at full strength, through the Winboard interface rather than some external GUI program. If we can't mix and match them, I claim you are doing us a disservice by making them separate programs. I guess my beef with UCI is that it encourages this wrongful division of labor between engine and GUI, in effect making the GUI a "front end part" of the engine. But this is wrong and harmful and bad. Just don't do it.
Okay. I've said my piece. Sorry if I hurt anybody's feelings.