What's actually involved in programming the actual process of writing programs? Here's a
quick overview of the process:
Write a program.
Compile the program.
Run the program.
Debug the program.
Repeat the whole process until the program is finished.
Let's discuss those steps one by one.
I have a small amount of bad news for you: you can't write programs in English. It would be

nice indeed to be able to type "count the number of words in a sentence" into your computer and
have it actually understand, but that's not going to happen for a while (unless someone writes a
program to make a computer do that, of course). Instead, you have to learn a programming
language.
Much of a programming language is indeed in English. Programming languages commonly
use words like "if", "repeat", "end" and such. Also, they use the familiar mathematical operators
like "+" and "=". It's just a matter of learning the "grammar" of the language; how to say things
properly.
So, we said "Write a program". This means: write the steps needed to perform the task,
using the programming language you know. You'll do the typing in a programming environment
(an application program which lets you write programs, which is an interesting thought in itself).
A common programming environment is CodeWarrior, and another common one is InterDev, but
you don't need to worry about those just yet. Some programming environments are free, and
some you have to buy just like any other application program. Commercial (non-free)
programming environments cost anything from $50 to $500+, and you'll almost always get a
huge discount if you're a student or teacher of some kind.
Incidentally, the stuff you type to create a program is usually called source code, or just code.
Programmers also sometimes call programming coding. We think it sounds slightly cooler.
In order to use a program, you usually have to compile it first. When you write a program
(in a programming language, using a programming environment, as we mentioned a moment
ago), it's not yet in a form that the computer can use. This isn't hard to understand, given that
computers actually only understand lots of 1s and 0s in long streams. You can't very well write
programs using only vast amounts of 1s and 0s, so you write it in a more easily-understood form
(a programming language), then you convert it to a form that the computer can actually use. This
conversion process is called compiling, or compilation. Not surprisingly, a program called a
compiler does the compiling.
It's worth mentioning that if your program has problems which the compiler can't deal with,
it won't be able to compile your program.
You'll be pleased to hear that your programming environment will include a suitable compiler
(or maybe more than one compiler: each different programming language your programming
environment allows you to use requires its own compiler). Compilers are just fancy programs, so
they too are written by programmers. Programmers who write compilers are a bit like gods; they
make it possible for everyone else to program.
Now that you've compiled the program into a form that the computer can use, you want to
see if it works: you want to make the computer perform the steps that you specified. This is
called running the program, or sometimes executing it. Just the same as how a car isn't of much

use if you don't drive it, a program isn't of much use if you don't run it. Your programming
environment will allow you to run your program too.
You've probably heard the term "debug" before (it's pronounced just as you might expect:
"dee-bug"). It refers to fixing errors and problems with your program. As I'm sure you know, the
term came about because the earliest computers were huge building-sized contraptions, and
actual real-life insects sometimes flew into the machinery and caused havoc with the circuits and
valves. Hence, those first computer engineers had to physically "debug" the computers they had
to scrape the toasted remains of various kinds of flying insects out of the inner workings of their
machines. The term became used to describe any kind of problem-solving process in relation to
computers, and we use it today to refer purely to fixing errors in our code.
You may also have heard the phrase "it's not a bug, it's a feature". Programmers sometimes
say this when someone points out a problem with their programs; they're saying that it's not a bug,
but rather a deliberate design choice (which is almost always a lie). This is rather like
accidentally spilling coffee all over yourself whilst simultaneously falling down some stairs, then
getting up and saying "I meant to do that".
Once again, your programming environment will help you to debug your programs (indeed,
you'll often find the picture of an insect shown in your programming environment to indicate
debugging). You usually debug your program by stepping through it. This means just what it
sounds like: you go through your program one step at a time, watching how things are going and
what's happening. Sooner or later (usually later), you'll see what's going wrong, and slap yourself
upside the head at the ridiculously obvious error you've made.
And then you repeat the whole process until you're happy with the program. This is trickier
than it might sound, since programmers are never happy with their programs. You see,
programmers are perfectionists never satisfied until absolutely everything is complete and
elegant and powerful and just gorgeous. Programmers will commonly release a new version of
their program every day for a couple of weeks after the initial release.
As you can imagine, enjoying an intellectual challenge is an important trait to have when
you're going back to correct and enhance your code many times over. You'll actually find that you
can't wait to get back into your program and fix the bugs, make improvements, and refine the
existing code.
And that's the basic process of programming. Note that most programming environments
will make a lot of it much easier for you, by doing such things as:
Warning you about common errors
Taking you to the specific bit of code which is causing the compiler to puke
Letting you quickly look up documentation on the programming language you're using
Letting you just choose to run the program, and compiling it automatically first

Colouring parts of your code to make it easier to read (for example, making numbers a
different colour from other text)
And many other things
So, don't worry too much about the specifics of compiling then running then debugging or
whatever. The purpose of this section was mostly to make you aware of the cyclical nature of
programming: you write code, test it, fix it, write more, test it, fix, and so on.

1, fancy  ['fænsi]
n. 幻想；想像力；爱好
adj. 想象的；奇特的；昂贵的；精选的
vt. 想象；喜爱；设想；自负
vi. 幻想；想象

2, contraption  [kən'træpʃən]
n. 奇妙的装置
3, havoc  ['hævək]
n. 大破坏,蹂躏
4, valves 
n. 阀门；瓣膜（valve的复数）；真空管
v. 装阀于…；以活门调节（valve的三单形式）
5, insects 
昆虫纲
昆虫类
6, circuits 
n. 电路
7, scrape  [skreip]
n. 刮掉,擦掉
v. 刮掉,擦掉
8, toasted 
adj. 烤的
v. 烤（toast的过去分词）；敬酒
9, spilling  ['spiliŋ]
泄漏
10, whilst  [wailst]
conj. 当...时(可是,虽然,只要)
11, slap  [slæp]
n. 掴,侮辱,拍击声
v. 拍击,侮辱,申斥
ad. 正面地,直接地,突然地
12, ridiculously 
ad. 可笑地
13, gorgeous  ['gɔ:dʒəs]
a. 华丽的,灿烂的,好极了
14, trait  [treit]
n. 特征,特点,特性