3/29 lecture sketch

! includes review/overview of highlights and some motivation for java

agenda/topics
+ date of prelim T3 review session:
  + fri apr 13
  + sat apr 14 <-- 3pm was chosen
  + sun apr 15
+ bonus material: show how to run $sparse$ example, make changes, etc.
+ codewarrior diff: p5.2 skeleton code
+ P5.2 write-up, hints (see outline/write-up)
+ P5 Q & A
! Matlab wrap-up (below)

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

universal programming concepts that we've seen

programming techniques and patterns
+ redundancy --> opportunity for improvement/automated solution
+ introspection = translate the way *you* do it into code
+ accumulation
+ template for processing input sequence with a stopping value
+ loop invariant, loop techniques
  + processed/unprocessed
  + answer so far
  + previous value
+ testing by hand
+ automated testing
+ boundary conditions, degenerate cases
+ debugging
  + diagnostic output
  + mental tracing
  + tracing by hand on paper
  + tracing on computer with debugger, etc.
  + comment out portions of code
  + run on smaller/simpler examples
  + compare against known answers
+ separation of concerns
+ incremental development
+ decompose a larger problem into smaller problems
+ abstraction = chunk/hide lower-level details into/under 
                a single higher-level concept
  examples:
  + vectorization: think at vector level, not element-by-element level
  + performance analysis: throw away "details", concentrate on rate of growth
  + polynomials: think of a polynomial as a single mathematical entity,
	not a bunch of coefficients and exponents
  + functions: replace function body with just the name of the function
  + statement comment: higher-level explanation, 
    ignoring irrelevant lower-level implementation details
+ style = formatting conventions to make programs readable
  + self-documenting identifiers
  + white space
  + indentation: indent substructures
  + comments
    + variable definition
    + statement comment
    + function specification in terms of parameters, return values/variables
    + loop invariant
  ($-notation is a Yan invention)

code
+ identifier = a name, e.g. of a variable or function
+ scope = set of places an identifier is visible
  + top-level scope
  + activation record
  + structure (aka record, roughly aka object)
    + fields (aka members)

+ variable = a kind of location: a "box" that can hold a "value"
  + declare = create
  + initialize = assign first value
  + assign = destructively update value, aka write value
  + l-value = location of box, on *l*efthand side of assignment
  + r-value = value in contents of box, on *r*ighthand side of assignment

+ datatype = the "kind" or "flavor" of a variable or value
  + integer
  + floating point
  + character
  + string
  + boolean/logical
  + array (1-D, 2-D)
  + structure (aka record, roughly aka object)
+ value = data that can be stored in a variable

+ expression = (part of) a program that evaluates to a value; 
               often has no "side-effects"
  + literal = a constant typed into a program, like $3$, but not like $1+2$
  + operator = built-in operation, often name is made of symbols, e.g. $==$
  + function = built-in or user-defined operation;
               often name is made of letters, e.g. $find$
  + cast/convert/coerce = change from one datatype to another
  + standard math, etc: min, max, abs, rand, ceil, floor, round, ...

+ logic
  + true, false
  + and, or, not, any, all
  + demorgan's laws
  + often need not/opposite of a condition for $while$ loops

+ statement = (part of) a program that is executed for its "side-effect";
              often does not evaluate to a value
+ assignment statement = destructive update of a variable's value
+ print = display information
+ sequencing = "straight line code"
+ conditional = selection/branching/decision-making
+ loop = repetition
  + definite iteration, e.g. $for$
  + indefinite iteration, e.g. $while$
  + loop variable
  + loop range/test/guard/condition  
  + loop body
  + "loop while not done" -- need opposite of "done"

+ function = named, parametrized piece of code
  + function header = line of code that says a function is being defined;
                      contains function name, parameters, etc.
  + parameter = input variable
  + function body = code to run
  + activation record = fresh new scope in which to run function body
  + return values = computed answers/results
_______________________________________________________________________________

what's missing?

+ we've seen many universal concepts, techniques, patterns, program elements
+ if what we've seen is so great, why isn't the course over?

namespace control
+ grr!  one function per file
+ grr!  tons (thousands?  tens of thousands?) of identifiers at top-level scope
  + grr!  hard to remember
  + grr!  easy to accidentally shadow or otherwise conflict

matlab can be *too* "helpful"
+ grr!  accidentally assign past end of the array
+ grr!  accidentally use non-logical number as loop guard
+ grr!  accidentally assign array of length one to array of length two
+ grr!  accidentally take square root of a character
+ grr!  accidentally pass struct into our polynomial addition function

in the matlab we've seen so far, abstraction can be broken
+ that is, details that should be hidden "leak through" or are exposed
+ to see this, consider our polynomial package
+ client code can rely on things subject to change
  + client uses our code and reads coefficients directly from vector
  + later, we discover a better implementation and re-implement
  + client loses!  their code no longer works!
+ client code can accidentally corrupt data
  + when we re-implement, we provide functions to read and modify coefficients
  + client can still accidentally overwrite our data -- no way to force/remind
    client to use our functions

matlab can be inefficient: updates can be inefficient
+ $x = [x 1]$ can take unbounded time and space (more than $O(1)$)

java provides immediate solutions to all these problems