November 17, 2003
CAPTCHA poetry

If you've tried to log onto a web service lately -- such as Yahoo's free email, or Ticketmaster -- you've probably seen a CAPTCHA. That's the ungainly acronym for a Completely Automatic Public Turing test to tell Computers and Humans Apart. A CAPTHCA is a technique for stopping spambots from commandeering a web site. The test asks you to identify a little picture -- usually a stretched or skewed word -- before you go any further. Since people can identify pictures very easily, but computers can't, it stops the spambots cold. The end result, though, is that the Internet is now flooded with these colorful little pictures of distorted words.
Now programmer Patrick Swiekowski has written a script that automatically collects CAPTCHA images from AOL's screen-name signup process, and displays them four at a time on a web page, as a form of poetry. The page refreshes every few seconds, so it's kind of like reading a robotized version of fridge-magnet poetry -- four words juxtaposed in strange and often eerie ways. I watched it refresh for a couple of minutes and saw the following "poems":
long flag
power even
bath with
dust market
side berry
feeble near
rice swim
letter good
drop soup
thread there
That's the most compressed literary form I've ever seen! Ultra-haiku.
(Thanks to Lonnie Foster's Tribblescape for this one!)
Posted by Clive Thompson at November 17, 2003 11:21 PM
| TrackBack
I think I saw this in Acta.
Ahahha! We probably could have filled ACTA with reams of poetry generated by robots, and nobody would have known.
"Sneeze Attack Market Place"
These secret identities serve a variety of purposes, and they help us to understand how variables work. In this lesson, we'll be writing a little less code than we've done in previous articles, but we'll be taking a detailed look at how variables live and work.
Earlier I mentioned that variables can live in two different places. We're going to examine these two places one at a time, and we're going to start on the more familiar ground, which is called the Stack. Understanding the stack helps us understand the way programs run, and also helps us understand scope a little better.
Let's see an example by converting our favoriteNumber variable from a stack variable to a heap variable. The first thing we'll do is find the project we've been working on and open it up in Project Builder. In the file, we'll start right at the top and work our way down. Under the line:
The rest of our conversion follows a similar vein. Instead of going through line by line, let's just compare end results: when the transition is complete, the code that used to read:
When Batman went home at the end of a night spent fighting crime, he put on a suit and tie and became Bruce Wayne. When Clark Kent saw a news story getting too hot, a phone booth hid his change into Superman. When you're programming, all the variables you juggle around are doing similar tricks as they present one face to you and a totally different one to the machine.
When the machine compiles your code, however, it does a little bit of translation. At run time, the computer sees nothing but 1s and 0s, which is all the computer ever sees: a continuous string of binary numbers that it can interpret in various ways.
To address this issue, we turn to the second place to put variables, which is called the Heap. If you think of the Stack as a high-rise apartment building somewhere, variables as tenets and each level building atop the one before it, then the Heap is the suburban sprawl, every citizen finding a space for herself, each lot a different size and locations that can't be readily predictable. For all the simplicity offered by the Stack, the Heap seems positively chaotic, but the reality is that each just obeys its own rules.
Inside each stack frame is a slew of useful information. It tells the computer what code is currently executing, where to go next, where to go in the case a return statement is found, and a whole lot of other things that are incredible useful to the computer, but not very useful to you most of the time. One of the things that is useful to you is the part of the frame that keeps track of all the variables you're using. So the first place for a variable to live is on the Stack. This is a very nice place to live, in that all the creation and destruction of space is handled for you as Stack Frames are created and destroyed. You seldom have to worry about making space for the variables on the stack. The only problem is that the variables here only live as long as the stack frame does, which is to say the length of the function those variables are declared in. This is often a fine situation, but when you need to store information for longer than a single function, you are instantly out of luck.
This will allow us to use a few functions we didn't have access to before. These lines are still a mystery for now, but we'll explain them soon. Now we'll start working within the main function, where favoriteNumber is declared and used. The first thing we need to do is change how we declare the variable. Instead of
But some variables are immortal. These variables are declared outside of blocks, outside of functions. Since they don't have a block to exist in they are called global variables (as opposed to local variables), because they exist in all blocks, everywhere, and they never go out of scope. Although powerful, these kinds of variables are generally frowned upon because they encourage bad program design.