This is actually not hard to prove. For those who'd like it spelled out: One reason: Programming is an open system, chess is closed. Another reason: It takes one person (maybe two with a coach) to become a GrandMasterOfChess; it takes a whole team from IBM to program a computer to beat a single GrandMasterOfChess at a single match. Not even a GrandMasterOfChess on his own could do that. ---- The first reason needs more explanations, the second only says that humans are smart. Let's try these: *In chess, you don't get the chance to refactor. Usually one mistake is enough to lose the game. *In chess, you have very limited time to make a decision. On average 3 minutes per move. *There are a lot more programmers than chess players. ''Of the above three, the first states only that chess is not fault-tolerant, is more time-critical, and less accessible, so ChessIsHarderThanProgramming.'' That's exactly what I thought. I think that in any case we're comparing apples to oranges. However, chess and programming have many things in common. We can use some techniques developed for the game of chess when doing programming, unless we think that ProgrammingIsHarderThanChess and therefore no chess technique will apply to programming. ---- ''Another reason: It takes one person (maybe two with a coach) to become a GrandMasterOfChess; it takes a whole team from IBM to program a computer to beat a single GrandMasterOfChess at a single match. Not even a GrandMasterOfChess on his own could do that.'' That only proves that programming ''chess'', in particular, is hard. It doesn't prove anything about other kinds of programming. (Which, of course, are hard as well.) -- MikeSmith ---- I would conjecture that if chess is Turing complete then chess and programming are equivalently hard (every chess game would have an equivalent program). Of course the "chess" interface would make some types of program/game harder than others to play. If chess is not Turing complete then it would be easier than programming. ''The above has it a bit backwards. If chess were turing-complete (which it isn't since there are a finite set of states) then every program would have an equivalent chess game.'' Chess is not turing-complete, but neither is any RealLife computer system. I accept that the number of states in even a small PC is many orders of magnitude greater than those in a chess game - but it is still finite. '''Sure. But chess is not eve turing-complete in theory. Not even close; it has a fairly small (in the scope of these things) set of states.'' ''Additionally, turing-complete is not a good measure of difficulty. It tells you something about what is possible in a language, not what is easy. For a quick example, take your favorite 1000-10000 line program (in your favorite language), then rewrite it in intercal :). For a more pragmatic example, consider the fact that c++ templates are turing-complete.'' ''`Hardness' in this sense has to do with the process of programming (or playing chess), and is more difficult to define. However, I don't believe that chess would be equivalently hard to (general purpose) programming, under any useful definition of `hard'.'' ---- Programming certainly pays better than chess. ---- ''In chess you don't get the chance to refactor. Usually one mistake is enough to lose the game. '' But you don't need to win every game. Often, you're playing in a tournament environment, where you "merely" need to win M out of N games to progress. OTOH, a failed software project is a bad thing - it has real costs in terms of money, reputation, and sometimes jobs. So even though it may be easier to fail in chess, the cost of failure is higher in software development. -- MikeSmith ---- As a couple of people have mentioned, this comparison was broken to begin with. Chess is a well-defined two-player game, where players take turns making moves. There is a well-defined notion of winning, moves, turns, etc. Chess has consistent and relatively simple rules. In contrast, programming is not a two-player game, or any kind of game in the ordinary sense. There is no notion of winning. What is a move, or turn, in programming? How do you castle? :-) You can write down the rules of chess in a few pages, but TheRulesOfProgramming are ambiguous and inconsistent, written down in hundreds of books (reference books, text books, etc.). TheRulesOfProgramming are complex, and inconsistent (I've seen lots of conflicting advice about ho to program). Here are some comparisons between chess and programming that come to mind: * For a chess position, there are a finite number of well-defined moves that the player can make. A famous chess fact is that there's typically 30 or so possible moves in any chess position. In programming, it would be useful to know, on average, how many choices a programmer has to choose from when they reach a decision point. In other words, we could compare the BranchingFactor of programming and chess. * A chess game usually lasts (at most) only a couple of hours, and takes 40 - 60 moves. Programming usually takes much longer, and I suspect programmers must make more than 60 decisions along the way. * In chess, you always see the entire board, i.e. you always know what's going on. There is no hidden information, and the only uncertainty/randomness comes from your opponents moves. In programming, there is typically lots of things you don't know (and can't know), and uncertainty can arise from numerous different places. * Chess is always the same. While it as deep strategies and a variety of tactics, it's just not as big, complex, and varied as programming. One day a programmer might write a video game, the next day they might write a text editor, the next day a CGI script, etc. There are no new rules or pieces in (ordinary) chess. If you want to compare programming to games, programming is more a mixture of (at least) Risk, Life, Diplomacy, NomicGame, and MagicTheGathering. -- TobyDonaldson ''In contrast, programming is not a two-player game, or any kind of game in the ordinary sense. There is no notion of winning.'' Winning is getting the project done. Done well. You can think of your own limitations as your adversary. Also, see SoftwareDevelopmentAsaCooperativeGame. I certainly agree that programming can be thought of as a game, if you are willing to stretch the notion of game thinly enough. I don't know about you, but if someone said "Hey, let's play a game!", writing code doesn't spring to mind! Since "game" is vague and imprecise (yet wonderfully suggestive), anyone can mean pretty much whatever they want by it. As you point out, you can think of programming as an adversarial game, or a cooperative game. Chess, in contrast, is a purely 2-player adversarial game, unless you change the rules. You could think of pretty much any part of programming as a kind of game, but it seems you will always be abstracting away some of the details of what programming really is. Treating programming in general as a game (or set of games) seems to be mainly a literary device. ---- ''For a chess position, there are a finite number of well-defined moves that the player can make. '' This doesn't matter. The number of moves in quasi-majority of situations is well beyond what any human can manage. ''A chess game usually lasts (at most) only a couple of hours, and takes 40 - 60 moves. '' Yes. And playing chess is A LOT more intensive than programming. ''In chess, you always see the entire board, i.e. you always know what's going on.'' You must be kidding. If you see the entire board , this has nothing to do with realizing what's going on. ''Chess is always the same.'' That's a good joke. So why do people keep playing chess and discover a lot of new things about chess? ''TheRulesOfProgramming are complex, and inconsistent (I've seen lots of conflicting advice about how to program).'' Now is this a characteristic of programming or of humans doing programming? At least the fact that you saw conflicting advices should give us a clue that humans play an important part in the equation. ---- What a bizarre and ill-defined statement! I'm not even sure chess is a good metaphor for programming. There are several things "programming is harder than chess" could mean: * one programming task is comparable to thinking about one move in a game of chess ** Not as effort but as mechanism. A programming task will contain several choices/commitments (vis-a-vis the way to go about it, design the API, the structure of the algorithm, etc.) that is very similar with the decision making process in chess. * trying to reason out the cause of a bug is comparable to thinking about a move in a game of chess. ** I do not believe deductive reasoning (backward chaining) is used much in playing chess, so I cannot support this one with my experience. * one programming project or task is comparable to one game of chess ** I think intellectual effort comparisons are misguided. What I can say for sure is that chess players are miserably underpaid for their intellect and their effort. It's important to tell this to kids studying chess: chess might prepare them for a different career. * one programming project is comparable to a chess tournament or match ** A professional chess player should be able to play 10-12 torunaments a year without any burn out. I do not believe there are many programmers who finnish 10 projects in 1 year. * the career of a programmer is comparable to the career of a professional chess player (actual coding is of course only the tip of the iceberg of being a programmer, just as playing chess is only a minor activity of a professional chess player) ** Unfortunately programmers dedicate much less time to keeping their brain and programming skills in shape. They are mostly paid for software development activities, and that's what they do. The training of programmers is abysmal, for the complexity of intellectual activity they perform. * software education is comparable to the multi-PhD work to become a chess Grand Master. ** I see some parallels here: the process of learning chess openings feels similar to learning a new library or API (arbitrary and complex). Learning new algorithms and techniques feels similar to learning types of combinations or endgames (more fundamental and widely useful). ** ''Again the process of learning for programmers is missing key components. Outside the university it is as good as non-existent, as far as I am concerned.'' * the feeling of winning (or losing) a game is comparable to the feeling of finishing a programming task (or getting a bug report on your precious code) ** The SweetTasteOfVictory is applicable to all human endeavours. Even to wiki. I was planning to write up on that. * the feel of playing your way out of a poor position is comparable to the feel of working in LegacyCode * likewise, the feel of playing in a good position is comparable to coding within a well architected system surrounded by UnitTest''''''s ** I do not believe that UnitTest''''''s have much to do with the essence of programming. They are key tools to ensure a quality output and keep the process under control, but contrary to the thesis of TestDrivenDesign I was underwhelmed by what XP proponents claim to be the connection between unit testing and the creative process of coming up with a solution to a problem. * playing from an opening you don't know is comparable to programming with unfamiliar tools or an unknown API with the manual missing ** Not quite. In programming you can take a break and study the tools/API etc. When such things are impossible the situation still differs from chess, but the other way around: in chess, no mater what the opening is, you can '''always''' follow general principles and play it soundly, even with very superficial knowledge. And you get a decent games. I've won against grandmasters in openings that were totally new to me while the opponents knew their way around very well. In programming, no matter how good you are, there are no guaranteed recipes to getting a job done. * the feeling of working overtime is comparable to finishing an adjourned game in the wee hours of the day (adjourned game? what's that? kids these days...) ** Not sure. More correctly, it is comparable with trying to prepare against a grandmaster for the next day and not being able to find the right path in the opening. Chess players might even spend a night trying to prepare the opening for the next game. * the feeling of losing a game on time is comparable to your programming task running over time/budget or your project getting cancelled ** The SweetTasteOfVictory has its reverse as well. * the experience of playing blitz or bughouse is like programming an adhoc personal project in your favorite EsotericProgrammingLanguage (or ScriptingLanguage). ** Playing blitz is more like playing in Las Vegas than playing chess. You know you play bad but you hope your luck will help you make less mistakes than your opponent. It is also more entertainment than intellectual activity, although, unlike entertainment, it is mentally exhausting. I'd love to have Costin's input as to the validity of any of these statements. -- IanOsgood ---- Here's one more take on this. ProgrammingIsHarderThanChess because we don't have computer programs which can do the job of a world class programmer, but we do have programs that are on par with world class chess players. -- IanOsgood ---- Is Programming harder than Go? Is Programming harder than... * chess? * go? * tiddlywinks? * knitting? * RandomPages? * a polar bear? * concrete? * square dancing? * dating? ...and is 1 < a daisy? ---- Programming is more like a puzzle than a game. In a puzzle there is just one "player" and the objective is to solve the puzzle. Like a Rubik's Cube. In a game there are multiple players. Actually programming is more like a ''kind'' of puzzle, since some programs are easy to figure out how to write, and some are very hard. I suppose it can become more like a game if there are multiple people trying to solve the puzzle and there is a prize for being first. But such a game is more like a wrapper around programming than a description of programming itself. I don't know what it would mean for a game to be Turing-complete. A Turing machine doesn't have any players at all. You set it up and then it runs deterministically. (A non-deterministic Turing machine is equivalent.) ---- CategoryComparisons CategoryMetaphor