DOCSLIB.ORG

Functional Programming Functional Vs. Imperative Referential

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Functional Programming Functional Vs. Imperative Referential Functional vs. Imperative Referential transparency Imperative programming concerned with “how.” The main (good) property of functional programming is Functional Programming referential transparency. Functional programming concerned with “what.” COMS W4115 Every expression denotes a single value. Based on the mathematics of the lambda calculus Prof. Stephen A. Edwards (Church as opposed to Turing). The value cannot be changed by evaluating an expression Spring 2003 or by sharing it between different parts of the program. “Programming without variables” Columbia University No references to global data; there is no global data. Department of Computer Science It is inherently concise, elegant, and difficult to create subtle bugs in. There are no side-effects, unlike in referentially opaque Original version by Prof. Simon Parsons languages. It’s a cult: once you catch the functional bug, you never escape. The Joy of Pascal Strange behavior Variables program example(output) This prints 5 then 4. At the heart of the “problem” is fact that the global data var flag: boolean; flag affects the value of f. Odd since you expect function f(n:int): int In particular begin f (1) + f (2) = f (2) + f (1) if flag then f := n flag := not flag else f := 2*n; gives the offending behavior flag := not flag Mathematical functions only depend on their inputs end They have no memory Eliminating assignments eliminates such problems. begin In functional languages, variables not names for storage. flag := true; What does this print? Instead, they’re names that refer to particular values. writeln(f(1) + f(2)); writeln(f(2) + f(1)); Think of them as not very variables. end Simple functional programming in A more complex function Currying ML - fun max a b = Functions are first-class objects that can be manipulated A function that squares numbers: = if a > b then a else b; with abandon and treated just like numbers. val max = fn : int -> int -> int % sml - max 10 5; - fun max a b = if a > b then a else b; Standard ML of New Jersey, Version 110.0.7 val it = 10 : int val max = fn : int -> int -> int - fun square x = x * x; - max 5 10; - val max5 = max 5; val square = fn : int -> int val it = 10 : int val max5 = fn : int -> int - square 5; - - max5 4; val it = 25 : int val it = 5 : int Notice the odd type: - - max5 6; int -> int -> int val it = 6 : int This is a function that takes an integer and returns a - function that takes a function and returns an integer. Tuples and arguments Polymorphism Recursion You can also pass and return tuples to/from functions: Reverse has an interesting type: ML doesn’t have variables in the traditional sense, so you can’t write programs with loops. - fun max(a,b) = if a > b then a else b; - fun reverse(a,b) = (b,a); val max = fn : int * int -> int val reverse = fn : ’a * ’b -> ’b * ’a So use recursion: - max (10,5); - fun sum n = This means it can reverse a two-tuple of any type and any val it = 10 : int = if n = 0 then 0 else sum(n-1) + n; other type: - fun reverse(a,b) = (b,a); val sum = fn : int -> int val reverse = fn : ’a * ’b -> ’b * ’a - reverse (10,5.2); - sum 2; - reverse (10,5); val it = (5.2,10) : real * int val it = 3 : int val it = (5,10) : int * int - reverse ("foo", 3.14159); - sum 3; - max (reverse (10,5)); val it = (3.14159,"foo") : real * string val it = 6 : int val it = 10 : int - sum 4; - val it = 10 : int Power operator Using the same thing twice The let expression You can also define functions as infix operators: Without variables, duplication may appear necessary: The easiest way is to introduce a local name for the thing we need multiple times: - fun x ˆ y = fun f x = = if y = 0 then 1 g(square(max(x,4))) + fun f x = = else x * (x ˆ (y-1)); (if x <= 1 then 1 let val ˆ = fn : int * int -> int else g(square(max(x,4)))); val gg = g(square(max(x,4))) - 2 ˆ 2; in One fix: use an extra function: val it = 4 : int gg + (if x <=1 then 1 else gg) - 2 ˆ 3; fun f1(a,b) = b + (if a <= 1 then 1 else b); end; val it = 8 : int fun f x = f1(x, g(square(max(x,4)))); - let is not assignment Data Types Lists - let val a = 5 in Programs aren’t very useful if they only manipulate Tuples have parenthesis, lists have brackets: = (let scalars. - (5,3); = val a = a + 2 Functional languages are particularly good at val it = (5,3) : int * int = in manipulating more complex data types. - [5,3]; = a val it = [5,3] : int list = end, You’ve already seen tuples, which is a fixed-length list of = a) specific types of things. Concatenate lists with @: = end; ML also has lists, arbitrary-length vectors of things of the - [1,2] @ [3,4,5]; val it = (7,5) : int * int same type. val it = [1,2,3,4,5] : int list Cons Other list functions Fun with recursion Add things to the front with :: (pronnounced “cons”) - null [1,2]; - fun addto (l,v) = val it = false : bool - [1,2,3]; = if null l then nil - null nil; val it = [1,2,3] : int list = else hd l + v :: addto(tl l, v); val it = true : bool - 5 :: it; val addto = fn : int list * int -> int list - null []; val it = [5,1,2,3] : int list val it = true : bool - addto([1,2,3],2); Concatenating is not the same as consing: - val a = [1,2,3,4]; val it = [3,4,5] : int list - [1,2] :: [3,4]; val a = [1,2,3,4] : int list stdIn: Error: operator and operand don’t agree [literal]- hd a; operator domain: int list * int list list val it = 1 : int operand: int list * int list - tl a; in expression: val it = [2,3,4] : int list (1 :: 2 :: nil) :: 3 :: 4 :: nil More recursive fun But why always name functions? Recursion with Lambda Expressions - fun map (f, l) = - map( fn x => x + 5, [10,11,12]); = if null l then nil val it = [15,16,17] : int list Q: How do you call something recursively if it doesn’t have = else f (hd l) :: map(f, tl l); a name? This is called a lambda expression: it’s simply an val map = fn : (’a -> ’b) * ’a list -> ’b list unnamed function. A: Give it one. - fun add5 x = x + 5; The fun operator is similar to a lambda expression: - let = val rec f = val add5 = fn : int -> int - val add5 = fn x => x + 5; = fn x => if null x then nil val add5 = fn : int -> int = else hd x + 1 :: f (tl x) - map(add5, [10,11,12]); - add5 10; = in f end val it = [15,16,17] : int list val it = 15 : int = [1,2,3]; val it = [2,3,4] : int list Pattern Matching Pattern Matching Call-by-need Functions are often defined over ranges More fancy binding Most imperative languages, as well as ML, use call-by-value or call-by-reference. All arguments are x if x ≥ 0 fun map (_,[]) = [] f (x) = evaluated before being passed (copied) to the callee. −x otherwise. | map (f,h :: t) = f h :: map(f,t); But some functional languages use call-by-need. Functions in ML are no different. How to cleverly avoid “_” matches anything - fun infinite x = infinite x; writing if-then: h :: t matchs a list, binding h to the head and t to the val infinite = fn : ’a -> ’b fun map (f,[]) = [] tail. - fun zero _ = 0; | map (f,l) = f (hd l) :: map(f,tl l); val zero = fn : ’a -> int Pattern matching is order-sensitive. This gives an error. - zero (infinite 2); fun map (f,l) = f (hd l) :: map(f,tl l) This doesn’t terminate in ML, but it does with call-by-need. | map (f,[]) = []; Call-by-need deterministic in the absence of side effects. Reduce Another Example Call-by-need Another popular functional language construct: Consider fun find1(a,b) = if b then true else (a = 1); fun reduce (f, z, nil) = z - fun find1(a,b) = Call-by-value: | reduce (f, z, h::t) = f(h, reduce(f, z, t)); = if b then true else (a = 1); reduce(find1, false, [1, 3, 5, 7] val find1 = fn : int * bool -> bool find1(1, find1(3, find1(5, find1(7, false)))) f reduce(f,z,a::b::c) If is “−”, is a − (b − (c − z)) find1(1, find1(3, find1(5, false))) - reduce( fn (x,y) => x - y, 0, [1,5]); - reduce(find1, false, [3,3,3]); find1(1, find1(3, false)) find1(1, false) val it = ˜4 : int val it = false : bool true - reduce( fn (x,y) => x - y, 2, [10,2,1]); val it = 7 : int - reduce(find1, false, [5,1,2]); Call-by-need: val it = true : bool reduce(find1, false, [1, 3, 5, 7] find1(1, find1(3, find1(5, find1(7, false)))) true The Lambda Calculus Bound and Unbound Variables Arguments Fancy name for rules about how to represent and evaluate In λx : ∗ 2 x, x is a bound variable. Think of it as a formal λx : λy : ∗ (+ x y) 2 expressions with unnamed functions. parameter to a function. is equivalent to the ML Theoretical underpinning of functional languages. “∗ 2 x” is the body. fn x => fn y => (x + y) * 2; Side-effect free.
Load more

Recommended publications
  • Programming Paradigms & Object-Oriented
    4.3 (Programming Paradigms & Object-Oriented- Computer Science 9608 Programming) with Majid Tahir Syllabus Content: 4.3.1 Programming paradigms Show understanding of what is meant by a programming paradigm Show understanding of the characteristics of a number of programming paradigms (low- level, imperative (procedural), object-oriented, declarative) – low-level programming Demonstrate an ability to write low-level code that uses various address modes: o immediate, direct, indirect, indexed and relative (see Section 1.4.3 and Section 3.6.2) o imperative programming- see details in Section 2.3 (procedural programming) Object-oriented programming (OOP) o demonstrate an ability to solve a problem by designing appropriate classes o demonstrate an ability to write code that demonstrates the use of classes, inheritance, polymorphism and containment (aggregation) declarative programming o demonstrate an ability to solve a problem by writing appropriate facts and rules based on supplied information o demonstrate an ability to write code that can satisfy a goal using facts and rules Programming paradigms 1 4.3 (Programming Paradigms & Object-Oriented- Computer Science 9608 Programming) with Majid Tahir Programming paradigm: A programming paradigm is a set of programming concepts and is a fundamental style of programming. Each paradigm will support a different way of thinking and problem solving. Paradigms are supported by programming language features. Some programming languages support more than one paradigm. There are many different paradigms, not all mutually exclusive. Here are just a few different paradigms. Low-level programming paradigm The features of Low-level programming languages give us the ability to manipulate the contents of memory addresses and registers directly and exploit the architecture of a given processor.
    [Show full text]
  • Functional Languages
    Functional Programming Languages (FPL) 1. Definitions................................................................... 2 2. Applications ................................................................ 2 3. Examples..................................................................... 3 4. FPL Characteristics:.................................................... 3 5. Lambda calculus (LC)................................................. 4 6. Functions in FPLs ....................................................... 7 7. Modern functional languages...................................... 9 8. Scheme overview...................................................... 11 8.1. Get your own Scheme from MIT...................... 11 8.2. General overview.............................................. 11 8.3. Data Typing ...................................................... 12 8.4. Comments ......................................................... 12 8.5. Recursion Instead of Iteration........................... 13 8.6. Evaluation ......................................................... 14 8.7. Storing and using Scheme code ........................ 14 8.8. Variables ........................................................... 15 8.9. Data types.......................................................... 16 8.10. Arithmetic functions ......................................... 17 8.11. Selection functions............................................ 18 8.12. Iteration............................................................. 23 8.13. Defining functions ...........................................
    [Show full text]
  • Exploring Languages with Interpreters and Functional Programming Chapter 8
    Exploring Languages with Interpreters and Functional Programming Chapter 8 H. Conrad Cunningham 24 September 2018 Contents 8 Evaluation Model 2 8.1 Chapter Introduction . .2 8.2 Referential Transparency Revisited . .2 8.3 Substitution Model . .3 8.4 Time and Space Complexity . .6 8.5 Termination . .7 8.6 What Next? . .7 8.7 Exercises . .8 8.8 Acknowledgements . .8 8.9 References . .9 8.10 Terms and Concepts . .9 Copyright (C) 2016, 2017, 2018, H. Conrad Cunningham Professor of Computer and Information Science University of Mississippi 211 Weir Hall P.O. Box 1848 University, MS 38677 (662) 915-5358 Browser Advisory: The HTML version of this textbook requires a browser that supports the display of MathML. A good choice as of September 2018 is a recent version of Firefox from Mozilla. 1 8 Evaluation Model 8.1 Chapter Introduction This chapter introduces an evaluation model applicable to Haskell programs. As in the previous chapters, this chapter focuses on use of first-order functions and primitive data types. A goal of this chapter and the next one is enable students to analyze Haskell functions to determine under what conditions they terminate normally and how efficient they are. This chapter presents the evaluation model and the next chapter informally analyzes simple functions in terms of time and space efficiency and termination. How can we evaluate (i.e. execute) an expression that “calls” a function like the fact1 function from Chapter 4? We do this by rewriting expressions using a substitution model, as we see in this chapter. This process depends upon a property of functional languages called referential transparency.
    [Show full text]
  • 15-150 Lectures 27 and 28: Imperative Programming
    15-150 Lectures 27 and 28: Imperative Programming Lectures by Dan Licata April 24 and 26, 2012 In these lectures, we will show that imperative programming is a special case of functional programming. We will also investigate the relationship between imperative programming and par- allelism, and think about what happens when the two are combined. 1 Mutable Cells Functional programming is all about transforming data into new data. Imperative programming is all about updating and changing data. To get started with imperative programming, ML provides a type 'a ref representing mutable memory cells. This type is equipped with: • A constructor ref : 'a -> 'a ref. Evaluating ref v creates and returns a new memory cell containing the value v. Pattern-matching a cell with the pattern ref p gets the contents. • An operation := : 'a ref * 'a -> unit that updates the contents of a cell. For example: val account = ref 100 val (ref cur) = account val () = account := 400 val (ref cur) = account 1. In the first line, evaluating ref 100 creates a new memory cell containing the value 100, which we will write as a box: 100 and binds the variable account to this cell. 2. The next line pattern-matches account as ref cur, which binds cur to the value currently in the box, in this case 100. 3. The next line updates the box to contain the value 400. 4. The final line reads the current value in the box, in this case 400. 1 It's important to note that, with mutation, the same program can have different results if it is evaluated multiple times.
    [Show full text]
  • Week 3: Scope and Evaluation Order Assignment 1 Has Been Posted!
    Week 3: Scope and Evaluation Order CSC324 Principles of Programming Languages David Liu, Department of Computer Science Assignment 1 has been posted! Closures and static scope static (adjective) determined only by the program source code dynamic (adjective) determined only when the program is run E.g., referential transparency is a static property How are closures implemented? Are they static or dynamic? Or both? Function bodies can be processed statically (e.g., Haskell compiler generates code once per lambda). The closure environment (and therefore the closure itself) can only be generated dynamically. The closure depends only on where the function is evaluated, not where that function is called. (define (make-adder n) (lambda (x) (+ x n))) (define adder (make-adder 1)) (adder 100) So we can determine where each free identifier obtains its values statically, based on where its enclosing function is defined. scope (of an identifier) The parts of program code that may refer to that identifier. static (aka lexical) scope The scope of every identifier is determined by the structure of the source code (e.g., by nesting of lambdas and lets). Every identifier obtains its value from the closest enclosing expression that binds it. (define (make-adder n) (lambda (x) (+ x n))) (define adder (make-adder 1)) ; (0x..., {n: 1}) (let* ([n 100]) (adder 2)) Implementing static scope in an interpreter A simple interpreter (define/match (interpret env expr) [(_ (? number?)) expr] [(_ (? symbol?)) (hash-ref env expr)] [(_ (list '+ l r)) (+ (interpret env l) (interpret env r))]) A simple interpreter (define/match (interpret env expr) [(_ (? number?)) expr] [(_ (? symbol?)) (hash-ref env expr)] [(_ (list '+ l r)) (+ (interpret env l) (interpret env r))]) The environment is passed recursively when interpreting each subexpression.
    [Show full text]
  • Functional and Imperative Object-Oriented Programming in Theory and Practice
    Uppsala universitet Inst. för informatik och media Functional and Imperative Object-Oriented Programming in Theory and Practice A Study of Online Discussions in the Programming Community Per Jernlund & Martin Stenberg Kurs: Examensarbete Nivå: C Termin: VT-19 Datum: 14-06-2019 Abstract Functional programming (FP) has progressively become more prevalent and techniques from the FP paradigm has been implemented in many different Imperative object-oriented programming (OOP) languages. However, there is no indication that OOP is going out of style. Nevertheless the increased popularity in FP has sparked new discussions across the Internet between the FP and OOP communities regarding a multitude of related aspects. These discussions could provide insights into the questions and challenges faced by programmers today. This thesis investigates these online discussions in a small and contemporary scale in order to identify the most discussed aspect of FP and OOP. Once identified the statements and claims made by various discussion participants were selected and compared to literature relating to the aspects and the theory behind the paradigms in order to determine whether there was any discrepancies between practitioners and theory. It was done in order to investigate whether the practitioners had different ideas in the form of best practices that could influence theories. The most discussed aspect within FP and OOP was immutability and state relating primarily to the aspects of concurrency and performance. ​ ​ ​ ​ ​ ​ This thesis presents a selection of representative quotes that illustrate the different points of view held by groups in the community and then addresses those claims by investigating what is said in literature.
    [Show full text]
  • Unit 2 — Imperative and Object-Oriented Paradigm
    Programming Paradigms Unit 2 — Imperative and Object-oriented Paradigm J. Gamper Free University of Bozen-Bolzano Faculty of Computer Science IDSE PP 2018/19 Unit 2 – Imperative and Object-oriented Paradigm 1/38 Outline 1 Imperative Programming Paradigm 2 Abstract Data Types 3 Object-oriented Approach PP 2018/19 Unit 2 – Imperative and Object-oriented Paradigm 2/38 Imperative Programming Paradigm Outline 1 Imperative Programming Paradigm 2 Abstract Data Types 3 Object-oriented Approach PP 2018/19 Unit 2 – Imperative and Object-oriented Paradigm 3/38 Imperative Programming Paradigm Imperative Paradigm/1 The imperative paradigm is the oldest and most popular paradigm Based on the von Neumann architecture of computers Imperative programs define sequences of commands/statements for the computer that change a program state (i.e., set of variables) Commands are stored in memory and executed in the order found Commands retrieve data, perform a computation, and assign the result to a memory location Data ←→ Memory CPU (Data and Address Program) ←→ The hardware implementation of almost all Machine code computers is imperative 8B542408 83FA0077 06B80000 Machine code, which is native to the C9010000 008D0419 83FA0376 computer, and written in the imperative style B84AEBF1 5BC3 PP 2018/19 Unit 2 – Imperative and Object-oriented Paradigm 4/38 Imperative Programming Paradigm Imperative Paradigm/2 Central elements of imperative paradigm: Assigment statement: assigns values to memory locations and changes the current state of a program Variables refer
    [Show full text]
  • S-Algol Reference Manual Ron Morrison
    S-algol Reference Manual Ron Morrison University of St. Andrews, North Haugh, Fife, Scotland. KY16 9SS CS/79/1 1 Contents Chapter 1. Preface 2. Syntax Specification 3. Types and Type Rules 3.1 Universe of Discourse 3.2 Type Rules 4. Literals 4.1 Integer Literals 4.2 Real Literals 4.3 Boolean Literals 4.4 String Literals 4.5 Pixel Literals 4.6 File Literal 4.7 pntr Literal 5. Primitive Expressions and Operators 5.1 Boolean Expressions 5.2 Comparison Operators 5.3 Arithmetic Expressions 5.4 Arithmetic Precedence Rules 5.5 String Expressions 5.6 Picture Expressions 5.7 Pixel Expressions 5.8 Precedence Table 5.9 Other Expressions 6. Declarations 6.1 Identifiers 6.2 Variables, Constants and Declaration of Data Objects 6.3 Sequences 6.4 Brackets 6.5 Scope Rules 7. Clauses 7.1 Assignment Clause 7.2 if Clause 7.3 case Clause 7.4 repeat ... while ... do ... Clause 7.5 for Clause 7.6 abort Clause 8. Procedures 8.1 Declarations and Calls 8.2 Forward Declarations 2 9. Aggregates 9.1 Vectors 9.1.1 Creation of Vectors 9.1.2 upb and lwb 9.1.3 Indexing 9.1.4 Equality and Equivalence 9.2 Structures 9.2.1 Creation of Structures 9.2.2 Equality and Equivalence 9.2.3 Indexing 9.3 Images 9.3.1 Creation of Images 9.3.2 Indexing 9.3.3 Depth Selection 9.3.4 Equality and Equivalence 10. Input and Output 10.1 Input 10.2 Output 10.3 i.w, s.w and r.w 10.4 End of File 11.
    [Show full text]
  • SI 413, Unit 3: Advanced Scheme
    SI 413, Unit 3: Advanced Scheme Daniel S. Roche ([email protected]) Fall 2018 1 Pure Functional Programming Readings for this section: PLP, Sections 10.7 and 10.8 Remember there are two important characteristics of a “pure” functional programming language: • Referential Transparency. This fancy term just means that, for any expression in our program, the result of evaluating it will always be the same. In fact, any referentially transparent expression could be replaced with its value (that is, the result of evaluating it) without changing the program whatsoever. Notice that imperative programming is about as far away from this as possible. For example, consider the C++ for loop: for ( int i = 0; i < 10;++i) { /∗ some s t u f f ∗/ } What can we say about the “stuff” in the body of the loop? Well, it had better not be referentially transparent. If it is, then there’s no point in running over it 10 times! • Functions are First Class. Another way of saying this is that functions are data, just like any number or list. Functions are values, in fact! The specific privileges that a function earns by virtue of being first class include: 1) Functions can be given names. This is not a big deal; we can name functions in pretty much every programming language. In Scheme this just means we can do (define (f x) (∗ x 3 ) ) 2) Functions can be arguments to other functions. This is what you started to get into at the end of Lab 2. For starters, there’s the basic predicate procedure?: (procedure? +) ; #t (procedure? 10) ; #f (procedure? procedure?) ; #t 1 And then there are “higher-order functions” like map and apply: (apply max (list 5 3 10 4)) ; 10 (map sqrt (list 16 9 64)) ; '(4 3 8) What makes the functions “higher-order” is that one of their arguments is itself another function.
    [Show full text]
  • Comparative Studies of Programming Languages; Course Lecture Notes
    Comparative Studies of Programming Languages, COMP6411 Lecture Notes, Revision 1.9 Joey Paquet Serguei A. Mokhov (Eds.) August 5, 2010 arXiv:1007.2123v6 [cs.PL] 4 Aug 2010 2 Preface Lecture notes for the Comparative Studies of Programming Languages course, COMP6411, taught at the Department of Computer Science and Software Engineering, Faculty of Engineering and Computer Science, Concordia University, Montreal, QC, Canada. These notes include a compiled book of primarily related articles from the Wikipedia, the Free Encyclopedia [24], as well as Comparative Programming Languages book [7] and other resources, including our own. The original notes were compiled by Dr. Paquet [14] 3 4 Contents 1 Brief History and Genealogy of Programming Languages 7 1.1 Introduction . 7 1.1.1 Subreferences . 7 1.2 History . 7 1.2.1 Pre-computer era . 7 1.2.2 Subreferences . 8 1.2.3 Early computer era . 8 1.2.4 Subreferences . 8 1.2.5 Modern/Structured programming languages . 9 1.3 References . 19 2 Programming Paradigms 21 2.1 Introduction . 21 2.2 History . 21 2.2.1 Low-level: binary, assembly . 21 2.2.2 Procedural programming . 22 2.2.3 Object-oriented programming . 23 2.2.4 Declarative programming . 27 3 Program Evaluation 33 3.1 Program analysis and translation phases . 33 3.1.1 Front end . 33 3.1.2 Back end . 34 3.2 Compilation vs. interpretation . 34 3.2.1 Compilation . 34 3.2.2 Interpretation . 36 3.2.3 Subreferences . 37 3.3 Type System . 38 3.3.1 Type checking . 38 3.4 Memory management .
    [Show full text]
  • Perhaps There Is a Much Better Way Goals
    DjangoCon 2014 Tony Morris Perhaps There Is A much Better Way Goals Our existing common goals The goals for today Goals Our common goals to implement software efficiently to arrive at an initial result as quickly as possible over time, to reliably arrive at results as quickly as possible (aka maintenance) a result is valid if the program accurately achieves our objective Goals Our common goals impertinent goals financial gain "but django makes me $$$!" motivate personal avidities Goals Our goals for today "Why Django Sucks" Goals Our goals for today I could talk all day about why django sucks and I’d be saying lots and lots of true things but not necessarily helpful things Goals Our goals for today I could talk all day about why django sucks and I’d be saying lots and lots of true things but not necessarily helpful things Goals Our goals for today The goal today To equip you with new tools and perspective, with which to explore the question for yourself. Goals Lies Along the way We will visit some of the lies you have been told Goals Lies Tacitly insidious ones "Having to come to grips with Monads just isn’t worth it for most people" Goals Lies Confusingly insidious ones "Imperative vs functional programming vs object-oriented programming" Goals Lies Awkward ones "The real world is mutable" Goals Lies Funny ones "Django: The Web framework for perfectionists with deadlines" Goals Summary What is functional programming? What does monad mean? Functional imperative programming Parametricity —types are documentation What is Functional Programming?
    [Show full text]
  • Peach Documentation Release
    peach Documentation Release Alyssa Kwan Nov 11, 2017 Contents 1 Table of Contents 3 1.1 Solutions to Common Problems.....................................3 2 Indices and tables 5 i ii peach Documentation, Release Welcome to peach. peach is a functional ETL framework. peach empowers you to easily perform ETL in a way inherent to the functional programming paradigm. Why peach? Please see the Solutions to Common Problems section of the documentation. peach is the culmination of learnings from over a decade of mistakes made by the principal author. As such, it represents best practices to deal with a wide array of ETL and data lake / data warehouse problems. It also represents a sound theoretical framework for approaching this family of problems, namely “how to deal with side effects amidst concurrency and failure in a tractable way”. Contents 1 peach Documentation, Release 2 Contents CHAPTER 1 Table of Contents 1.1 Solutions to Common Problems 1.1.1 Clean Retry on ETL Job Failure Problem Jobs are side-effecting; that is their point: input data is ingested, and changes are made to the data lake or warehouse state in response. If a job fails partway through execution, it leaves all sort of garbage. This garbage gets in the way of retries, or worse yet, any other tries at all. If all of the job artifacts - both intermediate and final - are hosted upon a transactional data store, and jobs are only using features that are included in transactions (for instance, some RDBMS’s don’t include schema changes in transaction scope, so you can’t create tables and have them automatically cleaned up), then congratulations! There is no problem.
    [Show full text]