DOCSLIB.ORG

Functional Programming

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Functional Programming Programming Paradigms During the next few weeks we are going to work with CSc 520 functional programming. Before I can explain to you what FP is, I thought I’d better put things into Principles of Programming perspective by talking about other Languages programming paradigms. Over the last 40 or so years, a number of programming 2: Functional Programming paradigms (a programming paradigm is a way to think Christian Collberg about programs and programming) have emerged. [email protected] Department of Computer Science University of Arizona Copyright c 2004 Christian Collberg 520—Spring 2005—2 [1] 520—Spring 2005—2 [2] Programming Paradigms. Programming Paradigms. A programming paradigm Imperative Programming is a way to think about programs, programming, and Programming with state. problem solving, Also known as procedural programming. The first to is supported by one or more programming languages. emerge in the 1940s-50s. Still the way most people learn how to program. Being familiar with several paradigms makes you a better programmer and problem solver. The most popular FORTRAN, Pascal, C, BASIC. paradigms: Functional Programming 1. Imperative programming. 2. Functional programming. Programming with values. 3. Object-oriented programming. Arrived in the late 50s with the LISP language. LISP is 4. Logic Programming. still popular and widely used by AI people. When all you have is a hammer, everything looks like a nail. LISP, Miranda, Haskell, Gofer. 520—Spring 2005—2 [3] 520—Spring 2005—2 [4] Programming Paradigms. Procedural Programming Object-Oriented Programming We program an abstraction of the Von Neumann Machine, Programming with objects that encapsulate data and consisting of a store (memory), a program (kept in the operations. store), A CPU and a program counter (PC): A variant of imperative programming first introduced Computing x:=x+1 1. Compute x’s ad- with the Norwegian language Simula in the mid 60s. CPU dress, send it to the Simula, Eiffel, Modula-3, C++. Addresses Data store, get x’s value back. Logic Programming X: 53 Jump 2. Add 1 to x’s value. Program: PC := PC + 8; PC Programming with relations. 3. Send x’s address Update Introduced in the early 70s. Based on predicate X := X + 1 store and new value to the calculus. Prolog is popular with Computational Store store for storage. Linguists. 4. Increment PC. Prolog, Parlog. 520—Spring 2005—2 [5] 520—Spring 2005—2 [6] Procedural Programming. Procedural Programming. The programmer... Procedural programming is difficult because: uses control structures (IF, WHILE, ...) to alter the 1. A procedural program can be in a large number of program counter (PC), states. (Any combination of variable values and PC uses assignment statements to alter the store. locations constitutes a possible state.) The programmer has to keep track of all of them. is in charge of memory management, i.e. declaring 2. Any global variable can be changed from any location in variables to hold values during the computation. the program. (This is particularly true of languages like § ¤ C & C++ [Why?]). function f a c t ( n : integer ) : integer ; 3. It is difficult to reason mathematically about a var s , i : integer : = 1 ; procedural program. begin while i <=n do s := s∗ i ; i := i + 1 ; end ; r e t u r n s ; end f a c t . ¦ ¥ 520—Spring 2005—2 [7] 520—Spring 2005—2 [8] Functional Programming Functional Languages In contrast to procedural languages, functional programs Common characteristics of functional programming don’t concern themselves with state and memory locations. languages: Instead, they work exclusively with values, and 1. Simple and concise syntax and semantics. expressions and functions which compute values. 2. Repetition is expressed as recursion rather than Functional programming is not tied to the von Neumann iteration. machine. 3. Functions are first class objects. I.e. functions can be It is not necessary to know anything about the manipulated just as easily as integers, floats, etc. in underlying hardware when writing a functional program, other languages. the way you do when writing an imperative program. 4. Data as functions. I.e. we can build a function on the Functional programs are more declarative than fly and then execute it. (Some languages). procedural ones; i.e. they describe what is to be computed rather than how it should be computed. 520—Spring 2005—2 [9] 520—Spring 2005—2 [10] Functional Languages. Functional Languages. 5. Higher-order functions. I.e. functions can take 8. Polymorphic types. Functions can work on data of functions as arguments and return functions as results. different types. (Some languages). 6. Lazy evaluation. Expressions are evaluated only when 9. Functional programs can be more easily needed. This allows us to build infinite data structures, manipulated mathematically than procedural programs. where only the parts we need are actually constructed. (Some languages). Pure vs. Impure FPL 7. Garbage Collection. Dynamic memory that is no longer Some functional languages are pure, i.e. they contain needed is automatically reclaimed by the system. GC is no imperative features at all. Examples: Haskell, also available in some imperative languages (Modula-3, Miranda, Gofer. Eiffel) but not in others (C, C++, Pascal). Impure languages may have assignment-statements, goto:s, while-loops, etc. Examples: LISP, ML, Scheme. 520—Spring 2005—2 [11] 520—Spring 2005—2 [12] What is a function? More on functions A function maps argument values (inputs) to result A function must not map an input value to values (outputs). more than one output value. Example: A function takes argument values from a source set (or True domain). A function produces result values that lie in a target set Jenny IsPretty (or range). False Source (Domain) Function Target (Range) not a Sweden Washington DC Capital function ! USA NZ Stockholm Wellington Copenhagen 520—Spring 2005—2 [13] 520—Spring 2005—2 [14] More on functions. More on functions. If a function F maps every element in the domain to A function that is undefined for some inputs, is called some element in the range, then F is total. I.e. a total partial. function is defined for all arguments. Int Int Divide Int Plus Int Int Int ? Divide is partial since 0 =? is undefined. 520—Spring 2005—2 [15] 520—Spring 2005—2 [16] Specifying functions Specifying functions. A function can be specified extensionally or intentionally. Intensionally: Extensionally: Give a rule (i.e. algorithm) that computes the result from the arguments. Enumerate the elements of the (often infinite) set of pairs “(argument, result)” or The intentional view emphasizes the process (or “Argument 7! Result.” algorithm) that is used to compute the result from the arguments. The extensional view emphasizes the external behavior (or specification), i.e. what the function does, rather double x = 2 * x than how it does it. even x = x mod 2 == 0 isHandsome x = if isBald x double = {· · ·, (1,2), (5,10), · · ·g then True even = {· · ·, (0,True), (1,False), · · ·g else False double = {· · ·, 17!2, 57!10, · · ·g isHandsome=fChris7!True,Hugh7!Falseg 520—Spring 2005—2 [17] 520—Spring 2005—2 [18] Specifying functions. Function Application Graphically: The most important operation in a functional program is The graphical view is a notational variant of the function application, i.e. applying an input argument to intentional view. the function, and retrieving the result: double x = 2 * x even even x = x mod 2 == 0 or even double 5 ) 10 even 6 ) True eithereven 520—Spring 2005—2 [19] 520—Spring 2005—2 [20] Function Composition Function Definition — Example Function composition makes the result of one function Example: How many numbers are there between m and n, application the input to another application: inclusive? Extensional Definition: double x = 2 * x sumbetween m n = {· · · (1; 1) 7! 1; (1; 2) 7! 2; · · · ; (2; 10) 7! 9g even x = x mod 2 == 0 Intentional Definition: sumbetween m n = ((m + n) * (abs (m-n) + 1)) div 2 even (double 5) ) even 10 ) True Graphical Definition: m + * n div − abs + 2 1 sumbetween 520—Spring 2005—2 [21] 520—Spring 2005—2 [22] Function Signatures Referential Transparency To define a function we must specify the types of the input The most important concept of functional programming and output sets (domain and range, i.e. the function’s is referential transparency. Consider the expression signature), and an algorithm that maps inputs to outputs. (2 ∗ 3) + 5 ∗ (2 ∗ 3) int The Signature! double int (2 ∗ 3) occurs twice in the expression, but it * has the same meaning (6) both times. 2 RT means that the value of a particular expression (or sub-expression) is always the same, regardless of where it occurs. int even Bool This concept occurs naturally in mathematics, but is broken by imperative programming languages. mod == RT makes functional programs easier to reason about 2 0 mathematically. 520—Spring 2005—2 [23] 520—Spring 2005—2 [24] Referential Transparency. Referential Transparency. RT is a fancy term for a very simple concept. Pure functional programming languages are What makes FP particularly simple, direct, and referentially transparent. expressive, is that there is only one mechanism This means that it is easy to find the meaning (value) of (function application) for communicating between an expression. subprograms. We can evaluate it by substitution. I.e. we can replace In imperative programs we can communicate either a function application by the function definition itself. through procedure arguments or updates of global variables. This is hard to reason about mathematically. A notation (programming language) where the value of an expression depends only on the values of the sub-expressions is called referentially transparent. 520—Spring 2005—2 [25] 520—Spring 2005—2 [26] Referential Transparency.
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]
  • A Feature Model of Actor, Agent, Functional, Object, and Procedural Programming Languages
    Accepted Manuscript A feature model of actor, agent, functional, object, and procedural programming languages H.R. Jordan, G. Botterweck, J.H. Noll, A. Butterfield, R.W. Collier PII: S0167-6423(14)00050-1 DOI: 10.1016/j.scico.2014.02.009 Reference: SCICO 1711 To appear in: Science of Computer Programming Received date: 9 March 2013 Revised date: 31 January 2014 Accepted date: 5 February 2014 Please cite this article in press as: H.R. Jordan et al., A feature model of actor, agent, functional, object, and procedural programming languages, Science of Computer Programming (2014), http://dx.doi.org/10.1016/j.scico.2014.02.009 This is a PDF file of an unedited manuscript that has been accepted for publication. As a service to our customers we are providing this early version of the manuscript. The manuscript will undergo copyediting, typesetting, and review of the resulting proof before it is published in its final form. Please note that during the production process errors may be discovered which could affect the content, and all legal disclaimers that apply to the journal pertain. Highlights • A survey of existing programming language comparisons and comparison techniques. • Definitions of actor, agent, functional, object, and procedural programming concepts. • A feature model of general-purpose programming languages. • Mappings from five languages (C, Erlang, Haskell, Jason, and Java) to this model. A Feature Model of Actor, Agent, Functional, Object, and Procedural Programming Languages H.R. Jordana,∗, G. Botterwecka, J.H. Nolla, A. Butterfieldb, R.W. Collierc aLero, University of Limerick, Ireland bTrinity College Dublin, Dublin 2, Ireland cUniversity College Dublin, Belfield, Dublin 4, Ireland Abstract The number of programming languages is large [1] and steadily increasing [2].
    [Show full text]
  • The Machine That Builds Itself: How the Strengths of Lisp Family
    Khomtchouk et al. OPINION NOTE The Machine that Builds Itself: How the Strengths of Lisp Family Languages Facilitate Building Complex and Flexible Bioinformatic Models Bohdan B. Khomtchouk1*, Edmund Weitz2 and Claes Wahlestedt1 *Correspondence: [email protected] Abstract 1Center for Therapeutic Innovation and Department of We address the need for expanding the presence of the Lisp family of Psychiatry and Behavioral programming languages in bioinformatics and computational biology research. Sciences, University of Miami Languages of this family, like Common Lisp, Scheme, or Clojure, facilitate the Miller School of Medicine, 1120 NW 14th ST, Miami, FL, USA creation of powerful and flexible software models that are required for complex 33136 and rapidly evolving domains like biology. We will point out several important key Full list of author information is features that distinguish languages of the Lisp family from other programming available at the end of the article languages and we will explain how these features can aid researchers in becoming more productive and creating better code. We will also show how these features make these languages ideal tools for artificial intelligence and machine learning applications. We will specifically stress the advantages of domain-specific languages (DSL): languages which are specialized to a particular area and thus not only facilitate easier research problem formulation, but also aid in the establishment of standards and best programming practices as applied to the specific research field at hand. DSLs are particularly easy to build in Common Lisp, the most comprehensive Lisp dialect, which is commonly referred to as the “programmable programming language.” We are convinced that Lisp grants programmers unprecedented power to build increasingly sophisticated artificial intelligence systems that may ultimately transform machine learning and AI research in bioinformatics and computational biology.
    [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]
  • 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]
  • 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]
  • A Formal Component-Based Software Engineering Approach for Developing Trustworthy Systems
    A FORMAL COMPONENT-BASED SOFTWARE ENGINEERING APPROACH FOR DEVELOPING TRUSTWORTHY SYSTEMS MUBARAK SAMI MOHAMMAD A THESIS IN THE DEPARTMENT OF COMPUTER SCIENCE AND SOFTWARE ENGINEERING PRESENTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF DOCTOR OF PHILOSOPHY (COMPUTER SCIENCE) CONCORDIA UNIVERSITY MONTREAL´ ,QUEBEC´ ,CANADA APRIL 2009 °c MUBARAK SAMI MOHAMMAD, 2009 CONCORDIA UNIVERSITY School of Graduate Studies This is to certify that the thesis prepared By: Mr. Mubarak Sami Mohammad Entitled: A Formal Component-Based Software Engineering Approach for Developing Trustworthy Systems and submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy (Computer Science) (Computer Science) complies with the regulations of this University and meets the accepted standards with re- spect to originality and quality. Signed by the final examining committee: Chair Dr. External Examiner Dr. Nicholas Graham External to Program Dr. Jamal Bentahar Examiner Dr. Joey Paquet Examiner Dr. Juergen Rilling Supervisor Dr. Vasu Alagar Co-supervisor Dr. Olga Ormandjieva Approved Chair of Department or Graduate Program Director 20 Dr. Robin A.L. Drew, Dean Faculty of Engineering and Computer Science Abstract A Formal Component-Based Software Engineering Approach for Developing Trustworthy Systems Mubarak Sami Mohammad, Ph.D. Concordia University, 2009 Software systems are increasingly becoming ubiquitous, affecting the way we experience the world. Embedded software systems, especially those used in smart devices, have be- come an essential constituent of the technological infrastructure of modern societies. Such systems, in order to be trusted in society, must be proved to be trustworthy. Trustworthiness is a composite non-functional property that implies safety, timeliness, security, availability, and reliability.
    [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]
  • Programming Languages
    Lecture 19 / Chapter 13 COSC1300/ITSC 1401/BCIS 1405 12/5/2004 Lecture 19 / Chapter 13 COSC1300/ITSC 1401/BCIS 1405 12/5/2004 General Items: Computer Program • Lab? Ok? • Read the extra credits • A series of instructions that direct a computer to perform tasks • Need to come to class • Such as? Who is the programmer? • Have a quiz / no books / use notes -> What is the big idea • School is almost over • Programming language is a series of rules for writing the instructions • • There are hundreds of computer programs – need-based! Reading Materials: Programming language • - Two basic types: Low- and high-level programming languages Miscellaneous: o Low-level: Programming language that is machine-dependent ° Must be run on specific machines o High-level: Language that is machine-independent ° Can be run on different types of machines Programming Language Low Level High Level Machine Assembly Language Language Procedural Nonprocedural Remember: Ultimately, everything must be converted to the machine language! Object Oriented F.Farahmand 1 / 12 File: lec14chap13f04.doc F.Farahmand 2 / 12 File: lec14chap13f04.doc Lecture 19 / Chapter 13 COSC1300/ITSC 1401/BCIS 1405 12/5/2004 Lecture 19 / Chapter 13 COSC1300/ITSC 1401/BCIS 1405 12/5/2004 Categories of programming languages o Nonprocedural language -> Programmer specifies only what the - Machine language program should accomplish; it does not explain how o Only language computer understands directly - Forth-generation language - Assembly language o Syntax is closer to human language than that
    [Show 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.
    [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]
  • C++ Tutorial Part I : Procedural Programming
    C++ Tutorial Part I : Procedural Programming C. David Sherrill School of Chemistry and Biochemistry School of Computational Science and Engineering Georgia Institute of Technology Purpose To provide rapid training in elements of C++ syntax, C++ procedural programming, and C++ object- oriented programming for those with some basic prior programming experience To provide a handy programming reference for selected topics To provide numerous, actual C++ code examples for instruction and reference Why C++? “Intermediate”-level language: allows for fine (low- level) control over hardware, yet also allows certain complex tasks to be done with relatively little code (high-level) Good for scientific applications: produces efficient, compiled code, yet has features that help one develop and maintain a complicated, large code (e.g., namespaces, object-oriented design) Recommended reading These notes were developed during my reading of “Sams Teach Yourself C++ in One Hour a Day,” 7th Edition, by Siddhartha Rao (Sams, Indianapolis, 2012). I recommend the book, it’s readable and to the point. A good mastery of C++ will probably require working through a book like that one, and doing some examples; notes like these only serve as a basic introduction or a quick review A Note on C++11 This was originally supposed to be C++0x, with the “x” filled in according to the year the new C++ standard was finalized (e.g., C++09 for 2009). However, the standard took longer than expected, and was only formalized in 2011. So, C++11 is what was formerly referred to as C++0x. As of 2013, the new C++11 standards are not yet fully implemented in many compilers.
    [Show full text]