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.

• Everyone wants to be an entrepreneur.

• Everyone doesn't want to be an entrepreneur.

• Not everyone wants to be an entrepreneur.

• At least one person doesn't want to be an entrepreneur.

• Some people don't want to be an entrepreneur.

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.

• Someone doesn't want to be an entrepreneur.