I disagree: I prefer simple commands that do exactly one thing. In UCI the "go" command does a bunch of different things, controlled by options that are passed along with it. It's actually (marginally) harder to parse because of this.mvk wrote:I wanted to say that the single "position\ngo" command is much simpler, but I was waiting for the best opportunity.hgm wrote:But it is a fraud: they are not simple commands at all. They are multiple commands written on the same line. They are exactly the same commands as in CECP. "positon startpos" = "new", "position fen" = "setboard", "moves" = "force", "wtime/btime" = "time/otim".mvk wrote:What I think is quite elegant in the uci design is that with just one pair of simple commands ("position" and "go") an uci engine can already make moves in a game, accept take back, setup and play from a new position, swap sides, accept new time controls, reset and start a new game and analyse random positions.
I don't think anyone wants to argue that the CECP "specs" are well written; I started with UCI precisely because I found the specifications more readable.uci.html is 26kB, xboard.html is 96kB. Both are equally useful documentation for their standard. Where does the size difference come from? Not only the resign and draw commands. It is also unneeded complexity: multiple ways to do the same thing. It is things like this: when I go back in xboard, I don't receive "force" and "setboard" with all the things you mention. I get "undo". Undo is a redundant command and yet it is mandatory to implement to get full functionality. Or if I retract a move while playing, I don't get 2 times "undo", I get ... "remove"! Such convoluted things are the reason that when you start with uci you have full functionality quicker and can focus on search and evaluation sooner. And your users can run under any GUI of their choosing ofcourse. One more such thing: you can send "feature setboard=1", but as long as the GUI is allowed to send "rejected setboard", you must still support "edit" and all its drama. But some GUIs need "setboard" and won't do "edit", so you must still have both. Argh. With uci the gui has no such weird freedoms and that makes life easier for everyone. If you intend to give the user the full experience, you must implement the whole standard, not just the subset that lets you play a single game.
A large part of the size of the CECP specs is due to bloat. Dropping all of the historical cruft (or moving it to an appendix) will do wonders to make the protocol more accessible. If and when you do that it turns out that there is really very little functional difference between the two protocols.
I disagree about "undo": the "force/setboard" combination isn't equivalent because it doesn't retain the game history. Sure, you can send the full move list afterwards, which is functionally the same as what UCI does. I'll take a simple "undo" instead, thanks. It's not like the ability to undo a move is something that needs to be added specially in the engine, it does that during the search anyway. "Remove" instead of 2x"undo" is a bit unintuitive, but is a logical consequence of the engine not being in "force" mode. It's not too much trouble to deal with it.
I will grant you "rejected setboard" as a theoretical problem, but in practice I don't think there are any GUIs that would send that, and I would personally consider a GUI that does as defective. None of my engines support the "edit" command and I have no plans to add support for it in the future either.