Related material from the same author is the Mostly Adequate Guide to Functional Programming. This Dev How To project/site has a section with solutions and extra notes on that (awesome and free) book. Check it out!
My notes and examples sometimes use a few helper functions that either I created or that I extracted from a video lesson into a reusable function. If you are reading a page and it seems there is no definition for a certain function, check the Helper Functions page.
A Note on Extra Examples and Deviations From The Videos#
While studying this content myself and creating these notes and the unit tests, I sometimes change the original code a little bit, or add extra notes on “flaws” in his code and propose a different, “better” solution.
Or course Brian Lonsdorf (the author of the original content and the videos) knows about all these things. He probably just wanted to focus on the main ideas, without digressions and to keep the code short and easy to read.
One such example of this happening is on Video 05, concatUniq() imperative style.
A Note on the Wording Used#
The explanations (my explantions and notes on the content of the videos) at times use wording like “beginner-like approach”, or “this implementation is too much procedural”, or “too much object-oriented”, etc.
The intent is not to deride beginners 1 or to imply that other programming paradigms are bad 2. The focus here is on functional programming. We strive for a functional style as much as possible since the goal is to learn and practice this specific programming paradigm. So, when something does not conform to the principles of FP, we occasionally make such comparisons and comments as a means to show how much the given implementation is non-conformant, or how far away it is to the functional paradigm.
Also, if beginners tend to do things in a certain way, that is OK. The goal is to keep learning and improving. If the procedural, or the object-oriented, or functional programming style have such and such pros and cons, that is OK too 3. Again, the goal is to learn so we can offer more educated opinions and make more informed decisions in any given situation 4.
I myself am a beginner in a lot of stuff, have always been, and will always be.
I myself like to study and practice C, Shell Script, C++, Ruby, Java, etc., which are more procedural or object-oriented in style, among, of course, Haskell, Scheme, Lisp and similar which are either purely functional or are at least feel very comfortable and work well for a functional style.
Similar things could be said about static-typing (at compile time) or dynamic typing (at runtime). Both have advantages and disadvantages (that is stating the obvious), but worth keeping in mind.
I am amazed by John Carmack’s (traditionally a C/C++ programmer) humility talking about his willingness to learn Lisp and Functional Programming. He is also humble when he says thinks like “I wanted to do some real project in Haskell” so he could “talk about their merits on a concrete sense rather than an abstract sense” and that he “does think he soft of gets Lisp now.” Watch this part about Haskell and this part about Lisp. They are from John Carmack’s keynote at Quakecon 2013.
- 01 - Create linear data flow with container style types (Box)
- 02 - Refactor Imperative to Composed Expression using Box
- 03 - Enforce a null check with composable code branching using Either
- 04 - Use chain for composable error handling with nested Eithers
- 05 - A collection of Either examples compared to imperative code
- Final Notes
- Helper Functions