| Main Menu | Next Chapter |
Programming is both a science and an art. That is part of the
excitement. To be sure, there are plenty of rules to follow when
writing a program and, since the interaction is with a machine,
it has a certain mechanical nature to it. But, any program you
write is yours. It came out of your head and is the product of
your creative juices. This is especially true as you venture beyond
the basic formats presented in class and this text. We urge you
to discover the fun of that creative process by exploring and
experimenting. You can't write a program that will hurt the computer,
so go for it!
A. So What is Programming Anyway?
But, what does it mean to 'program a computer'? If you program
your VCR (something at least one of the authors rarely does because
it is too much hassle - a strange thing for a Computer Scientist
to say), you tell the VCR exactly what you want. "Record
the signal being transmitted on channel 6 between 9 and 10 PM
on June 18, 1996."
When you program your VCR, you 'tell' the VCR exactly what you want it to do. Perhaps the command is: "Record the signal being transmitted on channel 6 between 9 and 10 PM on June 18, 1996." Of course, one doesn't speak directly to the VCR, but that is not the issue. The thing to observe is how precise you have to be in instructing the VCR - whether one speaks directly to it or pushes buttons on a remote. It is not acceptable to just say or type, "Please record "E.R." next Tuesday. That is one of the first things you will learn about computers and programming - the instructions must be given in great detail and with no errors or ambiguities. To put it differently,
Everyone who has ever used a computer knows this. If
you type "COPPY" at a computer keyboard when you mean COPY,
the computer just sits there - or worse, gives back one of those
delightful computer error messages. Contrast this with human behavior.
If the sentence above was, "Computers Is Stupid", you
may wonder about the authors' knowledge of English but you would understand
the message.
Because computers are stupid, the languages we use to communicate
our instructions to them must be precise. You can't leave a computer
'guessing' or needing to figure out which of many items you are
referring to. Ambiguity is not allowed! For example, even if you
have only been working with one file for the last hour, you
can't type, "COPY IT". You must give the computer the
name of the file in order to avoid any ambiguity. (Researchers in the area
of artificial intelligence do hope someday to develop
the kind of programs that will provide computers with the smarts
to handle ambiguity and error but that is a long ways off. More important for us, the
program that provides the smarts will be written in the
precise, detailed way being discussed here.)
You may have observed situations involving computers where some
ambiguity seemed to be OK. For example, in operating systems
such as DOS and Unix you do not always have to tell the system
which disk drive you want to copy from. That is because the programmer
of the copy command specifically wrote into the code the rule:
Somebody had to handle the ambiguity - but it was not the computer!
B. Details, Details, Details
Avoiding errors and ambiguity is not easy, especially when a program
has to include every little detail about the problem at hand.
You can't just give a computer the command "calculate the
sum of the numbers in this file". You have to tell the computer
to:
At this point we have learned a few things about computer programs:
C. Programming Languages
In the VCR "programming" example above there was one
long instruction. Actually, to program a VCR one makes a number
of selections (for time, date, AM/PM, channel etc.) using a remote.
Much the same thing happens when one uses a mouse with a computer.
The instructions for processing the choices one makes (with the
remote or the mouse) are translated into a set of instructions
for the computer. In other words, the one long instruction above
would get translated into a set of instructions to be handled by the VCR's
computer. (Yes, a VCR contains a small, special purpose computer.)
What we are seeing here are different levels for communicating with a computer. Computers directly 'understand' only what is referred to as machine language. This is a language of 1's and 0's (or more precisely two voltage levels), a language that humans have a most difficult time programming in.
Actually,
there a number of machine languages, different ones for different
computer architectures. For example, the so-called IBM compatibles
understand one machine language, Macintosh computers understand
a different machine language, and RISC based Unix workstations
understand yet other machine languages. Each of these machine
languages has its own way of saying "Add these two numbers" or
"Check to see if the value in this memory location is greater
than 0." This is why you can't run software written for a Macintosh
on a PC or vs. versa. If a piece of software can be run on both
types of computers, it has been written in both languages - or
somehow translated from one to the other.
Computer Scientists long ago said "Forget it!" to this
type of language and began the search for an easier way to communicate
with a computer. The first practical step
was Assembly Language, a language that pretty much follows
the format of machine language but has simple word-like codes corresponding
to the fundamental instructions of the computer architecture.
For example, in assembly language the word 'Add' might be used to represent the combination of
1's and 0's that mean add at the machine language level. A programmer would write a program
in assembly language and then run a program (often called an Assembler)
that translated the program into machine language. And, guess
what - the assembler was probably written in machine language.
(Modern assembly languages are quite complex but here is a relatively simple example.)
This was an improvement but still programming was a slow, tedious
process and the programmer spent too much time on tiny details.
The next step involved the creation of the so called third generation languages
(after machine language and assembly language). These languages allowed one to
write one instruction that looked a bit like simple English (or Spanish or ...)
and that became a number of machine language instructions when compiled. For
example, one
could write one instruction that told the computer to do some
set of instructions 30 or 50 or 2000 times or tell the computer
to make some kind of comparison as in:
Now programs were at least semi-readable and a programmer could
focus more on the actual problem being solved.
Fortran was the first language of this type. Cobol, Pascal, Basic,
and 'C' followed later. 'C++, the language you are studying here',
is a later, cleaned up version of 'C' with a number of important
additional features.
Just as with Assembly language, programs written in these newer,
third generation languages need to be translated into machine
language. Whatever language one writes in, there must be a translator
program that turns the code you write into machine language. For
third generation languages such translators are called compilers.
Languages other than machine language all have their own compilers
and, as a matter of fact, each version of a language (such as GNU C++ or
Microsoft C++ or Borland C++) has its own compiler. A C++ compiler
takes a file (or as we will see, a set of files) containing
C++ code and attempts to translate it (or them) into the machine language
for some computer architecture, for example, Pentium PC's. If
the compiler encounters one or more lines of code that it cannot
understand because the programmer has made a 'grammatical' mistake
in the use of C++, it outputs error messages and does not complete
the translation. Only successfully translated code can be executed.
You will need to learn how to compile whatever version of C++
you are using. Actually, you will need to learn much more
than how to compile. Modern programming languages come with a
sophisticated environment for writing, compiling, and debugging
programs and you will need to have some understanding of how to take advantage
of these.
There have been further advances in programming languages. One
focus has been on creating languages that are even more human
like in form or style. These are the so-called fourth and fifth
generation languages.
A second focus has been on creating languages that support a more human like form of problem solving or that have more sophisticated ways of representing the complexities of a programming problem. This is where we will focus much of our energy in the following pages - on ways to capture the complexity of the real world in our programs. This is also one of the strengths of C++ and one of the reasons it is the language of this text.
D. The Issue of Complexity
We start this section with an important observation:
Computer programs are both models of complexity and complex
products in themselves.
OK, so what does this mean? First, let's deal with "Computer
programs are models of complexity.…" It may surprise
you to know that computer scientists sometimes debate whether
or not Computer Science is a science at all. And, if it is, what
is the special area of study for this science. One possible answer
(the favorite of one of the authors) is that Computer Science
explores modeling, specifically, how to best create computational
models of the complexities of the real world - or even imaginary
worlds as in computer games. (For the moment allow us to cheat
on the word 'computational' and simply let it mean 'executable
on a computer'.)
From this perspective, a computer program is a model of some aspect
of some part of some world. If whatever being modeled is at all
complex, then the computer program is a model of that complexity.
We will see that capturing the complexity of a 'world' can be
a serious challenge, requiring the best tools available.
And now for the second part of that sentence:
Computer programs are not simple things. The complexity they are attempting to model often makes the programs themselves quite complex - thousands upon thousands of lines of code using thousands of names for memory locations. Imagine a song with thousands's of verses and hundred's of different possible refrains. Then imagine that sometimes part of a verse is mixed in with part of another verse, that verses are sung with one set of chords sometimes and with a different set of chords other times, and that verses and refrains are sometimes repeated multiple times. Oh, and don't forget that there are various harmonies, keys, and rhythms. Put all this and you have some sense of the complexity of large programs.
E. Software Engineering
So now we have two issues: how to best capture/model the complexity
of the problem (world) under consideration and how to best manage
the complexity of the programming task itself. In many cases,
the same tools can be used to handle both kinds of complexity
and that is the way we will leave things for the moment.
The discipline or 'science' of managing both these types of complexity
is called software engineering and will be a major emphasis of
this material. Over the years there have been many strategies and
tools developed to help manage program complexity. Some of them,
such as the use of descriptive names for the memory used in
a program or the use of comments, and good indentation
are relatively simple. Others involve a potentially complex analysis
of the programming task. All are a mixture of creativity and discipline.
Any creative activity which is meant to be brought to fruition
requires discipline. The writer must write and rewrite that poem
or novel. The painter must prepare paint and canvas then work
and rework that piece of art. The musician must spend long hours
practicing, creating just the right combination of effects in
voice and instruments. The computer programmer must carefully
analyze and design a program before writing any code, then, write
and re-write the code to get it to perform exactly as required,
do so efficiently, provide an easy to work with user interface,
and be easy to understand and modify.
Much of this material is devoted to discussing basic software engineering
strategies and tools we will expect you to incorporate into the
programming process. Some of these strategies and tools are not necessarily fun or
creative but when properly used they will allow you to handle
the complexity of the task you have been given. As you use them,
try to remember that they are the fruit of other people's frustration
with failed or very difficult programming efforts. They represent
proven techniques to ultimately make the programming task easier.
And, an easier task is a more fun task!
 Top of Chapter |
Main Menu | Next Chapter |