Computer Science Discipline

I have been involved in Computer Science for a long time, every since that day in 1968 when I was handed a book on Fortran and told that I now a Fortran programmer. My first week I wrote three programs, one was trivial, it ran the first time through. The second was a graphics program, which generated graphics that were later published. Within the first year I had started programming in PL/1, and machine language (I didn't learn about assemblers until later). I was also looking at other languages.

I also had my first class in Computer Science (titled "Computer Science"). This was taught by Dennis Steele, and covered, as you might expect, Computer Science. We learned Fortran - or, for me it was a review, since I'd already been a programmer for two weeks. In addition, he taught us machine language by developing a machine language for an imaginary machine. The language was very simple, and lacked some of the features one would assume available.

We learned to program in his imaginary machine language. However, I also had a copy of the "Principles of Operation" for the IBM 360 computer, so when I was hire at Iowa State for the summer of 1969, my boss compiled his programs into object decks before running them. I was curious about how they were built, so I decoded one deck, and figured out what each column meant. Then I wrote a simple procedure in IBM 360 machine language, typed it onto a card with a keypunch, linked it with a main program, and ran it.

After that second summer, I continued with my Mathematics education, but I was using my programming ability to generate cash for living. And so it went.

Later, I programmed for many companies, in many languages, but to this day, Fortran is the only one I was taught in a classroom setting, and that was after I had already learned the language. I have programmed in Fortran, Pl/1, NEAT/3, 399 NEAT, Pascal (the teacher "taught" us that one - "This year we will be using Pascal. The program is due on Friday."), C, C++, and others. These are only the ones I used commercially, there is probably a longer list of languages I've studied, and maybe written a personal program in, such as lisp.

I have also studied Computer Science, getting my Master's degree in 1978, and my PhD in 1983. In each case, if anything, I thought the coursework was very simple. (I remember when I started my Master's program in 1975, I decide to sign up for a "qualifying test" about a month after I returned to school. You were supposed to take the class first, but I didn't, I just felt like failing one. In actual fact, I got a perfect score.)

After getting a PhD, I started teaching at the University of Missouri at Columbia, then the University of North Dakota, and finally at Park College. During this time I had time to think about how Computer Science ought to be taught, and I realized that there are some problems.

The effect of these problems are very evident to me today. For example, when I apply for a job, people ask and emphasis what languages I've programmed in rather than what algorithms have I used. To me, the longest its ever taken me to learn a language is about two days, so what difference does it make what languages I've used?

One obvious comparison for me, with a degree in Mathematics is to compare the field of Computer Science with Mathematics. The major difference is that Computer Science is a much newer discipline, formed in the 1950's, whereas Mathematics is a very old discipline.

The results are telling. First, programming languages are roughly equivalent to arithmetic, and could easily be taught in grade school. My youngest daughter learned HTML, which is a "programming language" for the Internet, when she was in the fifth grade, and she maintained a WEB site until she got tired of it some time in high school. (She is in charge of a WEB page now that she is in college, and recently wrote a program in C++.)

Programming languages in can get people to the point that they can tell the computer what to do - that is, they can write programs. It does not tell people how to make the computer do useful things, just as knowing how to do arithmetic doesn't allow anyone to do anything with mathematic, it just teaches people to work with abstractions called "numbers."

A quick review of the programs when I was teaching showed that the course "Data Structures" is the gateway to everything else. This course is roughly equivalent to a high school course in Algebra, and could be taught at that level. This introduces students to the concept that programs need to be organized, and abstractions used to break large programs into manageable pieces.

Finally, there are college level courses. These teach students things like how to write compilers, operating system, graphics systems, etc. Also, some of the previous courses are reused with more detail added. Therefore, there is typically a course in "Programming Languages."

This brings us to the biggest problem. Colleges emphasis learning a particular language or software product rather than learning general concepts. So much so that that's what employers expect. If someone has a course in Assembly Language, the assumption is that one particular type of assembly language will be taught.

I recall an incident that happened at the University of Missouri. I was teaching the Data Structures course, and I noticed that one of the prerequisites was assembly language, which was taught using IBM 360 assembly language. Therefore, I told the students that one program would be written in assembly. After the announcement, there was an audible groan from the students when I announced this. I gave them a review for maybe twenty minutes before releasing them to write the program. The resulting programs were actually quite good, and I had at least two students come up to me afterwards and thank me. In the Assembly class, they had primarily learned that assembly language was hard. Yet this assignment was no more difficult for them than if it had been in PL/1, which the other assignments were in, so these students appreciated being shown that Assembly language was not that hard.

I also recall a book (either Teaching as a Subversive Activity or Insult to Intelligence) which pointed out the importance of teachers realizing what they are teaching. In the example above, the Assembly Language class didn't teach assembly language in reality - it taught that Assembly Language is hard. Similarly, I have seen textbooks on programming languages that spend a lot of time on recursion. I usually skipped those sections, because in reality all they taught was that recursion is hard.

Recursion used for a recursively defined problem is easy. To attempt to force a primarily non-recursive problem into a recursive solution is also difficult.

(As a Computer Professional who has done research in programming languages, and in compiler writing, I can state that people who claim that recursive solutions are not "efficient" don't know what they're talking about. How the programmer represents a program, which is then run through a program called a compiler, is irrelevant. If they were run through a decent compiler they would generate the same code.)

I have to give credit to Dennis Steele. He taught assembly language correctly. That is, he wasn't worried about any particular assembly language, but rather he made a simple assembly language so people didn't have to understand each little detail of the assembler before they could do anything, and, on top of that, understand complex machine languages before they could learn to think in terms of machine language. What we studied is the thought processes that the programmer needs to go through to solve the problem, and let the student learn the particular language as it is needed.

This came in handy at least once. The NEAT/3 language, particularly NEAT/3 level 2 is, in reality, an assembly language for the NCR Century series of computers. I was presented a problem of displaying a standard deviation, which requires a square root. The problem is that the NCR Century computer had a simple machine language that did not include a multiply, let alone a square root. That is, NCR, being interested in business computing, had designed a computer where multiply was accomplished using subroutine calls.

Rather than being discouraged by the fact that any of the algorithms I had been taught would have made the resulting program prohibitively slow. I remembered an algorithm I had read in a book my mother gave me in junior high. The algorithm, when translated to base 2 was very simple, and fast. So much so that I can say it took almost exactly the same amount of time to find the square root of a number as it would take to multiply the results together to see if they were correct.

I also remember seeing a textbook for a programming language text which developed a simple new programming language for each chapter so the important points - how the programmer thinks about the problem - was abstracted from the details of the language. I did not teach from that book, but if I had I would have written a compiler for each of the simple languages, so students could have written in any of them. I don't know it the author did that or not. This would have taught the students how to think about programming languages rather than any particular language.

The real difference is that the student should be taught how to think rather than particular languages. When I took Physics as an undergraduate, this was illustrated. That is, when I listened to the teacher, I was learning how to think about physics. The other student told me that they were learning the equations he used for the presentation in class. Since they learned the equations, whenever they came up against something new, they were lost. I didn't notice when something new came up, since all I had learned was how to solve the problems.

Historically, I can see where the problem really originated. That is, about 1980, the general public became aware of computers. In those years almost half the Iowa State student body wanted to work for a degree in Computer Science. I was told the beginning classes increased in size by a factor of three in one year.

This would have been a good time for the Computer Science department to tighten the requirements, so only the brightest and best got into Computer Science. Instead, the requirements were relaxed so that everyone trying to get into the field was able to get a degree. This cheapened the degree, and today employers expect the cheapened degree. Therefore, I get rejected on job applications because the work is to be done in Java, and all I've used is C++, etc.

(The worse case was Pascal. The employer asked if I had taken a class in Pascal. I told him that I had taught the class, but that was not impressive enough, since the work order says I had to have taken the class.)

This cheapening of the Computer Science degree can, and probably has, resulted in loss of students. Why get a four year degree in Computer Science when you can learn the same thing in six weeks (so people think) in a more specialized school? And, since the specialized school is more likely to have classes in the languages the student will be expected to use, that gives them a leg up on the guy who wastes four years in a traditional college.

I'm not sure what the solution to this problem is. To an extent, it is a symptom of a larger problem - that is, people in the United States seem to ignore intelligence, or aptitude as a deciding factor in anything. That is, people don't think critically about what is going on around them. Politicians know this, and take advantage of it by saying whatever they think they need to say to get people to agree with them, with a total disregard for the truth. It is assumed that if you haven't taken a course in political science, then you cannot question the "experts."