CSC302 2006S, Class 4: On the Design of Programming Languages

Admin:
* Please do not use attachments
* Please submit homework via email on time: 
  * By midnight the day before class
  * No text messages
  * No 133+
  * Correct spelling and grammar, if at all possible
* New readings (do in order)
  * Graham: Revenge of the Nerds (paper) [Wednesday]
  * McCarthy: History of LISP (electronic) [Wednesday]
  * McCarthy: Recursive Functions of Symbolic Expressions and
    Their Computation by Machine, Part I (paper) [Friday]
  * Graham: The Roots of Lisp (paper) [Friday]

Overview:
* Notes on the readings
* Choosing a language
* Other language design issues

/Notes on the Readings/

* What languages have we (as a class) used?
  * C
  * Java
  * Scheme
  * Pascal
  * PHP
  * Perl
  * SQL (MySQL, PostgreSQL)
  * C++
  * C#
  * *Basic*
* What programming language would Wirth and Hoare like, and would 
  they like the same language?
  * Scheme seems relatively simple
  * Java 
    * Has good commenting style (so do C, C++)
    * Or maybe not, still problem of mismatched /* ... */
    * Modular (ooh, bad!)
    * Strong typing - Helps the programmer (Wirth and Hoare)
      * Hoare would not like the coercions in Java
    * Hoare wants compactness, Java is not compact
* Claim: Hoare likes lower-level languages
  * One possible contradiction: switch vs. case
    * Neither switch nor case has a real test (although they might arguably simulate tests), both simulate
      if (i = 1) then Q1
      else if (i = 2) then Q2
      else if (i = 3) then Q3
    * Switch is simply a clever goto, using an array of labels
      * Much more efficient than sequential tests
    * Case is higher-level - You choose between the Q's, but
      you don't 'know' the underlying implementation
    * Hoare does not like switch statements because you can
      jump easily into and out of the switch
      * Such jumping makes analysis much harder
      * Context: Assertion=based analysis, pre-post
         preconditions | code | postconditions
  * Another: "Among the more trivial by tiresome errors of low-level programming errors are type errors"

Hoare's description of the legendary NASA Fortran Bug

Loop in Fortran

        DO LABEL VARIABLE = START , END
        ....
        LABEL

        DO foo x = 1, 10
          TURN x
        foo

Fortran I ignored spaces, including within variable names and values

        DO foo x = 1  10
          TURN x
        foo

Fortran now has a more logical syntax

---

What are the key criteria by which we decide whether a language
is good?  Different levels of criteria

* Readability - Can you understand code written by someone else?
* Writability - Can you easily write code that matches your
  notion of how to solve the problem?
* Robustness - How likely is your written code to work correctly?
* Cost - Efficiency, Maintainablity, ...

Acheive through big language design techniques
* Simplicity - Not too many structures in the language
* Uniformity - Things look and behave similarly
* Orthogonality - Support cross-products of features
* Good control structures
* Good data structure and ADT techniques
* Type system

Small details that affect and effect many of the above
* Aliasing: Two variables can reference the same memory location
  * Problematic for analysis: A change to one variable can change the other.