From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Newsgroups: comp.edu,comp.lang.misc
Subject: Re: Programmers
Date: 9 Sep 92 20:15:53 GMT
Organization: Purdue University Statistics Department

In article <BuBBoJ.un@rice.edu> sabry@rice.edu (Amr Sabry) writes:

>Many people on this net implied that whoever can write a matrix
>multiplication subroutine in Fortran is a programmer.

>Based on courses here at Rice University, here is a minimum list of
>*concepts* that a real programmer should know:

This has some not needed by even an excellent mathematical programmer,
but is lacking in some very very basic stuff.

>- Inductive definitions.

Very necessary.

>- Parsing.

This is for the compiler writer, but not for the programmer.

>- Types: Unsafe, dynamically typed, and statically typed languages.

Also, type conversion and "type overlay" (unions).

>- Constructed data: data representation independence.

>- Lexical scope and procedures: implementing (call-by-value and
>call-by-name) closures.

Call-by-name and call-by-value are far from enough; call-by-reference is the
only one in Fortran.  There are other ways as well.  

>- Store: assignements, static scope versus dynamic extent, garbage collection.

Also temporary storage in registers.  A real programmer should be aware of the
use of registers, especially when the compiler does not know how to do it.
Also, when extra stores are actually cheaper.

>- Paramter passing techniques: by reference, copy-in-copy-out, by value.

>- Object-oriented languages: objects, classes, inheritance ...

>- Local control: Iteration via tail recursion.

And by many other means.

>- Non-local control: errors, exits, coroutines, goto ...

>- Continuations and continuation-passing style.

>- Macros: hygienic expansion.

One thing missing here is a more versatile macro expansion.  Something
which includes macros, #defines, the use of types and overloading in
macros, etc. 

>- Time pre-emption and light weight processes.

>A person that understands the above concepts can design or implement
>any programming language. Furthermore, they can code an algorithm in
>any existing programming language efficiently. Finally, learning any
>new language amounts essentially to learning a new syntax.

Such a person might be able to design or implement a HLL using "standard"
operations, but not one where "non-standard" operations should be introduced.

Such a person might be able to minimize the size of a program, but not the
time it takes to run; the material presented includes nothing on running
time and costs such as disk reads/writes, context switches, etc.  

Could such a person do a decent job in assemby language?  It is a much 
simpler language, but with a very rigid and unnatural syntax.  I doubt
it, because nothing is included on choice of algorithms at the machine
level, machine dependent optimizations, etc.

In short, what you have presented as what a student gets in the program
is how to program in a language with no consideration of efficiency in
the algorithm.  Now this is relatively easy, but produces poor code.
The infamous 4.2BSD frexp() was a straightforward HLL portable method of
doing the job.  Unfortunately, it frequently took 100 times as long to run
as using machine representation, which is only partially portable.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@pop.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!pop.stat!hrubin(UUCP)
Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math,misc.education