These fields are all optional and need only
be supplied if you would like a direct reply.
Your email address
Your real name
You must answer this!
If you don't, my spam filtering will
ensure that I never see your email.
What's 8 plus five (in digits only)?
Please make your changes here and then
Editing tips and layout rules.
File: NotIfYouHurry !! Not If You Hurry! ********> width=52% On one occasion, when I was a teenager, I was in the car with my parents going somewhere. Can't remember where, but that's irrelevant. We lived in a quiet suburban street, and we had reached the T-junction onto the main road. We had to turn right (which is equivalent to turning left in the States) and hence had to cross a lane of traffic and merge into the far lane. My father was looking to the right to see if there was anything approaching in the lane we had to cross, and asked my mother - "Is there anything coming?" The reply came - "Not if you hurry!" Now, in truth, whether there was something coming didn't depend on whether we hurried or not. As a result, when the question and answer were interpreted literally, the answer either didn't make sense, or was irrelevant. But in practice, it made a lot of sense. What my father really wanted to know was - "Is it safe to go?" What the reply really meant was - "If you hurry, there will be space and time." The "answer" was no answer to the question asked, but it did provide the information required, but which wasn't asked for. The literal interpretation was of no real value. This is a common problem in real life. "Natural language" descriptions rarely make sense when interpreted literally. Programmers know this all too well. Specifications are rarely clear, rarely complete, and never what the customer actually intends or wants. Programmers, of course, by their nature and inclination, tend to be very literal. Computers, after all, interpret their programs very exactly. It's a common form of humour among geeks of a certain type to interpret questions literally. "Do you want tea or coffee?" is often answered with a "Yes." Very helpful. Not. (As an aside, I was once in a group when the host asked "Does everyone want coffee?" One by one we all answered "Don't know" until the final person answered "Yes." We all thought that was hilarious.) So here is a critical skill, not often present in programmers: the ability to listen to something, and figure out what is intended, rather than what was actually said. Tough one. ******** width=4% ******** width=44% It's especially tough when people say something other than what they mean. Recently, for example, someone on the Hacker News discussion group said: * Everyone wants to be an entrepreneur. and this was "contradicted" by someone saying: * Everyone /doesn't/ want to be an entrepreneur. Well, that's simply not the opposite of the original statement. The correct opposite is: * Not everyone wants to be an entrepreneur. which logically translates to: * At least one person doesn't want to be an entrepreneur. or, more naturally, * Some people /don't/ want to be an entrepreneur. Some people say it doesn't matter, but these are simple questions of logic, and in their turn, questions of clear and unambiguous communication. In context it's easy enough for people to discard what was actually said and interpret it as what makes sense. Can you imagine programming a computer to understand these issues? How can we get a program to understand that when you say: * /Everyone/ doesn't want to be an entrepreneur. you actually mean: * /Someone/ doesn't want to be an entrepreneur. That seems hard, whether you hurry or not. ********< ---- !! Some references: * The discussion about people wanting to be entrepreneurs: * http://news.ycombinator.com/item?id=1207909 * Tim Gowers' discussion of natural language implication _ versus rigorous mathematical implication: * http://www.dpmms.cam.ac.uk/~wtg10/implication.html * The Hacker News discussion of that: * http://news.ycombinator.com/item?id=2121428 * Hacker News: * http://news.ycombinator.com