6 ms·

I'm relatively new to JS and functional programming and I've found that functional programming has been extremely difficult for me to grasp. I eventually figure

I'm relatively new to JS and functional programming and I've found that functional programming has been extremely difficult for me to grasp. I eventually figure it out (so far) but it takes me forever to read through code. You return a function that has a function in that that has another function in that and so on. Is this normal?

dccoolgai 13y ago
I find most JS written functionally (at least if it's done the right way) to be a lot easier to follow if you think of each functional "step" in the chain like columns in a spreadsheet. E.g. when I see something like _(array).filter(...).map(...).reject(...).reduce() I like to think of taking a value and following it the way you would across a spreadsheet and think of filter, map and reject as "columns". I don't know if that will help, but it does for me.
- drewblaisdell 13y ago
  > E.g. when I see something like _(array).filter(...).map(...).reject(...).reduce() I like to think of taking a value and following it the way you would across a spreadsheet and think of filter, map and reject as "columns". This is the practical use of functional Javascript methods after they are written, though. Following the code in the filter/map/reject/etc functions themselves is a bit more difficult.
mrsaint 13y ago
Yes, it's very popular with JS to make code more modular. Remember that, although JavaScript is a object-oriented language, it isn't a class-based language - it's a prototype-based language. The best way to grasp the idea is by following various code examples (and how and why they were implemented that way). Also, I found Douglas Crockford's video presentations on JS _extremely_ helpful. I have a list of them here: https://www.zeitgeist.se/2014/03/26/list-of-helpful-javascript-resources/ https://www.zeitgeist.se/2014/03/26/list-of-helpful-javascri...
lrichardson 13y ago
Yes and no. Some of this is that JavaScript is just not very well equipped to do functional programming. For instance, the nesting of functions in JavaScript is not only verbose to write, it also introduces a lot of noise in the code. One pretty simple/obvious setback for JavaScript is that declaring an anonymous function (or a lambda) entails quite a few characters. In ES6, [this will change with the introduction of "Arrow Functions"][2], but that's not going to be a cure-all by any means. Languages geared more towards the functional edge will handle things like curried higher order functions almost without you realizing it. For instance, taking an excerpt from my next post in the series (still unpublished): var uncurried = function (a, b, c) { // do something with a, b, and c }; var curried = function(a) { return function (b) { return function (c) { // do something with a, b, and c }; }; }; There we have two ternary functions (3 arguments), but the first one is uncurried (how you would expect it in javascript), and the second one is manually written in a curried fashion. Some programming languages, such as Haskell and OCaml, have function currying built into the language. What that means is that, technically, every function is a function of one argument, and one argument only. Syntactically, however, they may make this restriction almost unnoticable. For instance, in OCaml, one could write the two functions above like: let uncurried = fun a b c -> // (* do something with a, b, c *) let curried = fun a -> fun b -> fun c -> // (* do something with a, b, c *) The difference, however, is that in OCaml these are exactly the same thing. In OCaml, no functions have multiple arguments. However, invoking curried functions syntactically looks the same as what one would expect invoking a function with multiple arguments would be. To call the functions above we would write: uncurried foo bar baz curried foo bar baz Whereas in JavaScript, we have the obvious difference: uncurried(foo, bar, baz); curried(foo)(bar)(baz); Many would argue that the readability of the former is much better than the latter. --- Anyway, what I am trying to build up to in this series is building a set of tools to make writing code like this a little more fluid in JavaScript than native JavaScript would allow. This goes back to my example in [Part 1][1], where I show an underscore example: var firstTwoLetters = function(words){ return _.map(words, function(word){ return _.first(word, 2); }); }; Which, the exact same thing can be represented "my way" with: var firstTwoLetters = map(first(2)); I would argue that this is much more readable, and perhaps you would agree? [1]: http://tech.pro/tutorial/1953/functional-javascript-part-1-introduction [2]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/arrow_functions
taternuts 13y ago
I think so. It takes a while for it to `click`, but when it does you'll really start to enjoy it.

dccoolgai 13y ago

I find most JS written functionally (at least if it's done the right way) to be a lot easier to follow if you think of each functional "step" in the chain like columns in a spreadsheet. E.g. when I see something like _(array).filter(...).map(...).reject(...).reduce() I like to think of taking a value and following it the way you would across a spreadsheet and think of filter, map and reject as "columns". I don't know if that will help, but it does for me.

drewblaisdell 13y ago
> E.g. when I see something like _(array).filter(...).map(...).reject(...).reduce() I like to think of taking a value and following it the way you would across a spreadsheet and think of filter, map and reject as "columns". This is the practical use of functional Javascript methods after they are written, though. Following the code in the filter/map/reject/etc functions themselves is a bit more difficult.

mrsaint 13y ago

Yes, it's very popular with JS to make code more modular. Remember that, although JavaScript is a object-oriented language, it isn't a class-based language - it's a prototype-based language. The best way to grasp the idea is by following various code examples (and how and why they were implemented that way). Also, I found Douglas Crockford's video presentations on JS _extremely_ helpful. I have a list of them here: https://www.zeitgeist.se/2014/03/26/list-of-helpful-javascript-resources/ https://www.zeitgeist.se/2014/03/26/list-of-helpful-javascri...

lrichardson 13y ago

Yes and no. Some of this is that JavaScript is just not very well equipped to do functional programming. For instance, the nesting of functions in JavaScript is not only verbose to write, it also introduces a lot of noise in the code. One pretty simple/obvious setback for JavaScript is that declaring an anonymous function (or a lambda) entails quite a few characters. In ES6, [this will change with the introduction of "Arrow Functions"][2], but that's not going to be a cure-all by any means. Languages geared more towards the functional edge will handle things like curried higher order functions almost without you realizing it. For instance, taking an excerpt from my next post in the series (still unpublished): var uncurried = function (a, b, c) { // do something with a, b, and c }; var curried = function(a) { return function (b) { return function (c) { // do something with a, b, and c }; }; }; There we have two ternary functions (3 arguments), but the first one is uncurried (how you would expect it in javascript), and the second one is manually written in a curried fashion. Some programming languages, such as Haskell and OCaml, have function currying built into the language. What that means is that, technically, every function is a function of one argument, and one argument only. Syntactically, however, they may make this restriction almost unnoticable. For instance, in OCaml, one could write the two functions above like: let uncurried = fun a b c -> // (* do something with a, b, c *) let curried = fun a -> fun b -> fun c -> // (* do something with a, b, c *) The difference, however, is that in OCaml these are exactly the same thing. In OCaml, no functions have multiple arguments. However, invoking curried functions syntactically looks the same as what one would expect invoking a function with multiple arguments would be. To call the functions above we would write: uncurried foo bar baz curried foo bar baz Whereas in JavaScript, we have the obvious difference: uncurried(foo, bar, baz); curried(foo)(bar)(baz); Many would argue that the readability of the former is much better than the latter. --- Anyway, what I am trying to build up to in this series is building a set of tools to make writing code like this a little more fluid in JavaScript than native JavaScript would allow. This goes back to my example in [Part 1][1], where I show an underscore example: var firstTwoLetters = function(words){ return _.map(words, function(word){ return _.first(word, 2); }); }; Which, the exact same thing can be represented "my way" with: var firstTwoLetters = map(first(2)); I would argue that this is much more readable, and perhaps you would agree? [1]: http://tech.pro/tutorial/1953/functional-javascript-part-1-introduction [2]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/arrow_functions

taternuts 13y ago

I think so. It takes a while for it to `click`, but when it does you'll really start to enjoy it.