Table of Contents
IntroductionJoe Nelson outlines the scope of the course. The soul of functional programing is separating the concerns of what you are doing and recognizing those separations are happening. Creating clean code requires discipline. Custom names, looping patterns, glue code, etc. are side effects of a lack of discipline and invitations for messy code.
Omit Needless NamesThe first part of creating silence in your code is omitting needless names. This process can help separate inputs from the environment. Joe provides an exercise to help demonstrate this. He shows how testing a "daysThisMonth" function is much more difficult that testing a "daysInMonth" function.
Separating Mutation from CalculationA function that reads DOM elements and manipulates them can be difficult to test. This is because a test case must create mock elements to feed to the function. Instead, the function could be simplified to only manipulate a piece of text. This is easier to test and leaves the mutation of the DOM to another routine.
Recognize Pure FunctionA function that does not change anything outside of itself is considered a pure function. Pure functions react the same way to the same inputs. They are more testable, portable, memoizable, and parallelizable. Joe plays a game called Pure or Impure to help the audience recognize pure functions.
Separate Functions from RulesFunctions are nouns. A goal of functional programing is to write functions that take in a lot of arguments, but only give them one argument at a time. This process is called "currying".
Currying ExerciseIn this exercise, create a few different functions that utilize various curried function built into the Ramda library. Joe gives a little background information about the exercise files and fields questions from the audience as they are working on the exercise. - Problem: http://jsbin.com/romun - Solution: http://jsbin.com/mojusuyane
Currying Exercise HintsJoe gives a little guidance to how to get started with this exercise. He demonstrates a partial answer to the first challenge and fields a few more questions from the audience. - Problem: http://jsbin.com/romun - Solution: http://jsbin.com/mojusuyane
Currying Exercise Solutions 1 & 2Joe walks through the solution for the currying exercise. He starts with challenges 1 & 2. Joe then gives the audience more time to finish the 3rd challenge in this exercise. - Problem: http://jsbin.com/romun - Solution: http://jsbin.com/mojusuyane
Currying Exercise, Challenge 3 SolutionChallenge 3 in this exercise requires you to create a function that finds the largest number in a list. Joe begins walking through this complex solution. He then takes a few minutes to further explain the "reduce" function. - Problem: http://jsbin.com/romun - Solution: http://jsbin.com/mojusuyane
Currying Exercise, Challenge 3 Solution, continuedJoe continues his demonstration of the solutions for challenge three. At the end, he summarized all three challenges to further enforce the separation that currying enables. - Problem: http://jsbin.com/romun - Solution: http://jsbin.com/mojusuyane
ComposeFunctions can "meld" with other functions. This process is referred to as composing. When composing functions, the resulting composition should be separated from the arguments. Joe demonstrates a simplified compose function.
Composition ExerciseThis exercise focuses on combining methods through composition to create a better separation of concerns. Joe spends a few minutes describing the challenges and getting the audience started on the exercise. - Problem: http://jsbin.com/jevag - Solution: http://jsbin.com/gowugugaso
Composition Exercise: Challenge 1 SolutionJoe demonstrates the solution for the first challenge in this exercise. After that, he gives a few hints for the second challenge. Joe also engages in some audience discussions around scalability and maintainability of functional programming code. - Problem: http://jsbin.com/jevag - Solution: http://jsbin.com/gowugugaso
Composition Exercise: Challenge 2 SolutionJoe walks through the solution for challenge 2. He also gives the audience a little time to work on the third challenge. - Problem: http://jsbin.com/jevag - Solution: http://jsbin.com/gowugugaso
Composition Exercise: Challenge 3 SolutionJoe concludes the composition exercise with the solution to challenge 3. - Problem: http://jsbin.com/jevag - Solution: http://jsbin.com/gowugugaso
Point-FreeIn functional programing "points" refer to arguments. So point-free programming is the removal of arguments through composition. Joe shows a few examples of functions that have been created point-free.
The Silence: ReviewJoe reviews what he covered in The Silence phase. This includes making function inputs explicit, providing arguments over time, not modifying external objects, and composition without glue variables. Joe also spends some time answering questions about the content in this first part.
Questions, continuedJoe answers some additional audience questions and shows some tips and tricks when using JS Bin.
Reviewing CompositionBrian Lonsdorf now takes over to discuss "The Voyage". Before moving forward, Brian addresses a few more questions that popped up over lunch about Part 1 of this course. He stresses that functional programming is very declarative and all you are really doing is composing smaller bits to make a larger system.
Category TheoryIn category theory, you need a composition and an identity to form a category. Brian introduces category theory and defines various category laws like left identity, right identity, and associativity.
ObjectsBrian reintroduces objects in a different light. In his definition of objects, they are containers/wrappers for values. The have no methods and are not nouns. The first object he demonstrates in a Container object.
Object MapBrian discusses the advantages of having a map function added to the prototype of an object. By adding a map function, the container object can be opened up and the value pulled out.
Maybe FunctorAny object or data structure that implements the map function is considered a functor. The first functor Brian demonstrates is the "Maybe" functor which will capture a null check. That value inside may or may not be there. When you add a Maybe into a compose, it will always check to make sure the value is there. If not, it will stop the composition.
Functors Exercise 1In this exercise, you will use _.add and _.map to make a function that increments a value inside a functor. Brian does this exercise with the audience to help get them started writing functors. - Problem: http://jsbin.com/yumog - Solution: http://jsbin.com/xiwofojura
Functors Exercise 2Brian moves on to exercise two. In this exercise, you need to use _.head to get the first element of the list. After a few hints, Brian gives the group some time to work through the solution. He also answers a few questions while they work and explains maps a little more in-depth. - Problem: http://jsbin.com/yumog - Solution: http://jsbin.com/xiwofojura
Functors Exercise 2 SolutionBrian walks through the solution to exercise 2 and answer a number of follow-up questions from the audience. He also further emphasizes how implementing a map on a container abstracts a function's application. - Problem: http://jsbin.com/yumog - Solution: http://jsbin.com/xiwofojura
Functors Exercise 3 SolutionExercise 3 asked you to use the safeGet and _.head functions to extract the first initial of the user. Brian walks through the solution. In a later video, he comes back and further explains this exercise. - Problem: http://jsbin.com/yumog - Solution: http://jsbin.com/xiwofojura
Functors Exercise 4 SolutionBrian steps through the solution for exercise 4 which requires you to use Maybe in place of an if statement. While solving exercise 4 he jumps into an attendee's JSBin to help them solve the exercise. - Problem: http://jsbin.com/yumog - Solution: http://jsbin.com/xiwofojura
Functors Exercise Wrap-upBrian wraps up the exercises by answering a few more questions. He jumps back to exercise 3 to step through the solution more thoroughly. He stresses that functional code doesn't have to be completely point-free. Maybe object can be mixed with imperative code. - Problem: http://jsbin.com/yumog - Solution: http://jsbin.com/xiwofojura
EitherThe Either functor is typically used for pure error handling. It functions just like Maybe, but with an error message embedded. Either includes subclasses Left and Right. Right will always run. Left would not run and return the error message.
IOIO is a functor that is considered a lazy computation "builder". It's typically used to contain side effects. So rather than contain a String or Array, it will contain a function. A map appends the function to a list of items to run.
Either/IO Exercise 1In this exercise, write a function that uses checkActive() and showWelcome() to grant access or return an error. Brian gives the audience a few minutes to start working on this exercise before giving the solution. - Problem: http://jsbin.com/zegat - Solution: http://jsbin.com/tosusijoje
Either/IO Exercises 2, 3 & 4Brian picks up the pace a bit and demonstrates a few more exercises. Exercise 2 expands on exercise 1 by adding validation. You'll validate the for a length greater than 3 and return a Right or a Left based on that validation. In exercise 3, the Either used in exercise two should be rewritten to be a functor. Exercise 4 pulls text from a user input field and strips out the spaces. - Problem: http://jsbin.com/zegat - Solution: http://jsbin.com/tosusijoje
Either/IO Exercise 5 and 6Brian wraps up the exercises covering Either and IO by showing the audience the solution to exercises 5 and 6. - Problem: http://jsbin.com/zegat - Solution: http://jsbin.com/tosusijoje
Other FunctorsBrian breezes through a few more functors. EventStream provides an infinite list of results. Future has an eventual value similar to a Promise, except it's "lazy".
Other Functors: Exercise 1-5Brian works through the solutions for the 5 exercises in this section. That latter exercises transition into his discussion about monads.
Functor Laws & PropertiesIt's also important to recognize the laws and properties that functors must follow. These laws and properties make functors flexible and pluggable into any application. Brian discusses these laws and properties and shows a few illustrations. He also presents a number of scenarios to the audience and asks them to describe what functors would be required to build each scenario.
MonadsMonads allow you to nest computations. They are a pointed functor that adds mjoin and chain functions to combine other functors. Brian shows a number of code examples of different monads in action.
Monads ExercisesBrian quickly runs through all 3 exercises for the Monad section. He also concludes "The Voyage" section with a little more information on monads and shows they have their own set of laws similar to functors. - Problem: http://jsbin.com/woweg - Solution: http://jsbin.com/doroyomaya/
Demo Part 1Joe first sets up an event stream that will connect to the DOM element and listen for an event when a key is pressed.
Demo Part 2Now that we have a key pressed stream, Joe sets up a stream that will read the value from the input field. Once he has the value, he can tie that in with the YouTube API.
Demo Part 3Joe creates a Future that will pull video data from the YouTube API. The Future result is JSON data that will be used to update the DOM.
Demo Part 4With the JSON data loaded, Joe creates and "entryToLI" function that will take the entry data and output HTML code. This code is placed on the page as the list of video.
Final ThoughtsAfter having a few debugging issues, Joe walks through a few commits of the project to help summarize the final code in the YouTube demo application. Brian adds a couple last remarks as they conclude the course.