FORMAL AND NATURAL LANGUAGES Natural languages

6
The Way of the Program
For example, when you hear the sentence “The penny dropped,” you understand that
“the penny” is the subject and “dropped” is the predicate. Once you have parsed a
sentence, you can figure out what it means, or the semantics of the sentence. Assum-
ing that you know what a penny is and what it means to drop, you will understand
the general implication of this sentence.
Although formal and natural languages have many features in common – tokens,
structure, syntax, and semantics – there are some differences:
ambiguity: Natural languages are full of ambiguity, which people deal with by
using contextual clues and other information. Formal languages are designed
to be nearly or completely unambiguous, which means that any statement has
exactly one meaning, regardless of context.
redundancy: In order to make up for ambiguity and reduce misunderstandings,
natural languages employ lots of redundancy. As a result, they are often
verbose. Formal languages are less redundant and more concise.
literalness: Natural languages are full of idiom and metaphor. If I say, “The
penny dropped,” there is probably no penny and nothing dropping.
∗
Formal
languages mean exactly what they say.
People who grow up speaking a natural language – everyone – often have a hard
time adjusting to formal languages. In some ways, the difference between formal
and natural language is like the difference between poetry and prose, but more so:
Poetry: Words are used for their sounds as well as for their meaning, and the
whole poem together creates an effect or emotional response. Ambiguity is
not only common but often deliberate.
Prose: The literal meaning of words is more important, and the structure con-
tributes more meaning. Prose is more amenable to analysis than poetry but
still often ambiguous.
Programs: The meaning of a computer program is unambiguous and literal, and
can be understood entirely by analysis of the tokens and structure.
Here are some suggestions for reading programs (and other formal languages). First,
remember that formal languages are much more dense than natural languages, so
it takes longer to read them. Also, the structure is very important, so it is usually
not a good idea to read from top to bottom, left to right. Instead, learn to parse the
program in your head, identifying the tokens and interpreting the structure. Finally,
the details matter. Small errors in spelling and punctuation, which you can get away
with in natural languages, can make a big difference in a formal language.
1.5
THE FIRST PROGRAM
Traditionally, the first program you write in a new language is called "Hello,
World!"
because all it does is display the words, "Hello, World!" In Python, it
∗
This idiom means that someone realized something after a period of confusion.

1.6 Debugging
7
looks like this:
print 'Hello, World!'
This is an example of a print statement,
†
which doesn’t actually print anything on
paper. It displays a value on the screen. In this case, the result is the words
Hello, World!
The quotation marks in the program mark the beginning and end of the text to be
displayed; they don’t appear in the result.
Some people judge the quality of a programming language by the simplicity of the
"Hello, World!"
program. By this standard, Python does about as well as possible.
1.6
DEBUGGING
It is a good idea to read this book in front of a computer so you can try out the
examples as you go. You can run most of the examples in interactive mode, but if
you put the code into a script, it is easier to try out variations.
Whenever you are experimenting with a new feature, you should try to make mis-
takes. For example, in the "Hello, World!" program, what happens if you leave
out one of the quotation marks? What if you leave out both? What if you spell print
wrong?
This kind of experiment helps you remember what you read; it also helps with debug-
ging, because you get to know what the error messages mean. It is better to make
mistakes now and on purpose than later and accidentally.
Programming, especially debugging, sometimes brings out strong emotions. If you
are struggling with a difficult bug, you might feel angry, despondent, or embarrassed.
There is evidence that people naturally respond to computers as if they were people.
††
When they work well, we think of them as teammates, and when they are obstinate
or rude, we respond to them the same way we respond to rude, obstinate people.
Preparing for these reactions might help you deal with them. One approach is to think
of the computer as an employee with certain strengths, like speed and precision, and
particular weaknesses, like lack of empathy and inability to grasp the big picture.
†
In Python 3.0, print is a function, not a statement, so the syntax is print(
'
Hello, World!
'
). We
will get to functions soon!
††
See Reeves and Nass, The Media Equation: How People Treat Computers, Television, and New Media
Like Real People and Places.

8
The Way of the Program
Your job is to be a good manager: find ways to take advantage of the strengths
and mitigate the weaknesses. And find ways to use your emotions to engage with the
problem, without letting your reactions interfere with your ability to work effectively.
Learning to debug can be frustrating, but it is a valuable skill that is useful for many
activities beyond programming. At the end of each chapter there is a debugging
section, like this one, with my thoughts about debugging. I hope they help!

tải về 1.38 Mb.

Chia sẻ với bạn bè của bạn: