Don wrote:hgm wrote:Aaron Becker wrote:Good point. We UCI programmers are either idiots or insane, no one knows which (maybe some of us are both). Fortunately there are still plenty of Winboard programmers to move the state of the art in computer chess forward.
Well, I would not put it quite in the same words as you or Bob, but it does indeed strike me as odd to prefer the awfully inefficient and verbose UCI prototocol over WinBoard protocol, which is almost trivially to implement in comparison. I cannot see any argument in favor of UCI; there only seem to be downsides to this.
When I started actively developing my chess program I chose UCI because it was very nicely specified. The docs were crystal clear, I had it up and running in no time and it even handles thinking on the opponents time for you. Not that this is a big deal, but it was nice to have the protocol and GUI handle this in such a nice way.
I think I can sum up the differences by just making the observation (which is my opinion) that there seems to be 2 different philosophies with winboard vs UCI.
Winboard seems more like just a simple communication protocol and UCI seems like it was designed to take some burden off the chess programmer by taking over some of the functions you (as a programmer) would normally have to worry about yourself.
I'll give what I think is the primary example. Thinking on the opponents time or pondering. With UCI you don't have to implement pondering, the protocol manages this for you. When the engine makes a move, the GUI will immediately send the engine the position to begin pondering on. If the move is not made, the GUI will stop your engine and restart it with the correct position. UCI (or more properly put the user inteface) handles all the state tracking for you and the engine is relegated to just following simple orders.
Another way to view this is that winboard shifts more responsibility to the engine and UCI shifts more responsibility to the user interface. UCI tracks state for you (from the point of view of the engine author) and winboard doesn't.
Which is better? It's totally a matter of personal preference as far as I'm concerned. I am not a religious zealot on this issue and I believe the top programs would be just as strong had they used winboard instead of UCI. But I do prefer UCI simply because I believe it allows you to focus more on the game playing engine and isolates you from some of the crufty details of the user interface, and I'm an old fashioned programmer who believes that functional parts of systems should be modular and separated. I don't like the idea of a monolithic engine that do it all.
My guess is that over time people will move towards UCI for these same reasons. UCI is more modern in the sense that it simplifies and separates functionality. It makes the chess engine simpler by taking away some of the burden. On the other hand, it could be argued that this is a weakness and that the engine SHOULD be tracking state, fully in control of pondering, etc. I cannot argue with that either, as I say it's a matter or personal preference.
I can tell you one thing however. In the past, before UCI, my program essentially implemented a separate user interface that was compiled into the program. It was relatively simple, but it had to be there. It did what UCI does now so UCI allows me to throw all of that away. If I implement winboard, which I plan to do as an option to Komodo, I will have to essentially build a simple user interface (which would be compiled into the chess program) to get the functionality that winboard does not provide.
None of this is that big a deal and it's not worthy of a religious war but it's how I see it. I respect the arguments of the winboard folks who do not want the GUI to have control of their engines. In my younger days I was more of a control freak that way too and there are good arguments for that.
Anyway, I have not tracked the development of winboard all that well, do I have it wrong? Am I missing something here?