* Overview of Functional Programming
** Where functional languages fit in the world of programming
   Functional Programming is a programming paradigm, like Imperative programming
   or Object Oriented
*** History
    Functional programming languages can trace their roots back to Lambda
    Calculus, a branch of logic which was first conceived in the early 20th
    century, when computing was in it's infancy. Lambda calculus is really just
    a formalized notation for defining and composing functions. It has stayed
    largely confined to academia due to it's lack of any real world
    practicality. Functional programming was born of this branch of formal
    logic, and for a while it too stayed mostly isolated in academia. However,
    unlike lambda calculus, functional programming languages have practical
    value, and although functional programming has been around as long as many
    other paradigms, it has recently begun gaining popularity.

** Defining Functional Programming
*** Evaluation of Expressions
    Functional programs perform computations by the evaluation of expressions, as
    opposed to executing statements which change a global state. One could say that
    in imperative programming, statements are the basic building blocks of a
    program. In object oriented programming, objects are the basic building blocks.
    In functional programming, functions are the basic building blocks.

*** First Class Functions
    Functions are also first class, meaning that functions can be passed around
    and used like any other sort of value. Because a functions evaluate to
    values, they can be used just like the value, meaning they can be passed as
    arguments to other functions, assigned to variables, returned from
    functions, which leads to something called partial application.

*** Function Purity
    A lot of functional languages are pure. Functional purity means that any
    functions do not have side effects. That is, they do not change a global
    state. Changing a global state could mean anything from printing to the
    screen, to changing the state of a variable scoped outside of the
    function. The advantage of pure code is that it is generally less error prone.
**** Not all functional languages are pure
     Haskel enforces purity, but Scala does not
**** How to get things done in a pure language
     If purity restricts IO, how do you get things done? Complicated
     question. Scala allows side effects when necessary, but encourages purity
     for the most part. Thus, it is common to write most code in a pure,
     functional style, and have a small portion of your code be impure with I/O
     side effects and state to minimize the chance for error.
**** Immutability
     Data immutability is a large part of functional programming. That is, to
     avoid side effects, functions return an altered copy of the data they
     operate on.
***** Memory Implications of immutability
      Since data is immutable, the unmodified portion of the data can be shared,
      reducing the total memory cost. There are other factors to consider more,
      but I'll talk more about that when I talk about Haskell. (Functional
      languages prefer linked lists over arrays because the time to prepend an
      element to a linked list is constant). Also factors like GC and
      optimizations affect this. Lazy evaluation also affect this.
**** Referential transparency
     Calling a function with the same inputs creates the same output every
     time. This again reflects the stateless nature of functional programming.
*** Higher order functions
    Functions that take other functions as their arguments. E.g. map.
*** Recursion
    Yep. 
    Tail call optimization.
   
** Why Functional Programming?
*** Provides a layer of abstraction
    Same as object oriented programming, it provides a layer of abstraction, and
    the ability to abstract more easily. One thing I've seen personally is that
    functional programming can address some of the design patterns I've seen in
    Object oriented code that can be tedious or problematic. E.G. first class
    functions help you avoid things like:

    applicator.apply()
    imageManipulatorFactoryFactory.make()
    doer.do()
**** Counterpoint: 
     More abstraction leads to more overhead, code can be slower
*** Code is shorter
    Functional programs can be shorter, more expressive, and easier to read
    than other types of code.
**** Counterpoint:
     The converse can also be equally true. Functional programs can also be
     longer, harder to read, and require special training. Also, purity can make
     things like I/O a pain. When real world programs need to do things like
     . . . I/O, this can become tiresome. Thus, functional programming can be
     criticized for being too idyllic and impractical. 
*** Concurrency
    Stateless code is easier to parallelize, both from the perspective of the
    developer and the compiler.
**** Counterpoint: 
     I've never seen an example of this

** Takeaway
   Anyone who tells you that functional programming is going to be *the* future
   of programming is lying to you. Functional programming has some good
   application specific domains (compiler programming gets cited a lot), but it
   is not a universal panacea. IT has some positive aspects that will see
   adoption by mainstream programming languages over time, and it's also already
   have aspects incorporated into languages (map in python and javascript,
   lambdas in lots of languages).