CSC302 2011S, Class 27: The Evolution of Some Key Language Features

Overview:
* The Story of Mel, a Real Programmer.
* Reading Ryder et al.
* Major Characteristics.
* More History.

Admin:
* Missing (excused): AT
* Are there questions on the mid-semester exam? 
  It is now due Monday evening. Shove the paper copy under my door.
  Your hash tables should copy the strings.
* Reading 1 for Monday: Dijkstra's "Go To Statement Considered Harmful".
* Reading 2 for Monday: Bratley, P. (1967). Algorithm 306: Permutation with Repetitions [G6]. Communications of the ACM 10(7), July 1967, pp. 450-451.
* Both are in the ACM DL.
* EC for CS table today [academic].
* EC for Sita Sings the Blues tonight [academic].

Mel, A Real Programmer
* What was the computing context?
  * "After vacuum tubes" - Computers are spreading, we see "mid-size"
    computers in individual businesses
  * Programming context (what did languages look like):
* What were the main points?
  * Maybe: "We should be thankful that we don't have to program like that"
  * Maybe: "We don't program as much to the hardware, so we know much
    less about the hardware."
* Why do you think I had you read this?
  * Remind us how far programming has come; Give us a baseline for
    comparison
  * Readable code is important / Clarity vs. Efficiency vs. Cleverness
    * There's a value in companies establishing standards and enforcing
      them.
  * While you gain a lot with high-level languages, you lose something,
    too.
* Other thoughts
  * Lots of approaches to the same problem
  * Programmers are selfish: They write programs using clever techniques
    rather than tools that incorporate their clever techniques
  * Your ethics should trump the company's

Detour: Evolution of value of clarity and concision
* First compilers (Fortran)
  * Computers: Big and expensive
  * Programmers: CHEAP (grad students and women)
  * Design goal of Fortran: No worse than half as efficient as hand-tuned
    assembly code

* Today
  * Computers: Small and cheap
  * Programmers: Expensive (sometimes rediculuousdsly so)
  * Goal in language design: Make best use of programmer time
  * Architectures are complex enough that a good compiler beats a
    good programmer 90+% of the time

Approaching Ryder et al.

* Who is the audience?
  * People with an interest in programming languages and software engineering
    * That is, professionals (including academics) in the computing disciplines
  * Part of scholarly archive on practice
    * That is, professionals (including academics) in the computing disciplines (or maybe history of science)
  * FUNDERS!
* What is the thesis? [Your paraphrase; The actual text]
  * There is a symbiotic relationsihp between software engineering design
    and programming language practice.
  * Good ideas about software design get incorporated into languages
  * Software engineering discipline identifies problems
    * Languages provide solutions
    * Software engineering provides solutions that get incorporated
      into languages
* What argumentative structure and evidence are used to support the
  thesis?
  * Lots of examples: Modularity, Data abstraction, Error handling,
    Visual languages
  * Interviews!
* Do I accept the argument?
  * No.  They chose a stupid set of languages.
* Why should I care?
  * I didn't

What are some interesting points you saw or things you liked in the article?
* There are a lot of different language features that seem to support
  better programming.
* Issues of multiple- vs. single inheritance
  * Ooh!  A good topic for one of the public presentations
  * It's worth looking at some of the philosophical papers on why
    choices were made
* Lots of important ideas are old: We see a lot of stuff from the 1960's
  and not so much after the 1980's.
* We get it wrong a lot
  * Modularity good!
  * But another two decades before "separate interface and implementation"
*