6 |
7 | This book is a balanced, pragmatic look at FP in JavaScript. The first edition is now complete. Read here online **for free**, or:
8 |
9 |
10 | 
11 |
51 |
52 |
4 |
5 | [](https://leanpub.com/fljs) [](http://amazon.fljsbook.com)
6 |
7 | ## Table of Contents
8 |
9 | * [Foreword](foreword.md/#foreword)
10 | * [Preface](preface.md/#preface)
11 | * [Chapter 1: Why Functional Programming?](ch1.md/#chapter-1-why-functional-programming)
12 | * [At a Glance](ch1.md/#at-a-glance)
13 | * [Confidence](ch1.md/#confidence)
14 | * [Communication](ch1.md/#communication)
15 | * [Readability](ch1.md/#readability)
16 | * [Perspective](ch1.md/#perspective)
17 | * [How to Find Balance](ch1.md/#how-to-find-balance)
18 | * [Resources](ch1.md/#resources)
19 | * [Chapter 2: The Nature Of Functions](ch2.md/#chapter-2-the-nature-of-functions)
20 | * [What Is A Function?](ch2.md/#what-is-a-function)
21 | * [Function Input](ch2.md/#function-input)
22 | * [Named Arguments](ch2.md/#named-arguments)
23 | * [Function Output](ch2.md/#function-output)
24 | * [Functions Of Functions](ch2.md/#functions-of-functions)
25 | * [Syntax](ch2.md/#syntax)
26 | * [What's This?](ch2.md/#whats-this)
27 | * [Chapter 3: Managing Function Inputs](ch3.md/#chapter-3-managing-function-inputs)
28 | * [All For One](ch3.md/#all-for-one)
29 | * [Adapting Arguments to Parameters](ch3.md/#adapting-arguments-to-parameters)
30 | * [Some Now, Some Later](ch3.md/#some-now-some-later)
31 | * [One At A Time](ch3.md/#one-at-a-time)
32 | * [Order Matters](ch3.md/#order-matters)
33 | * [No Points](ch3.md/#no-points)
34 | * [Chapter 4: Composing Functions](ch4.md/#chapter-4-composing-functions)
35 | * [Output To Input](ch4.md/#output-to-input)
36 | * [General Composition](ch4.md/#general-composition)
37 | * [Reordered Composition](ch4.md/#reordered-composition)
38 | * [Abstraction](ch4.md/#abstraction)
39 | * [Revisiting Points](ch4.md/#revisiting-points)
40 | * [Chapter 5: Reducing Side Effects](ch5.md/#chapter-5-reducing-side-effects)
41 | * [Effects On The Side, Please](ch5.md/#effects-on-the-side-please)
42 | * [Once Is Enough, Thanks](ch5.md/#once-is-enough-thanks)
43 | * [Pure Bliss](ch5.md/#pure-bliss)
44 | * [There Or Not](ch5.md/#there-or-not)
45 | * [Purifying](ch5.md/#purifying)
46 | * [Chapter 6: Value Immutability](ch6.md/#chapter-6-value-immutability)
47 | * [Primitive Immutability](ch6.md/#primitive-immutability)
48 | * [Value To Value](ch6.md/#value-to-value)
49 | * [Reassignment](ch6.md/#reassignment)
50 | * [Performance](ch6.md/#performance)
51 | * [Treatment](ch6.md/#treatment)
52 | * [Chapter 7: Closure vs Object](ch7.md/#chapter-7-closure-vs-object)
53 | * [The Same Page](ch7.md/#the-same-page)
54 | * [Look Alike](ch7.md/#look-alike)
55 | * [Two Roads Diverged In A Wood...](ch7.md/#two-roads-diverged-in-a-wood)
56 | * [Chapter 8: Recursion](ch8.md/#chapter-8-recursion)
57 | * [Definition](ch8.md/#definition)
58 | * [Declarative Recursion](ch8.md/#declarative-recursion)
59 | * [Stack](ch8.md/#stack)
60 | * [Rearranging Recursion](ch8.md/#rearranging-recursion)
61 | * [Chapter 9: List Operations](ch9.md/#chapter-9-list-operations)
62 | * [Non-FP List Processing](ch9.md/#non-fp-list-processing)
63 | * [Map](ch9.md/#map)
64 | * [Filter](ch9.md/#filter)
65 | * [Reduce](ch9.md/#reduce)
66 | * [Advanced List Operations](ch9.md/#advanced-list-operations)
67 | * [Method vs. Standalone](ch9.md/#method-vs-standalone)
68 | * [Looking For Lists](ch9.md/#looking-for-lists)
69 | * [Fusion](ch9.md/#fusion)
70 | * [Beyond Lists](ch9.md/#beyond-lists)
71 | * [Chapter 10: Functional Async](ch10.md/#chapter-10-functional-async)
72 | * [Time As State](ch10.md/#time-as-state)
73 | * [Eager vs Lazy](ch10.md/#eager-vs-lazy)
74 | * [Reactive FP](ch10.md/#reactive-fp)
75 | * [Chapter 11: Putting It All Together](ch11.md/#chapter-11-putting-it-all-together)
76 | * [Setup](ch11.md/#setup)
77 | * [Stock Events](ch11.md/#stock-events)
78 | * [Stock Ticker UI](ch11.md/#stock-ticker-ui)
79 | * [Appendix A: Transducing](apA.md/#appendix-a-transducing)
80 | * [Why, First](apA.md/#why-first)
81 | * [How, Next](apA.md/#how-next)
82 | * [What, Finally](apA.md/#what-finally)
83 | * [Appendix B: The Humble Monad](apB.md/#appendix-b-the-humble-monad)
84 | * [Type](apB.md/#type)
85 | * [Loose Interface](apB.md/#loose-interface)
86 | * [Just a Monad](apB.md/#just-a-monad)
87 | * [Maybe](apB.md/#maybe)
88 | * [Humble](apB.md/#humble)
89 | * [Appendix C: FP Libraries](apC.md/#appendix-c-fp-libraries)
90 | * [Stuff to Investigate](apC.md/#stuff-to-investigate)
91 | * [Ramda](apC.md/#ramda-0230)
92 | * [Lodash/fp](apC.md/#lodashfp-4174)
93 | * [Mori](apC.md/#mori-032)
94 | * [Bonus: FPO](apC.md/#bonus-fpo)
95 | * [Bonus #2: fasy](apC.md/#bonus-2-fasy)
96 |
--------------------------------------------------------------------------------
/manuscript/apC.md:
--------------------------------------------------------------------------------
1 | # Functional-Light JavaScript
2 | # Appendix C: FP Libraries
3 |
4 | If you've been reading this book from start to finish, take a minute to stop and look back how far you've come since [Chapter 1](ch1.md). It's been quite a journey. I hope you've learned a lot and gained insight into thinking functionally for your own programs.
5 |
6 | I want to close this book leaving you with some quick pointers of working with common/popular FP libraries. This is not an exhaustive documentation on each, but a quick glance at the things you should be aware of as you venture beyond "Functional-Light" into broader FP.
7 |
8 | Wherever possible, I recommend you *not* reinvent any wheels. If you find an FP library that suits your needs, use it. Only use the ad hoc helper utilities from this book -- or invent ones of your own! -- if you can't find a suitable library method for your circumstance.
9 |
10 | ## Stuff to Investigate
11 |
12 | Let's expand the [list of FP libraries to be aware of, from Chapter 1](ch1.md/#libraries). We won't cover all of these (as there's a lot of overlap), but here are the ones that should probably be on your radar screen:
13 |
14 | * [Ramda](http://ramdajs.com): General FP Utilities
15 | * [Sanctuary](https://github.com/sanctuary-js/sanctuary): Ramda Companion for FP Types
16 | * [lodash/fp](https://github.com/lodash/lodash/wiki/FP-Guide): General FP Utilities
17 | * [functional.js](http://functionaljs.com/): General FP Utilities
18 | * [Immutable](https://github.com/facebook/immutable-js): Immutable Data Structures
19 | * [Mori](https://github.com/swannodette/mori): (ClojureScript Inspired) Immutable Data Structures
20 | * [Seamless-Immutable](https://github.com/rtfeldman/seamless-immutable): Immutable Data Helpers
21 | * [transducers-js](https://github.com/cognitect-labs/transducers-js): Transducers
22 | * [monet.js](https://github.com/monet/monet.js): Monadic Types
23 |
24 | There are dozens of other fine libraries not on this list. Just because it's not on my list here doesn't mean it's not good, nor is this list a particular endorsement. It's just a quick glance at the landscape of FP-in-JavaScript. A much longer list of FP resources can be [found here](https://github.com/stoeffel/awesome-fp-js).
25 |
26 | One resource that's extremely important to the FP world -- it's not a library but more an encyclopedia! -- is [Fantasy Land](https://github.com/fantasyland/fantasy-land) (aka FL).
27 |
28 | This is definitely not light reading for the faint of heart. It's a complete detailed roadmap of all of FP as it's interpreted in JavaScript. FL has become a de facto standard for JavaScript FP libraries to adhere to, to ensure maximum interoperability.
29 |
30 | Fantasy Land is pretty much the exact opposite of "Functional-Light". It's the full-on no-holds-barred approach to FP in JavaScript. That said, as you venture beyond this book, it's likely that FL will be on that road for you. I'd recommend you bookmark it, and go back to it after you've had at least six months of real-world practice with this book's concepts.
31 |
32 | ## Ramda (0.23.0)
33 |
34 | From the [Ramda documentation](http://ramdajs.com/):
35 |
36 | > Ramda functions are automatically curried.
37 | >
38 | > The parameters to Ramda functions are arranged to make it convenient for currying. The data to be operated on is generally supplied last.
39 |
40 | I find that design decision to be one of Ramda's strengths. It's also important to note that Ramda's form of currying (as with most libraries, it seems) is the ["loose currying" we talked about in Chapter 3](ch3.md/#user-content-loosecurry).
41 |
42 | The [final example of Chapter 3](ch3.md/#user-content-finalshortlong) -- recall defining a point-free `printIf(..)` utility -- can be done with Ramda like this:
43 |
44 | ```js
45 | function output(msg) {
46 | console.log( msg );
47 | }
48 |
49 | function isShortEnough(str) {
50 | return str.length <= 5;
51 | }
52 |
53 | var isLongEnough = R.complement( isShortEnough );
54 |
55 | var printIf = R.partial( R.flip( R.when ), [output] );
56 |
57 | var msg1 = "Hello";
58 | var msg2 = msg1 + " World";
59 |
60 | printIf( isShortEnough, msg1 ); // Hello
61 | printIf( isShortEnough, msg2 );
62 |
63 | printIf( isLongEnough, msg1 );
64 | printIf( isLongEnough, msg2 ); // Hello World
65 | ```
66 |
67 | A few differences to point out compared to [Chapter 3's approach](ch3.md/#user-content-finalshortlong):
68 |
69 | * We use `R.complement(..)` instead of `not(..)` to create a negating function `isLongEnough(..)` around `isShortEnough(..)`.
70 |
71 | * We use `R.flip(..)` instead of `reverseArgs(..)`. It's important to note that `R.flip(..)` only swaps the first two arguments, whereas `reverseArgs(..)` reverses all of them. In this case, `flip(..)` is more convenient for us, so we don't need to do `partialRight(..)` or any of that kind of juggling.
72 |
73 | * `R.partial(..)` takes all of its subsequent arguments (beyond the function) as a single array.
74 |
75 | * Because Ramda is using loose currying, we don't need to use `R.uncurryN(..)` to get a `printIf(..)` that takes both its arguments. If we did, it would look like `R.uncurryN( 2, .. )` wrapped around the `R.partial(..)` call; but that's not necessary.
76 |
77 | Ramda is a very popular and powerful library. It's a really good place to start if you're practicing adding FP to your code base.
78 |
79 | ## Lodash/fp (4.17.4)
80 |
81 | Lodash is one of the most popular libraries in the entire JS ecosystem. They publish an "FP-friendly" version of their API as ["lodash/fp"](https://github.com/lodash/lodash/wiki/FP-Guide).
82 |
83 | In [Chapter 9, we looked at composing standalone list operations](ch9.md/#composing-standalone-utilities) (`map(..)`, `filter(..)`, and `reduce(..)`). Here's how we could do it with "lodash/fp":
84 |
85 | ```js
86 | var sum = (x,y) => x + y;
87 | var double = x => x * 2;
88 | var isOdd = x => x % 2 == 1;
89 |
90 | fp.compose( [
91 | fp.reduce( sum )( 0 ),
92 | fp.map( double ),
93 | fp.filter( isOdd )
94 | ] )
95 | ( [1,2,3,4,5] ); // 18
96 | ```
97 |
98 | Instead of the more familiar `_.` namespace prefix, "lodash/fp" defines its methods with `fp.` as the namespace prefix. I find that a helpful distinguisher, and also generally more easy on my eyes than `_.` anyway!
99 |
100 | Notice that `fp.compose(..)` (also known as `_.flowRight(..)` in lodash proper) takes an array of functions instead of individual arguments.
101 |
102 | You cannot beat the stability, widespread community support, and performance of lodash. It's a solid bet for your FP explorations.
103 |
104 | ## Mori (0.3.2)
105 |
106 | In [Chapter 6](ch6.md), we already briefly glanced at the Immutable.js library, probably the most well-known for immutable data structures.
107 |
108 | Let's instead look at another popular library: [Mori](https://github.com/swannodette/mori). Mori is designed with a different (ostensibly more FP-like) take on API: it uses standalone functions instead of methods directly on the values.
109 |
110 | ```js
111 | var state = mori.vector( 1, 2, 3, 4 );
112 |
113 | var newState = mori.assoc(
114 | mori.into( state, Array.from( {length: 39} ) ),
115 | 42,
116 | "meaning of life"
117 | );
118 |
119 | state === newState; // false
120 |
121 | mori.get( state, 2 ); // 3
122 | mori.get( state, 42 ); // undefined
123 |
124 | mori.get( newState, 2 ); // 3
125 | mori.get( newState, 42 ); // "meaning of life"
126 |
127 | mori.toJs( newState ).slice( 1, 3 ); // [2,3]
128 | ```
129 |
130 | Some interesting things to point out about Mori for this example:
131 |
132 | * We're using a `vector` instead of a `list` (as one might assume), mostly because the documentation says it behaves more like we expect JS arrays to be.
133 |
134 | * We cannot just randomly set a position past the end of the vector like we can with JS arrays; that throws an exception. So we have to first "grow" the vector using `mori.into(..)` with an array of the appropriate size of extra slots we want. Once we have a vector with 43 slots (4 + 39), we can set the final slot (position `42`) to the `"meaning of life"` value using the `mori.assoc(..)` method.
135 |
136 | * The intermediate step of creating a larger vector with `mori.into(..)` and then creating another from it with `mori.assoc(..)` might sound inefficient. But the beauty of immutable data structures is that no cloning is going on here. Each time a "change" is made, the new data structure is just tracking the difference from the previous state.
137 |
138 | Mori is heavily inspired by ClojureScript. Its API will be very familiar if you have experience (or currently work in!) that language. Since I don't have that experience, I find the method names a little strange to get used to.
139 |
140 | But I really like the standalone function design instead of methods on values. Mori also has some functions that automatically return regular JS arrays, which is a nice convenience.
141 |
142 | ## Bonus: FPO
143 |
144 | In [Chapter 2, we introduced a pattern](ch2.md/#named-arguments) for dealing with arguments called "named arguments", which in JS means using an object at the call-site to map properties to destructured function parameters:
145 |
146 | ```js
147 | function foo( {x,y} = {} ) {
148 | console.log( x, y );
149 | }
150 |
151 | foo( {
152 | y: 3
153 | } ); // undefined 3
154 | ```
155 |
156 | Then in [Chapter 3, we talked about extending](ch3.md/#order-matters) our ideas of currying and partial application to work with named arguments, like this:
157 |
158 | ```js
159 | function foo({ x, y, z } = {}) {
160 | console.log( `x:${x} y:${y} z:${z}` );
161 | }
162 |
163 | var f1 = curryProps( foo, 3 );
164 |
165 | f1( {y: 2} )( {x: 1} )( {z: 3} );
166 | ```
167 |
168 | One major benefit of this style is being able to pass arguments (even with currying or partial application!) in any order without needing to do `reverseArgs(..)`-style juggling of parameters. Another is being able to omit an optional argument by simply not specifying it, instead of passing an ugly placeholder.
169 |
170 | In my journey learning FP, I've regularly been frustrated by both of those irritations of functions with traditional positional arguments; thus I've really appreciated the named arguments style for addressing those concerns.
171 |
172 | One day, I was musing about with this style of FP coding, and wondered what it would be like if a whole FP library had all its API methods exposed in this style. I started experimenting, showed those experiments to a few FP folks, and got some positive feedback.
173 |
174 | From those experiments, eventually the [FPO](https://github.com/getify/fpo) (pronounced "eff-poh") library was born; FPO stands for FP-with-Objects, in case you were wondering.
175 |
176 | From the documentation:
177 |
178 | ```js
179 | // Ramda's `reduce(..)`
180 | R.reduce(
181 | (acc,v) => acc + v,
182 | 0,
183 | [3,7,9]
184 | ); // 19
185 |
186 | // FPO named-argument method style
187 | FPO.reduce({
188 | arr: [3,7,9],
189 | fn: ({acc,v}) => acc + v
190 | }); // 19
191 | ```
192 |
193 | With traditional library implementations of `reduce(..)` (like Ramda), the initial value parameter is in the middle, and not optional. FPO's `reduce(..)` method can take the arguments in any order, and you can omit the optional initial value if desired.
194 |
195 | As with most other FP libraries, FPO's API methods are automatically loose-curried, so you can not only provide arguments in any order, but specialize the function by providing its arguments over multiple calls:
196 |
197 | ```js
198 | var f = FPO.reduce({ arr: [3,7,9] });
199 |
200 | // later
201 |
202 | f({ fn: ({acc,v}) => acc + v }); // 19
203 | ```
204 |
205 | Lastly, all of FPO's API methods are also exposed using the traditional positional arguments style -- you'll find they're all very similar to Ramda and other libraries -- under the `FPO.std.*` namespace:
206 |
207 | ```js
208 | FPO.std.reduce(
209 | (acc,v) => acc + v,
210 | undefined,
211 | [3,7,9]
212 | ); // 19
213 | ```
214 |
215 | If FPO's named argument form of FP appeals to you, perhaps check out the library and see what you think. It has a full test suite and most of the major FP functionality you'd expect, including everything we covered in this text to get you up and going with Functional-Light JavaScript!
216 |
217 | ## Bonus #2: fasy
218 |
219 | FP iterations (`map(..)`, `filter(..)`, etc.) are almost always modeled as synchronous operations, meaning we eagerly run through all the steps of the iteration immediately. As a matter of fact, other FP patterns like composition and even transducing are also iterations, and are also modeled exactly this way.
220 |
221 | But what happens if one or more of the steps in an iteration needs to complete asynchronously? You might jump to thinking that Observables (see [Chapter 10](ch10.md/#observables)) is the natural answer, but they're not what we need.
222 |
223 | Let me quickly illustrate.
224 |
225 | Imagine you have a list of URLs that represent images you want to load into a web page. The fetching of the images is asynchronous, obviously. So, this isn't going to work quite like you'd hope:
226 |
227 | ```js
228 | var imageURLs = [
229 | "https://some.tld/image1.png",
230 | "https://other.tld/image2.png",
231 | "https://various.tld/image3.png"
232 | ];
233 |
234 | var images = imageURLs.map( fetchImage );
235 | ```
236 |
237 | The `images` array won't contain the images. Depending on the behavior of `fetchImage(..)`, it probably returns a promise for the image object once it finishes downloading. So `images` would now be a list of promises.
238 |
239 | Of course, you could then use `Promise.all(..)` to wait for all those promises to resolve, and then unwrap an array of the image object results at its completion:
240 |
241 | ```js
242 | Promise.all( images )
243 | .then(function allImages(imgObjs){
244 | // ..
245 | });
246 | ```
247 |
248 | Unfortunately, this "trick" only works if you're going to do all the asynchronous steps concurrently (rather than serially, one after the other), and only if the operation is a `map(..)` call as shown. If you want serial asynchrony, or you want to, for example, do a `filter(..)` concurrently, this won't quite work; it's possible, but it's messier.
249 |
250 | And some operations naturally require serial asynchrony, like for example an asynchronous `reduce(..)`, which clearly needs to work left-to-right one at a time; those steps can't be run concurrently and have that operation make any sense.
251 |
252 | As I said, Observables (see [Chapter 10](ch10.md/#observables)) aren't the answer to these kinds of tasks. The reason is, an Observable's coordination of asynchrony is between separate operations, not between steps/iterations at a single level of operation.
253 |
254 | Another way to visualize this distinction is that Observables support "vertical asynchrony", whereas what I'm talking about would be "horizontal asynchrony".
255 |
256 | Consider:
257 |
258 | ```js
259 | var obsv = Rx.Observable.from( [1,2,3,4,5] );
260 |
261 | obsv
262 | .map( x => x * 2 )
263 | .delay( 100 ) // <-- vertical asynchrony
264 | .map( x => x + 1 )
265 | .subscribe( v => console.log );
266 | // {after 100 ms}
267 | // 3
268 | // 5
269 | // 7
270 | // 9
271 | // 11
272 | ```
273 |
274 | If for some reason I wanted to ensure that there was a delay of 100 ms between when `1` was processed by the first `map(..)` and when `2` was processed, that would be the "horizontal asynchrony" I'm referring to. There's not really a clean way to model that.
275 |
276 | And of course, I'm using an arbitrary delay in that description, but in practice that would more likely be serial-asynchrony like an asynchronous reduce, where each step in that reduction iteration could take some time before it completes and lets the next step be processed.
277 |
278 | So, how do we support both serial and concurrent iteration across asynchronous operations?
279 |
280 | **fasy** (pronounced like "Tracy" but with an "f") is a little utility library I built for supporting exactly those kinds of tasks. You can find more information about it [here](https://github.com/getify/fasy).
281 |
282 | To illustrate **fasy**, let's consider a concurrent `map(..)` versus a serial `map(..)`:
283 |
284 | ```js
285 | FA.concurrent.map( fetchImage, imageURLs )
286 | .then( function allImages(imgObjs){
287 | // ..
288 | } );
289 |
290 | FA.serial.map( fetchImage, imageURLs )
291 | .then( function allImages(imgObjs){
292 | // ..
293 | } );
294 | ```
295 |
296 | In both cases, the `then(..)` handler will only be invoked once all the fetches have fully completed. The difference is whether the fetches will all initiate concurrently (aka, "in parallel") or go out one at a time.
297 |
298 | Your instinct might be that concurrent would always be preferable, and while that may be common, it's not always the case.
299 |
300 | For example, what if `fetchImage(..)` maintains a cache of fetched images, and it checks the cache before making the actual network request? What if, in addition to that, the list of `imageURLs` could have duplicates in it? You'd certainly want the first fetch of an image URL to complete (and populate the cache) before doing the check on the duplicate image URL later in the list.
301 |
302 | Again, there will inevitably be cases where concurrent or serial asynchrony will be called for. Asynchronous reductions will always be serial, whereas asynchronous mappings may likely tend to be more concurrent but can also need to be serial in some cases. That's why **fasy** supports all these options.
303 |
304 | Along with Observables, **fasy** will help you extend more FP patterns and principles to your asynchronous operations.
305 |
306 | ## Summary
307 |
308 | JavaScript is not particularly designed as an FP language. However, it does have enough of the basics (like function values, closures, etc.) for us to make it FP-friendly. And the libraries we've examined here will help you do that.
309 |
310 | Armed with the concepts from this book, you're ready to start tackling real-world code. Find a good, comfortable FP library and jump in. Practice, practice, practice!
311 |
312 | So... that's it. I've shared what I have for you, for now. I hereby officially certify you as a "Functional-Light JavaScript" programmer! It's time to close out this "chapter" of our story of learning FP together. But my learning journey still continues; I hope yours does, too!
313 |
--------------------------------------------------------------------------------
/manuscript/foreword.md:
--------------------------------------------------------------------------------
1 | # Functional-Light JavaScript
2 | # Foreword
3 |
4 | It's no secret that I am a Functional Programming nut. I evangelize functional ideas and languages wherever I can, try to read the latest academic papers, study abstract algebra in my spare time…the works. Even in JavaScript, I refuse to write an impure statement, which is what led to writing *Professor Frisby's Mostly Adequate Guide to Functional Programming*. Yep, full on, dogmatic zealot.
5 |
6 | I was not always this way… I was once obsessed with objects. I loved modeling the "real world". I was the inventor of synthetic automatons, tinkering through the night with masterful precision. The creator of sentient puppets, fingers dancing on the keyboard to give them life -- a real 1337 h4x0r Geppetto. Yet, after 5 *solid* years of writing object-oriented code, I was never quite satisfied with the outcome. It just never worked out well for me. I felt like a lousy programmer. I even lost faith that a simple, flexible codebase of decent scale was possible.
7 |
8 | I figured I'd try something different: Functional Programming. I began to dabble with functional ideas in my everyday codebase, and much to my coworkers' dismay, hadn't the slightest clue what I was doing. The code I wrote in those days was awful. Atrocious. Digital sewage. The reason was a lack of clear vision or goal on what I was even trying to accomplish. My Jiminy-Coding-Cricket, if you like, was not there to guide me. It took a long time and a lot of garbage programs to figure out how to FP.
9 |
10 | Now, after all that messy exploration, I feel that pure Functional Programming has delivered on its promise. Readable programs do exist! Reuse does exist! I no longer invent, but rather discover my model. I've become a rogue detective uncovering a vast conspiracy, cork board pinned full of mathematical evidence. A digital-age Cousteau logging the characteristics of this bizarre land in the name of science! It's not perfect and I still have a lot to learn, but I've never been more satisfied in my work and pleased with the outcome.
11 |
12 | Had this book existed when I was starting out, my transition into the world of Functional Programming would have been much easier and less destructive. This book is two-fold (right and left): it will not only teach you how to use various constructs from FP effectively in your daily code, but more importantly, provide you with an aim; guiding principles that will keep you on track.
13 |
14 | You will learn Functional-Light: A paradigm that Kyle has pioneered to enable declarative, Functional Programming while providing balance and interop with the rest of the JavaScript world. You will understand the foundation which pure FP is built upon without having to subscribe to the paradigm in its entirety. You will gain the skills to practice and explore FP without having to rewrite existing code for it to work well together. You can take a step forward in your software career without backtracking and wandering aimlessly as I did years ago. Coworkers and colleagues rejoice!
15 |
16 | Kyle is a great teacher known for his relentless pursuit of the whole picture, leaving no nook or cranny unexplored, yet he maintains an empathy for the learner's plight. His style has resonated with the industry, leveling us all up as a whole. His work has a solid place in JavaScript’s history and most people's bookmarks bar. You are in good hands.
17 |
18 | Functional Programming has many different definitions. A Lisp programmer's definition is vastly different from a Haskell perspective. OCaml's FP bears little resemblance to the paradigm seen in Erlang. You will even find several competing definitions in JavaScript. Yet there is a tie that binds -- some blurry know-it-when-I-see-it definition, much like obscenity (indeed, some do find FP obscene!) and this book certainly captures it. The end result might not be considered idiomatic in certain circles, but the knowledge acquired here directly applies to any flavor of FP.
19 |
20 | This book is a terrific place to begin your FP journey. Take it away, Kyle...
21 |
22 | *-Brian Lonsdorf (@drboolean)*
23 |
--------------------------------------------------------------------------------
/manuscript/images/fig1.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/getify/Functional-Light-JS/40a68612275b23904c7b37abdb724b250bdf75e7/manuscript/images/fig1.png
--------------------------------------------------------------------------------
/manuscript/images/fig10.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/getify/Functional-Light-JS/40a68612275b23904c7b37abdb724b250bdf75e7/manuscript/images/fig10.png
--------------------------------------------------------------------------------
/manuscript/images/fig10.svg:
--------------------------------------------------------------------------------
1 |
2 |
--------------------------------------------------------------------------------
/manuscript/images/fig11.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/getify/Functional-Light-JS/40a68612275b23904c7b37abdb724b250bdf75e7/manuscript/images/fig11.png
--------------------------------------------------------------------------------
/manuscript/images/fig11.svg:
--------------------------------------------------------------------------------
1 |
2 |
--------------------------------------------------------------------------------
/manuscript/images/fig12.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/getify/Functional-Light-JS/40a68612275b23904c7b37abdb724b250bdf75e7/manuscript/images/fig12.png
--------------------------------------------------------------------------------
/manuscript/images/fig12.svg:
--------------------------------------------------------------------------------
1 |
2 |
--------------------------------------------------------------------------------
/manuscript/images/fig13.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/getify/Functional-Light-JS/40a68612275b23904c7b37abdb724b250bdf75e7/manuscript/images/fig13.png
--------------------------------------------------------------------------------
/manuscript/images/fig13.svg:
--------------------------------------------------------------------------------
1 |
2 |
--------------------------------------------------------------------------------
/manuscript/images/fig14.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/getify/Functional-Light-JS/40a68612275b23904c7b37abdb724b250bdf75e7/manuscript/images/fig14.png
--------------------------------------------------------------------------------
/manuscript/images/fig15.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/getify/Functional-Light-JS/40a68612275b23904c7b37abdb724b250bdf75e7/manuscript/images/fig15.png
--------------------------------------------------------------------------------
/manuscript/images/fig15.svg:
--------------------------------------------------------------------------------
1 |
2 |
--------------------------------------------------------------------------------
/manuscript/images/fig16.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/getify/Functional-Light-JS/40a68612275b23904c7b37abdb724b250bdf75e7/manuscript/images/fig16.png
--------------------------------------------------------------------------------
/manuscript/images/fig16.svg:
--------------------------------------------------------------------------------
1 |
2 |
--------------------------------------------------------------------------------
/manuscript/images/fig17.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/getify/Functional-Light-JS/40a68612275b23904c7b37abdb724b250bdf75e7/manuscript/images/fig17.png
--------------------------------------------------------------------------------
/manuscript/images/fig17.svg:
--------------------------------------------------------------------------------
1 |
2 |
--------------------------------------------------------------------------------
/manuscript/images/fig18.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/getify/Functional-Light-JS/40a68612275b23904c7b37abdb724b250bdf75e7/manuscript/images/fig18.png
--------------------------------------------------------------------------------
/manuscript/images/fig18.svg:
--------------------------------------------------------------------------------
1 |
2 |
--------------------------------------------------------------------------------
/manuscript/images/fig19.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/getify/Functional-Light-JS/40a68612275b23904c7b37abdb724b250bdf75e7/manuscript/images/fig19.png
--------------------------------------------------------------------------------
/manuscript/images/fig19.svg:
--------------------------------------------------------------------------------
1 |
2 |
--------------------------------------------------------------------------------
/manuscript/images/fig2.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/getify/Functional-Light-JS/40a68612275b23904c7b37abdb724b250bdf75e7/manuscript/images/fig2.png
--------------------------------------------------------------------------------
/manuscript/images/fig3.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/getify/Functional-Light-JS/40a68612275b23904c7b37abdb724b250bdf75e7/manuscript/images/fig3.png
--------------------------------------------------------------------------------
/manuscript/images/fig3.svg:
--------------------------------------------------------------------------------
1 |
2 |
--------------------------------------------------------------------------------
/manuscript/images/fig4.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/getify/Functional-Light-JS/40a68612275b23904c7b37abdb724b250bdf75e7/manuscript/images/fig4.png
--------------------------------------------------------------------------------
/manuscript/images/fig4.svg:
--------------------------------------------------------------------------------
1 |
2 |
--------------------------------------------------------------------------------
/manuscript/images/fig5.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/getify/Functional-Light-JS/40a68612275b23904c7b37abdb724b250bdf75e7/manuscript/images/fig5.png
--------------------------------------------------------------------------------
/manuscript/images/fig5.svg:
--------------------------------------------------------------------------------
1 |
2 |
--------------------------------------------------------------------------------
/manuscript/images/fig6.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/getify/Functional-Light-JS/40a68612275b23904c7b37abdb724b250bdf75e7/manuscript/images/fig6.png
--------------------------------------------------------------------------------
/manuscript/images/fig6.svg:
--------------------------------------------------------------------------------
1 |
2 |
--------------------------------------------------------------------------------
/manuscript/images/fig7.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/getify/Functional-Light-JS/40a68612275b23904c7b37abdb724b250bdf75e7/manuscript/images/fig7.png
--------------------------------------------------------------------------------
/manuscript/images/fig7.svg:
--------------------------------------------------------------------------------
1 |
2 |
--------------------------------------------------------------------------------
/manuscript/images/fig8.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/getify/Functional-Light-JS/40a68612275b23904c7b37abdb724b250bdf75e7/manuscript/images/fig8.png
--------------------------------------------------------------------------------
/manuscript/images/fig8.svg:
--------------------------------------------------------------------------------
1 |
2 |
--------------------------------------------------------------------------------
/manuscript/images/fig9.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/getify/Functional-Light-JS/40a68612275b23904c7b37abdb724b250bdf75e7/manuscript/images/fig9.png
--------------------------------------------------------------------------------
/manuscript/images/fig9.svg:
--------------------------------------------------------------------------------
1 |
2 |
--------------------------------------------------------------------------------
/manuscript/images/marketing/back-cover-hd.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/getify/Functional-Light-JS/40a68612275b23904c7b37abdb724b250bdf75e7/manuscript/images/marketing/back-cover-hd.png
--------------------------------------------------------------------------------
/manuscript/images/marketing/front-cover-hd.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/getify/Functional-Light-JS/40a68612275b23904c7b37abdb724b250bdf75e7/manuscript/images/marketing/front-cover-hd.png
--------------------------------------------------------------------------------
/manuscript/images/marketing/front-cover-hd.tiff:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/getify/Functional-Light-JS/40a68612275b23904c7b37abdb724b250bdf75e7/manuscript/images/marketing/front-cover-hd.tiff
--------------------------------------------------------------------------------
/manuscript/images/marketing/front-cover-sd.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/getify/Functional-Light-JS/40a68612275b23904c7b37abdb724b250bdf75e7/manuscript/images/marketing/front-cover-sd.png
--------------------------------------------------------------------------------
/manuscript/images/marketing/front-cover-small.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/getify/Functional-Light-JS/40a68612275b23904c7b37abdb724b250bdf75e7/manuscript/images/marketing/front-cover-small.png
--------------------------------------------------------------------------------
/manuscript/images/marketing/print-book-cover.pdf:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/getify/Functional-Light-JS/40a68612275b23904c7b37abdb724b250bdf75e7/manuscript/images/marketing/print-book-cover.pdf
--------------------------------------------------------------------------------
/manuscript/images/marketing/print-book-cover.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/getify/Functional-Light-JS/40a68612275b23904c7b37abdb724b250bdf75e7/manuscript/images/marketing/print-book-cover.png
--------------------------------------------------------------------------------
/manuscript/images/marketing/social-avatar.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/getify/Functional-Light-JS/40a68612275b23904c7b37abdb724b250bdf75e7/manuscript/images/marketing/social-avatar.png
--------------------------------------------------------------------------------
/manuscript/images/marketing/social-header.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/getify/Functional-Light-JS/40a68612275b23904c7b37abdb724b250bdf75e7/manuscript/images/marketing/social-header.png
--------------------------------------------------------------------------------
/manuscript/preface.md:
--------------------------------------------------------------------------------
1 | # Functional-Light JavaScript
2 | # Preface
3 |
4 | > *A monad is just a monoid in the category of endofunctors.*
5 |
6 | Did I just lose you? Don't worry, I'd be lost, too! All those terms that only mean something to the already-initiated in Functional Programming™ (FP) are just jumbled nonsense to many of the rest of us.
7 |
8 | This book is not going to teach you what those words mean. If that's what you're looking for, keep looking. In fact, there are already plenty of great books that teach FP the *right way*, from the top-down. Those words have important meanings and if you formally study FP in-depth, you'll absolutely want to get familiar with them.
9 |
10 | But this book is going to approach the topic quite differently. I'm going to present fundamental FP concepts from the ground-up, with fewer special or non-intuitive terms than most approaches to FP. We'll try to take a practical approach to each principle rather than a purely academic angle. **There will be terms**, no doubt. But we'll be careful and deliberate about introducing them and explaining why they're important.
11 |
12 | Sadly, I am not a card-carrying member of the FP Cool Kids Club. I've never been formally taught anything about FP. And though I have a CS academic background and I am decent at math, mathematical notation is not how my brain understands programming. I have never written a line of Scheme, Clojure, or Haskell. I'm not an old-school Lisp'r.
13 |
14 | I *have* attended countless conference talks about FP, each one with the desperate clinging hope that finally, *this time* would be the time I understood what this whole functional programming mysticism is all about. And each time, I came away frustrated and reminded that those terms got all mixed up in my head and I had no idea if or what I learned. Maybe I learned things. But I couldn't figure out what those things were for the longest time.
15 |
16 | Little by little, across those various exposures, I teased out bits and pieces of important concepts that seem to just come all too naturally to the formal FPer. I learned them slowly and I learned them pragmatically and experientially, not academically with appropriate terminology. Have you ever known a thing for a long time, and only later found out it had a specific name you never knew!?
17 |
18 | Maybe you're like me; I heard terms such as "map-reduce" around industry segments like "big data" for years with no real idea what they were. Eventually I learned what the `map(..)` function did -- all long before I had any idea that list operations were a cornerstone of the FPer path and what makes them so important. I knew what *map* was long before I ever knew it was called `map(..)`.
19 |
20 | Eventually I began to gather all these tidbits of understanding into what I now call "Functional-Light Programming" (FLP).
21 |
22 | ## Mission
23 |
24 | But why is it so important for you to learn functional programming, even the light form?
25 |
26 | I've come to believe something very deeply in recent years, so much so you could *almost* call it a religious belief. I believe that programming is fundamentally about humans, not about code. I believe that code is first and foremost a means of human communication, and only as a *side effect* (hear my self-referential chuckle) does it instruct the computer.
27 |
28 | The way I see it, functional programming is at its heart about using patterns in your code that are well-known, understandable, *and* proven to keep away the mistakes that make code harder to understand. In that view, FP -- or, ahem, FLP! -- might be one of the most important collections of tools any developer could acquire.
29 |
30 | > The curse of the monad is that... once you understand... you lose the ability to explain it to anyone else.
31 | >
32 | > Douglas Crockford 2012 "Monads and Gonads"
33 | >
34 | > https://www.youtube.com/watch?v=dkZFtimgAcM
35 |
36 | I hope this book "Maybe" breaks the spirit of that curse, even though we won't talk about "monads" until the very end in the appendices.
37 |
38 | The formal FPer will often assert that the *real value* of FP is in using it essentially 100%: it's an all-or-nothing proposition. The belief is that if you use FP in one part of your program but not in another, the whole program is polluted by the non-FP stuff and therefore suffers enough that the FP was probably not worth it.
39 |
40 | I'll say unequivocally: **I think that absolutism is bogus**. That's as silly to me as suggesting that this book is only good if I use perfect grammar and active voice throughout; if I make any mistakes, it degrades the entire book's quality. Nonsense.
41 |
42 | The better I am at writing in a clear, consistent voice, the better your reading experience will be. But I'm not a 100% perfect author. Some parts will be better written than others. The parts where I can still improve are not going to invalidate the other parts of this book which are useful.
43 |
44 | And so it goes with our code. The more you can apply these principles to more parts of your code, the better your code will be. Use them well 25% of the time, and you'll get some good benefit. Use them 80% of the time, and you'll see even more benefit.
45 |
46 | With perhaps a few exceptions, I don't think you'll find many absolutes in this text. We'll instead talk about aspirations, goals, principles to strive for. We'll talk about balance and pragmatism and trade-offs.
47 |
48 | Welcome to this journey into the most useful and practical foundations of FP. We both have plenty to learn!
49 |
--------------------------------------------------------------------------------