[These notes are taken from the introduction to my Comparative Programming Languages course, CMPT 383 at SFU. They aren't really about web programming, except that they sort of are.]

Read these notes as if you're about to start a comparative programming langauges course. “We will…” really means “if you were taking such a course, we would…”.

What is a “program”?

We will be expressing programs very differently than you're used to.
- Requires rethinking our definition of “program” a little.
Old definition (used in CMPT 120): a description of an algorithm that a computer can understand.
- “algorithm”: an unambiguous sequence of instructions for solving a problem.
- So, a “program” was just a sequence of steps for a computer to follow.
But think about some of the “steps” you specify.
- e.g. total = sum(values)
- Doesn't specify the order of addition (L→R, R→L, numerically-accurate partial sums).
- Some details were undefined and we trusted the language/library/module/framework to take care of the details.
- So many details of the “algorithm” are left out.
Some languages don't express a series of steps at all (as we will see).
- Proposed new definition of “program”: a description of a solution to a problem that allows a computer to solve the problem.
- All (most?) programs you have written so far have satisfied both definitions: they were “imperative” programs.
Imperative programming: the programmer gives an explicit series of steps that must be followed in order; variables represent he current state and are manipulated directly by the programmer.
- e.g. C, C#, Java, Python, Ruby, …
- … but there is more to the world.
Things we will see are not always true:
- “statements” are instructions that are followed in order.
- The programmer indicates what values to store in memory.
- Programs are composed of functions/methods/procedures and classes/objects.

Non-Imperative Programming

In this course, we will explore some non-imperative languages.
These are generally called declarative.
Declarative languages let you describe the results you want, but not the exact sequence of steps required to get there.
- e.g. SQL: describe the records you want, joins to make, etc. The DB server figures out how to get those results.
- e.g. XSLT: describe transformations on an XML document.
- e.g. HTML, CSS, SVG, Makefiles, HTML template languages.
- (not programming languages, but still declarative)
There is not a totally clear line between imperative and declarative languages.
- i.e. can often do declarative-like things in “imperative” languages, and vice-versa.

Functional Programming

One type of declarative programming.
- Still feels like we are giving explicit instructions, but the compiler has more freedom in interpreting details.
Can start by thinking about imperative programming, but…
- No “state” (global variables, etc.).
- No variables at all can be stored.
- No variables means no loops.
So how can we get anything done?
- Emphasis on evaluating expressions, not executing steps.
- Still have function arguments.
  - e.g. half_of x = x/2
  - x isn't quite a variable there.
- Recursion can take the place of loops.
- What we express is “just find the answer” instead of “follow these steps”.
- … that is what gives the compiler more freedom.
- Having no variables means (should mean?) easier debugging: results of a function are determined entirely by its arguments.

Example:

qsort [] = []
qsort (x:xs) = smaller ++ [x] ++ larger
  where smaller = qsort [a | a<-xs, a<=x]
        larger = qsort [a | a<-xs, a>x]