CSC302 2007S, Class 02: An Abbreviated History of Programming Languages

Admin:
* Upcoming talks: 
  * Prof. Meehan on Vocation, Thursday at 11:00 a.m.  
  * Dr. Stone on Life, Thursday at 4:15 p.m.
* About the first readings:
  * A few of you missed the 8 p.m. deadline.  
    Please don't miss it again.
  * I have done my best to respond to your questions.  Feel free to
    ask more in class.
  * A few of you received - grades for too-casual reflections.  The 
    problem was particularly severe with the Byte article.  In that
	case, I've segmented the reflections so that you can see what
	I hoped to see.
* There were enough questions about the art of programming that 
  I've added a short reading for Friday - The Story of Mel, a Real Programmer.
* We'll spend a few minutes on administrative questions.
* I plan to read over your HW1s tomorrow.

Overview:
* Some questions from the readings.
* Exercise: Dating key ideas.
* An abbreviated history of programming languages.

-----

/What is a programming language?/
* And how can you program without one?
  * LZB: In these articles, programming languages 
    = "higher-level language"
* Why the distinction?
  * EO: Low-level languages are architecture-specific
  * SS: Perhaps not so much creativity in the design of low-level
    languages; the interesting variations come from high-level
	languages
	* SR responds
  * EO'N: Higher-level languages may better reflect how we
    think about problems
  * There are many other kinds of instructions for computation
    * How mathematicians describe computation
	* Lambda calculus, Turing machines, etc.
	* Instructinos for "human computers", including parallel
	  human computers
* Historical detour
  * The first computers lacked assembly languages
  * Some: Program is a patch diagram
    * Detour within a detour - Early algorithms: Data and program are separate - The idea that a program itself is just data is due to John von Neumann @ Princeton
    * Detour detour detour - Why would you bother doing such things?  
	  Repetitive calculations with different inputs, e.g., solving
	  diff eqns.
  * In others, you wrote directly in machine code
  * Assembly: As long as you're talking about the instructions
    mnemonically ("add"), why not write them that way?
	* You can then automatically translate them to machine code
	* Can be a huge code explosion
	* But makes the programmer more efficient and makes programs
	  easier to debug
* Sammet gives us four criteria for a high-level language
  * "Machine code is unnecessary" - KG - You can program using this
    more readable stuff
  * "There is good potential for conversion to other computers"
    - DK - you can write compilers for different architectures
  * "There is an instruction explosion"
  * "The notation is closer to the original problem than assembly
    language would be" - EB - Often closer to English and how we think.
* Differences between 1 and 4
  * JT: Levels of distances from machine code
  * LZB: 1 refers to what programmers do and do not need to know,
    while 4 talks about how we actually represent solutions

Let's think about how to represent a problem (or solution) in a
high-level language:

Inner product.  Given two one-d vectors of length N, compute
their inner product.  represent the vectors however you choose

* One strategy: A and B are arrays, use a for loop to step
  through the arrays
  * C, Java
* A functional strategy
  (apply + (map * A B))
* Another possibility: Tail recursion