Announcements #
- Checking status
- Office hours: Wed 3
Plan for Today #
- Review of Core Concepts
- A Design/Programming Activity
- A language for Types
- Data-oriented Functional Programming: A Preview
- One approach: A Tour
Core Concepts of Functional Programming #
Composability is a fundamental aspiration in software design. We want the parts of our system to interoperate and combine as freely as possible. This offers power, expressiveness, reusability, and many other benefits.
In functional programming (FP), functions are the fundamental unit of abstraction providing simple, easily composed building blocks for solving problems.
Central features of FP:
- Functions are first-class entities
- Functions are pure (whenever possible)
- Data is immutable (whenever possible)
- Programs have declarative structure (as much as possible)
- Exploit laziness when appropriate
- Referential transparency
- Higher-Order Functions
Why use functional programming?
- Functions are simple, easily composed abstractions
- Easy to express many ideas with very little code
- Easier to reason about – and test – a functional program
- Avoids the significant complexity of mutating state
- Effective Concurrency/Parallelism by avoiding mutable state
- Focuses on data flow
- Efficiently exploits recursive thinking
- Fast development cycle
- Encourages code reuse
A Language for Types #
It helps to have a language for describing the shape of data. In some languages the shape is specified at compile time as types (via a type system), and in others described at compile and/or run time via schemas (e.g., via JSON Schema, Malli, etc.).
We will borrow the language of types to get a kind of pseudocode for describing the shape of data.
data Shape = Circle Float Float Float | Rectangle Float Float Float Float
data UnaryIntFn = Int -> Int
data BinaryIntFn = Int -> Int -> Int
data Expr a
= Literal { intVal :: Int }
| Ident { name :: String }
| Index { target :: a, idx :: a }
| Unary { op :: String, target :: a }
| Binary { lhs :: a, op :: String, rhs :: a }
| Call { func :: a, args :: [a] }
| Paren { subexpr :: a }
data List a = Nil | Cons a (List a)
data BTree a = Leaf a | Branch (BTree a) (BTree a)
Data-Oriented Functional Programming: A Preview #
An approach to design that makes the data entities in a system a central concern. This is an opinionated flavor of functional programming that suggests practices to reduce complexity, maximize reuse, and improve correctness.
Let’s start with a few core principles that we will dive into in the next few activities.
Principle #1: Separate Data and Code #
Design operations to operate on data that is separately described and stored. Keep state out of your functions.
Principle #2: Use Immutable Data When Possible #
Reduces complexity at very small performance penalty for general use. Transient mutability is fine in tight bottlenecks.
Principle #3: Represent Data with Generic Data Structures #
It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures.
– Alan Perlis
Principle #4: Describe Complex Data Models #
Type systems and schema can provide rich descriptions of our data models, offer validation, test generation, auto documentation, and many other benefits.
FP Activity I (Homework init ) #
Today, we’ll consider a problem that we will tackle; this
will be a homework exercise dominoes available to do.
In class, we will start with an interactive design process and
some pair-programming prototyping.
Here is a motivating version of the problem (from https://adventofcode.com/2017/day/24).
The CPU itself is a large, black building surrounded by a bottomless pit. Enormous metal tubes extend outward from the side of the building at regular intervals and descend down into the void. There’s no way to cross, but you need to get inside.
No way, of course, other than building a bridge out of the magnetic components strewn about nearby.
Each component has two ports, one on each end. The ports come in all different types, and only matching types can be connected. You take an inventory of the components by their port types (your puzzle input). Each port is identified by the number of pins it uses; more pins mean a stronger connection for your bridge. A 3/7 component, for example, has a type-3 port on one side, and a type-7 port on the other.
Your side of the pit is metallic; a perfect surface to connect a magnetic, zero-pin port. Because of this, the first port you use must be of type 0. It doesn’t matter what type of port you end with; your goal is just to make the bridge as strong as possible.
The strength of a bridge is the sum of the port types in each component. For example, if your bridge is made of components 0/3, 3/7, and 7/4, your bridge has a strength of 0+3 + 3+7 + 7+4 = 24.
For example, suppose you had the following components:
0/2
2/2
2/3
3/4
3/5
0/1
10/1
9/10
With them, you could make the following valid bridges:
0/1
0/1--10/1
0/1--10/1--9/10
0/2
0/2--2/3
0/2--2/3--3/4
0/2--2/3--3/5
0/2--2/2
0/2--2/2--2/3
0/2--2/2--2/3--3/4
0/2--2/2--2/3--3/5
(Note how, as shown by 10/1, order of ports within a component doesn’t matter. However, you may only use each port on a component once.)
Of these bridges, the strongest one is 0/1–10/1–9/10; it has a strength of 0+1 + 1+10 + 10+9 = 31.
What is the strength of the strongest bridge you can make with the components you have available?