|
1 | | -# Week One: Getting Started |
2 | | - |
3 | | -##Programming Paradigms |
4 | | -Three main programming paradigms: |
5 | | - |
6 | | -* imperative programming |
7 | | -* functional programming |
8 | | -* a lesser known one called logic programming |
9 | | - |
10 | | -Let's review what imperative programming is as a paradigm: |
11 | | - |
12 | | -* modifying mutable variables |
13 | | -* using assignments |
14 | | -* and control structures such as if-then-else, loops, break, continue, and return |
15 | | - |
16 | | -The most common informal way to understand imperative programs is as instruction sequences for a [Von Neumann computer](http://en.wikipedia.org/wiki/Von_Neumann_computer) |
17 | | - |
18 | | - |
19 | | - |
20 | | -Consists of essentially a processor and memory, and a bus that reads both instructions and data from the memory into the processor. |
21 | | - |
22 | | -What's important about this is that the width of that bus is about 1 [machine word](http://en.wikipedia.org/wiki/Word_(computer_architecture)), 32/64 bits. |
23 | | - |
24 | | -It turns out that this model of a computer has shaped programming to no small degree. A strong correspondence between: |
25 | | - |
26 | | -* mutable variables -> memory cells |
27 | | -* variable dereferences -> load instructions |
28 | | -* variable assignments -> store instructions |
29 | | -* control instructions -> jumps |
30 | | - |
31 | | -That's all very well - but the problem is scaling up. We want to avoid thinking about programs just word by word. We want to reason in larger structures... |
32 | | - |
33 | | -##Scaling Up |
34 | | -In the end, the pure imperative programming paradigm is limited by the "Von Neumann" bottleneck: |
35 | | ->*One tends to conceptualize data structures word-by word.* |
36 | | -
|
37 | | -If want to scale up, we have to define higher level abstractions; collections, polynomials, geometric shapes, strings, documents... |
38 | | - |
39 | | -Ideally, to be thorough, we need to develop *theories* of these higher level abstractions so that we are able to reason about them. |
40 | | - |
41 | | -##What is a theory precious |
42 | | -In mathematics, a theory consists of: |
43 | | - |
44 | | -* one or more data types |
45 | | -* operations on these types |
46 | | -* laws that describe the relationships between values and operations |
47 | | - |
48 | | -Here's what's important: *a theory in mathematics does not describe mutations.* IE, changing something while keeping the identity the same. |
49 | | - |
50 | | -##Theories without Mutation |
51 | | -For instance, the theory of polynomials defines the sum of two polynomials by laws such as |
52 | | ->_(a*x + b) + (c*x + d) = (a+c)*x + (b+d)_ |
53 | | -
|
54 | | -IE,. to sum two polynomials of degree 1 we take their two coefficients of the same degree and we sum those coefficients. |
55 | | - |
56 | | -There would be laws of all the other useful operators for polynomials. But what the theory does *not* do is define an operator to change a coefficient while keeping the polynomial the same. Whereas if we look at imperative programming, one can do precisely that... |
57 | | - |
58 | | - class Polynomial { double[] coefficient; } |
59 | | - Polynomial p = ...; |
60 | | - p.coefficient[0] = 42 |
61 | | - |
62 | | -The polynomial p is still the same, but we've changed it's coefficient. This isn't available in mathematics - it would detract from the theory and in fact could damage it by breaking laws |
63 | | - |
64 | | -Another example - strings. Most programming languages have strings, and would define a concatenation operator. One of the laws of concatenation is that it is associative, such that |
65 | | ->_(a ++ b) ++ c = a ++ (b ++ c)_ |
66 | | -
|
67 | | -But it does not define an operator to change a sequence element while keeping the sequence the same |
68 | | - |
69 | | -Some languages do get this right; ie, Java's strings are immutable; Java does not give you an operator to change a character in a string while keeping the string the same |
70 | | - |
71 | | -##Consequences for Programming |
72 | | -If we want to implement high-level concepts following their mathematical theories, there's no place for mutation |
73 | | - |
74 | | -* the theories do not admit it |
75 | | -* mutation can destroy useful laws in the theories |
76 | | - |
77 | | -Therefore, let's: |
78 | | - |
79 | | -* concentrate on defining theories for operators expressed as functions |
80 | | -* avoid mutations |
81 | | -* have powerful ways to abstract and compose functions |
82 | | - |
83 | | -##Functional Programming |
84 | | -In a *restricted* sense, functional programming means programming without mutable variables, assignments, loops, or other imperative control structures... It takes a lot of things away. |
85 | | - |
86 | | -In a *wider* sense, FP means focusing on the functions. In particular, function can be values that are produced, consumed, and composed |
87 | | - |
88 | | -Functional Programming languages can be viewed the same way - in a restricted sense, a functional programming language is one which does not have mutable variables, assignments, or imperative control structures. |
89 | | - |
90 | | -In a wider sense, a FPL enables the construction of elegant programs that focus on functions. In particular, functions are first-class citizens, meaning essentially that we can do with a function what we could do with any other piece of data: |
91 | | - |
92 | | -* they can be defined anywhere, including inside other functions; you can define a string anywhere, you should be able to define a function anywhere |
93 | | -* like any other value, they can be passed as parameters to functions and returned as results |
94 | | -* as for other values, there exists a set of operators to compose functions into richer functions |
95 | | - |
| 1 | +# Week One: Getting Started |
| 2 | + |
| 3 | +##Programming Paradigms |
| 4 | +Three main programming paradigms: |
| 5 | + |
| 6 | +* imperative programming |
| 7 | +* functional programming |
| 8 | +* a lesser known one called logic programming |
| 9 | + |
| 10 | +Let's review what imperative programming is as a paradigm: |
| 11 | + |
| 12 | +* modifying mutable variables |
| 13 | +* using assignments |
| 14 | +* and control structures such as if-then-else, loops, break, continue, and return |
| 15 | + |
| 16 | +The most common informal way to understand imperative programs is as instruction sequences for a [Von Neumann computer](http://en.wikipedia.org/wiki/Von_Neumann_computer) |
| 17 | + |
| 18 | + |
| 19 | + |
| 20 | +Consists of essentially a processor and memory, and a bus that reads both instructions and data from the memory into the processor. |
| 21 | + |
| 22 | +What's important about this is that the width of that bus is about 1 [machine word](http://en.wikipedia.org/wiki/Word_(computer_architecture)), 32/64 bits. |
| 23 | + |
| 24 | +It turns out that this model of a computer has shaped programming to no small degree. A strong correspondence between: |
| 25 | + |
| 26 | +* mutable variables -> memory cells |
| 27 | +* variable dereferences -> load instructions |
| 28 | +* variable assignments -> store instructions |
| 29 | +* control instructions -> jumps |
| 30 | + |
| 31 | +That's all very well - but the problem is scaling up. We want to avoid thinking about programs just word by word. We want to reason in larger structures... |
| 32 | + |
| 33 | +##Scaling Up |
| 34 | +In the end, the pure imperative programming paradigm is limited by the "Von Neumann" bottleneck: |
| 35 | +>*One tends to conceptualize data structures word-by word.* |
| 36 | +
|
| 37 | +If want to scale up, we have to define higher level abstractions; collections, polynomials, geometric shapes, strings, documents... |
| 38 | + |
| 39 | +Ideally, to be thorough, we need to develop *theories* of these higher level abstractions so that we are able to reason about them. |
| 40 | + |
| 41 | +##What is a theory precious |
| 42 | +In mathematics, a theory consists of: |
| 43 | + |
| 44 | +* one or more data types |
| 45 | +* operations on these types |
| 46 | +* laws that describe the relationships between values and operations |
| 47 | + |
| 48 | +Here's what's important: *a theory in mathematics does not describe mutations.* IE, changing something while keeping the identity the same. |
| 49 | + |
| 50 | +##Theories without Mutation |
| 51 | +For instance, the theory of polynomials defines the sum of two polynomials by laws such as |
| 52 | +>_(a*x + b) + (c*x + d) = (a+c)*x + (b+d)_ |
| 53 | +
|
| 54 | +IE,. to sum two polynomials of degree 1 we take their two coefficients of the same degree and we sum those coefficients. |
| 55 | + |
| 56 | +There would be laws of all the other useful operators for polynomials. But what the theory does *not* do is define an operator to change a coefficient while keeping the polynomial the same. Whereas if we look at imperative programming, one can do precisely that... |
| 57 | + |
| 58 | + class Polynomial { double[] coefficient; } |
| 59 | + Polynomial p = ...; |
| 60 | + p.coefficient[0] = 42 |
| 61 | + |
| 62 | +The polynomial p is still the same, but we've changed it's coefficient. This isn't available in mathematics - it would detract from the theory and in fact could damage it by breaking laws |
| 63 | + |
| 64 | +Another example - strings. Most programming languages have strings, and would define a concatenation operator. One of the laws of concatenation is that it is associative, such that |
| 65 | +>_(a ++ b) ++ c = a ++ (b ++ c)_ |
| 66 | +
|
| 67 | +But it does not define an operator to change a sequence element while keeping the sequence the same |
| 68 | + |
| 69 | +Some languages do get this right; ie, Java's strings are immutable; Java does not give you an operator to change a character in a string while keeping the string the same |
| 70 | + |
| 71 | +##Consequences for Programming |
| 72 | +If we want to implement high-level concepts following their mathematical theories, there's no place for mutation |
| 73 | + |
| 74 | +* the theories do not admit it |
| 75 | +* mutation can destroy useful laws in the theories |
| 76 | + |
| 77 | +Therefore, let's: |
| 78 | + |
| 79 | +* concentrate on defining theories for operators expressed as functions |
| 80 | +* avoid mutations |
| 81 | +* have powerful ways to abstract and compose functions |
| 82 | + |
| 83 | +##Functional Programming |
| 84 | +In a *restricted* sense, functional programming means programming without mutable variables, assignments, loops, or other imperative control structures... It takes a lot of things away. |
| 85 | + |
| 86 | +In a *wider* sense, FP means focusing on the functions. In particular, function can be values that are produced, consumed, and composed |
| 87 | + |
| 88 | +Functional Programming languages can be viewed the same way - in a restricted sense, a functional programming language is one which does not have mutable variables, assignments, or imperative control structures. |
| 89 | + |
| 90 | +In a wider sense, a FPL enables the construction of elegant programs that focus on functions. In particular, functions are first-class citizens, meaning essentially that we can do with a function what we could do with any other piece of data: |
| 91 | + |
| 92 | +* they can be defined anywhere, including inside other functions; you can define a string anywhere, you should be able to define a function anywhere |
| 93 | +* like any other value, they can be passed as parameters to functions and returned as results |
| 94 | +* as for other values, there exists a set of operators to compose functions into richer functions |
| 95 | + |
0 commit comments