To really get an answer to that, you should take a look at the INTERCAL manual, particularly the first two sections. (Or see my collection of INTERCAL Resources.) Briefly, though, INTERCAL is a computer language that was never meant to be taken seriously. In fact, it wasn't really meant to be used. Certainly it was never meant to be used in conjunction with the Internet.
The Common Gateway Interface actually manages to live up to its name. When form data is sent using the POST method, the information entered by the user is sent directly to the program's standard input. The program's output is passed directly back, just as if it had been a document retrieved from a file. Now, INTERCAL can't do much in the way of interacting with the outside world. (It's a bit autistic for a programming language.) It has no capabilities for accessing files and the like. But it can use the standard input and output. Of course, CGI also makes valuable information available through environment variables, and INTERCAL knows nothing of such objects. But a carefully designed program can make do without that information.
The original INTERCAL language (a.k.a. INTERCAL-72) had extremely constrained I/O. Reading the CGI data and outputting HTML would have been quite impossible. However, Eric S. Raymond, the person who created the Unix implementation of INTERCAL (with help from Louis Howell and others), wisely made extensions to the language several years ago to give it broader I/O capabilities. Though they had no way of knowing it at the time, this was all that was needed to allow INTERCAL programs to interface with the WorldWide Web.
When I realized that this was indeed possible, I determined to see it happen. All I needed was a worthwhile application. My friend Mike Hamrick was the one to suggest "Intersections & Splats", which I had created earlier as a normal standalone program. Five days later I had a fully functional version, and another five days later I pronounced it complete.
Simply that it is the first of its kind, being written entirely in INTERCAL, and unsupported by any intervening programs (such as a shell script). Though INTERCAL is fully capable of I/O, they are hardly its forte.
INTERCAL has many, but nobody has found a useful application for them yet.
The program is 993 lines long (including comments), nearly twice that of the original standalone program. Actually, it might have been substantially longer, but at the time, the compiler had a built-in limit of one thousand lines. While I could have just modified the compilier to increase the limit, I decided to put in the extra effort and optimize it down. Much of the program is devoted to generating the actual HTML, which contains, besides the visible elements, a string encoding the complete game state. This string (which is actually stored as the name of the text input field) is then sent back to the program when the person submits their guess, so that the new invocation can reconstruct the current state of the game. Once the output has been completed, the program is done, and exits directly.
The input section is much smaller, since the form data is tailored to be as brief as possible. (Unlike the HTML output, which demands a much greater amount of "dressing".) Numbers are encoded as letters from A to O, so the program can extract the original data through simple bit-masking, and without worrying about "special" characters getting encoded by the server.
It looks like INTERCAL, to be honest. If you wish, you can take a look at the source code and see for yourself. However, I can almost guarantee that you will not find it enlightening.
Like I said, it looks like INTERCAL.
Because it was there.