Barely a draft (and not complet even in scope)
Spectrum: Lisp, Python, Java/C++, C

				Static Type Checking

Comparing Python to Java, C, C++ (and other languages)

Compile Time (translate high-level to low-level) vs Run Time (execute low-level)
  Analysis done at Compile time: Static analysis
  Analysis at Runtime: Dynamic analysis

Strict Type Checking: 
  The type of every object is known; system ensures that we do approporiate
   things (operations) with each object: e.g., if instance of class, call only
   the methods in that class, otherwise an "error"; if instance of function,
   only allow calling function.

Static Type Checking (Java, C (somewht), C++, ML, Haskell):
  All syntax errors are found during compile time; pointed out by compiler
    (in Eclipse text window); errors can still occur: use + when meant *,
    exception for unexpected divide by 0, etc.
  Syntax errors really include all errors findable statically, by the compiler

Dynamic Type Checking (Python, Lisp):
  All language errors are found during runtime; all appear as raised exceptions.

Python does little compile-time checking (so compilation is very fast); Java,
C, C++ do much compile-time checking (so compilation is slower). In these
languages, if we change a class, all other classes that use it must be
recompiled to ensure they are still using it correctly. Python doesn't require
this: but changing a class can cause an error very deep into a computation.

For example, we saw code that looked up names in the inheritance hierarchy in
Python; those names are all checked at compile time in other languages.

Eclipse's PyDev (compared to Idle) tries to make certain errors (bad syntax, use
  of non-existing names) more static: indicated in Eclipse text window. It does
  so by running Python interpreter on code (in the background) and selectively
  displaying error messages. One philosophy is that it is better to find as many
  errors as possible before the code runs (and make guarantees that certain
  errors will never occur at runtime). If code runs before an error is found,
  all the previous execution might obscure the error.

In statically typed languages, we add redundancy that the compiler can use:
  declare the types of variables, parameters, return types
  ensure every method is called on an object of the correct type with the
    correct number and type of parameters.

Compare annotation checking to type checking at compilation time.
  Annotation checking in Python: repeatedly done (at execution cost) but very
     general (can check properties beyond "types")
  Type checking In Java/C++: done just once, wasting no time during execution.

Python can add stuff "on the fly": e.g., add new methods to classes already
  compiled. eval/exec of strings; statically typed languages don't allow this
  kind of flexibility

Some programmers believe
   statically-typed languages are like straightjackets
   statical typing allows focusing on more complicated/important kinds of errors
   (by definition, those not findable statically)

Hungarian Notation (type information postfix in names: for programmer only).
Invented by Charles Simonyi (a hungarian) to help Microsoft C programmers.
In Python we might say

  _s (string), _i (int), _f (float), _b (bool)      example, age_i
  _l (list), _t (tuple), _d (dictionary), _z(set)   edges_dstozofs

Takes getting used to (an understatment), but illustrates type information.