1. Preliminary Note
Be very careful when reading manuals, books, or handouts (like this one) pertaining to computers and Computer Science. They are written by people who already know the computers. They are also notoriously hard to read. Often, they are very exact - each word has a meaning and an exact and unique meaning. Individuals should read pertinent information BEFORE trying to do anything on a machine. To do otherwise is like being a wrong-way driver on a freeway on-ramp - ignoring the signs and going on anyway. You have to expect trouble if you fail to read important information carefully before you attempt something significant.
2. Introduction to the Course
Over the years, the introductory course to Computer Science as taught in the Mathematics and Computer Science Department has changed several times. Originally, three things were taught: (1) workings of a computer (introduction to machine architecture, now taught in COEN 21); (2) machine language (now taught in COEN 20); and (3) Fortran IV (Fortran-90/95 is now taught in Math 60).
Since 1982, the course has been re-structured and updated (sometimes yearly) based on the most recent national recommendations, the computers currently available at Santa Clara, and the development of computer languages. Now, this course covers the following topics:
The language BASIC or Pascal is not taught in this course, and previous programming experience is not considered a prerequisite for the course either. This is a first course in Computer Science for majors, but also a general course for other majors as well.
There is much to learn about any computer language, but we will not cover every aspect/feature of C++. One reason is that few people have ever had to use every feature of a specific language. Another reason is that some of the subtleties of the languages are only grasped after a few years of use. THEREFORE, don't expect to be able to program Tetris by the end of the quarter.
Instead, what I hope to do is to teach (1) the basics of C++, (2) a disciplined method of programming, and (3) a way of learning (from books and manuals) further features of C++ and other programming languages.
I will also point out local implementations/features of languages (i.e., the things that don't match the textbooks).
This course may make reference to other widely used languages, such as Fortran-90/95 and Java. Much of the syntax of Java is very similar to that of C++ although there are some significant differences. ( Fortran is the old standby and still very good for numerical calculations and, like English, it is widely used, particularly by numerical analysts, but no one really likes some of the out-dated style and rules. Fortran-90/95 is the subject of Math 60, taught in the winter quarter.)
3. Comment About Three Related Concepts
One has to distinguish carefully between three concepts related to computers. All of them involved ``commands,'' but they are used differently and must be kept separate in one's mind.
Don't forget your password for your account and don't make it obvious (do not use `JOSHUA' a la the movie War Games, do not use your name or initials), don't give it to others (not even to your ``best'' friend-you are responsible for what happens from your account), change it once or twice during the quarter.
5. Health Concerns
Recent studies have indicated a repeated problem associated with long hours behind a computer-physical stress. People have developed eyestrain, ``typist''-cramp, carpal tunnel syndrome, and back strain due to not moving enough and over-concentration on the screen.
SOLUTIONS: 1) Do not spend a significant length of time at a computer without taking a break (even if for only 10 minutes an hour). 2) Remember that the computer is supposed to help you-you are in charge, even if it doesn't seem to understand you.
6. First Courses: Techniques and Creativity
Like first courses in many subjects, Math 10 teaches a lot of basics and a lot of techniques. Realize that people learn techniques by practice, and much of this course consists of hands-on practice by writing programs. Also, we have to be content with basics: We can't write great literature after just one course in English. Similarly with Computer Science: Don't expect to be able to re-write the program for the air traffic controllers after this one course. Computer Science (like math in general or even music or art) has two sides to it.
Creativity vs. Techniques
NOTE THE DIFFERENCES BETWEEN
|creating proofs||using old math ``formulas''|
|writing new music||playing an instrument|
|writing programs||following language rules|
It is very hard to teach creativity, since it takes long practice on the part of the learner. It is easier to teach and learn techniques, but they only go so far.
7. Images of Computer Science
Just because you can type and speak English, you will not automatically become another Shakespeare. Just because you drive a car or use plumbing, does not qualify you to fix a car or be a licensed plumber. Just because you can play a piano or a guitar, does not mean you are also a great composer.
In teaching someone how to ride a bike, one says: ``you put your feet on the pedals and move them up and down, hold the handlebars to steer in the correct direction, and keep your balance.'' What more can you say?
Part of using a computer is like writing symphonies or riding a bike - only so much can be taught - an instructor can only give so many rules and instructions. This course tries to teach a method. It is trying to teach how to use a computer and write programs. These are mainly self-taught skills, like music or bike-riding.
This first course also will teach some theoretical computer science, such as algorithms for searching and sorting, which are not bound to one specific computer language. Similar to a first course in music theory, this course will cover techniques (i.e., rules of the computer language) and will try to help you become creative with those techniques (i.e., write programs). Note, however, that it is relatively easy to teach technique, but no teacher can (easily) teach you how to be a great programmer (or musical composer).
8. Introductory Computer Science Courses
Introductory computer courses across the country have notorious reputations.
Some perceptions are true: courses are hard, time-consuming, and frustrating. Some perceptions may not be so true: bad teachers, worse books. Often times, machines are thought to be inadequate - too few machines in labs, and the multi-user system is always down.
I'll try to make the course as painless as possible. However, beware that there is a certain amount of difficulty to be expected, and, at times, frustration. A Purdue University Study (reported February 1984) said that over 5 year period, 65% of CS majors dropped out of the program and changed majors!
One of the greatest problem is reading instructions and not understanding or thinking they don't apply. It is like wrong-way drivers on freeways. They see ``DO NOT ENTER - WRONG WAY'' and think the sign doesn't apply to them. Remember what you read and try to apply it!
9. Translation - Compiling
Computers don't (directly) understand C++ or Java or Fortran or BASIC. They understand ``Machine Language.'' A machine language program would be similar to a program written for a programmable pocket calculator (e.g., HP).
The computer tries to translate a program written in C++ or Fortran into a new program in its own code, and then runs its own program. This process is called compilation and the program which does the translation is called the compiler. If the compiler is unable to make a complete translation because the programmer incorrectly typed the program (typos or incorrect use of statements), the compiler will give a list of errors. If no compiler errors appear, then the (translated, machine language) program can then be run. Running the machine language program is called execution. The original C++ program is also called the SOURCE program and the machine language program is called the OBJECT Code.
When the compiler cannot translate a program because it was mis-written, e.g., the rules of the language were not followed, it gives error messages. Carefully read these error messages. Sometimes, not all errors are caught. Usually the messages tell you the line to look at, although, sometimes you have to look at the previous line. You can then re-edit your program file and correct the errors, and try to compile again.
Some compilers have powerful debug features. Debuggers usually enable you to step through a program, line by line. This line by line step-through is particularly useful when a program ``runs'' without any compiler errors, but the answers are still wrong!
10. Introduction to ``Programming''
Whether you use a natural or artificial (i.e., computer) language, you must learn by practice. The proof that you can use a computer language is if you manage to communicate with a computer, i.e., if a machine accepts your ``program'' and does what you want it to do.
THEREFORE, in this course, there will be 10 programs to aid you in learning the computer language.
11. Programming Steps
A lot of time and energy is spent in programming. Referring to these steps of programming just listed, if you are a good programmer and lucky, steps 3 and 4 will equal steps 1 and 2 in length of time. If not, step 4 (de-bugging) alone can take 5-6 times longer than the first three steps. A 1973 Department of Defense study on the cost of programming suggested that it took $75 per instruction for (initial) development of a program, but it took $4000 per instruction for maintenance!
12. Definition of Programming
Programming is the (creative) art of breaking a problem into minute details and (technically) coding these details in some technical ``computer language.'' Many people have said, ``Computers will always do what you tell them to do-however, this is not always what you actually want them to do!'' Be concerned about details! Programming can be an exercise in frustration because it shows us our shortcomings and lack of foresight. As the proverb says, ``The devil is in the details.''
Prof. Don Knuth, professor emeritus of the Department of Computer Science at Stanford, in fall 1998 suggested that ``about 2 percent of the general population has this way of thinking that makes them born to program ... A lot of people can write code, but I'm talking about people who are really in sync with computers.'' Thus, for many people, programming will not be easy to learn!
13. Writing Programs
The basic concept in programming is to be able to organize what you have to do in sequential order. In other words, you must decide what comes first, what comes second, what comes next, etc.
E.g., Graduation Program
1. National Anthem
3. President's address
4. Awarding of Honorary degrees
5. Key address
6. Awarding of student degrees
7. Valedictory speech
The general rule is the next step is not done until the previous step is completed. This rule also holds true for computer programs.
We must also be careful of (unwritten and unconscious) assumptions! In the graduation program above, we make certain (unwritten) assumptions: We assume that both the students and the faculty have marched in and that the guests in the audience have arrived! We don't normally start the national anthem if no one is on stage or if they are still marching in!
In computer programs, we almost always have to be explicit about everything and cannot leave any assumptions unwritten!
Always have a program written before going to a workstation. NEVER write your program from scratch at the computer without some sort of pre-written code. You will probably waste a lot of time, and possibly keep someone (more prepared?) from using the computer you are occupying.
14. Breaking a Problem Apart
The major problem in writing programs is often learning how to break a problem apart to a coherent sequence of programming steps.
A helpful first step is to write out the individual steps in English.
For example, take the problem of converting Arabic numerals to Roman numerals, e.g., 23 Þ XXIII.
We need to analyze our own (unconscious) thought patterns.
Where did the XX come from?
Where did the III come from?
How do you (mathematically, i.e., using plus, minus, times, divide) ``break apart'' 23 into 2 and 3? How do you make sure that you don't break apart 23 into a 3 and a 2 and get XXXII!
How do you explain what you did (mathematically)?
For practice, look at the sample problems given in section 21 below. Spend a few minutes thinking about a solution to problem 1 (describe how to tie your shoe laces) and the first part of problem 4 (breaking a 4-digit number into the 4 separate digits).
15. Programming Hints
16. Programming Style
A good programming style has the following characteristics:
Programs should (and, for this course, MUST) have three types of comments:
This is a block indicating 1) the title of the program, 2) the programmer's name, 3) the date it was developed, 4) other useful information (e.g., course and instructor).
In C++, the variable names should be chosen to be self-evident (i.e. do not use x to refer to miles!). However, in other languages, restrictions on the length of identifiers may force an explanation section of what role certain variables play in the program, which are input variables, which are output variables, which variables change values, etc.
Sub-sections and sub-structures should be identified. Rarely does one see a program ``over-commented.'' Unknown algorithms (or algorithms or theorems not easily recognizable) should also be indicated. Sometimes closing braces (or ``end'' statements) should be labeled to distinguish multiple occurrences.
19. Rules for Machine Problems/Programs
·check if variables are misspelled or not declared
·check for missing semi-colons
·check for unbalanced blocks delimiters (braces).
21. Sample Problems
Take any four-digit number (with not all 4 digits being the same). Re-arrange its digits in two different ways-lowest to highest, and highest to lowest. Subtract the smaller new number from the larger new number to obtain another number. Repeat this process (of re-arrangement and subtraction) seven times each time using the final new number.
Is there any pattern?
22. Brief History of Programming Languages
Early computers had limited memory and no auxiliary storage. This required short programs with tricky techniques. Programs were almost always written in machine language or sometimes in ``assembly'' (in which abbreviations are used instead of numerical codes).
The first few wide-spread languages appeared ( Fortran and COBOL). Improvements in hardware, particularly in memory technology, enabled languages to be designed with features making it easier to program (Algol, Algol-68). This led to fewer mistakes and more readable code. There was a new concern to make newer language definitions more exact and mathematical (by using ``BNF'' definitions of languages).
Revisions of older languages were common along with the development of special purpose languages. The development of ``super-computers'' with vector and parallel processing possibilities complicates the revision of older languages.
FORTRAN (55) | | ALGOL(60) COBOL(60) (FORTRAN II) JOVIAL(60) | EULER | | | | PL/I(65) | | FORTRAN IV(66) | | BCPL(67) | | Pascal | | | (1st draft 68) | | ALGOL-68 | | | (1st compiler 70) B(70) (WATFIV) (rev'd 73) | | | C(72) FORTRAN 77 | | | Ada (82) | | | Modula-II (83) | | | C++(84-88) | Oberon (88,89) | FORTRAN 90 Java(90-93) | | | | FORTRAN 95 Java 1.0 (95) C++(ANSI-96) | Java 1.1 (97)