This week's book giveaway is in the Android forum.
We're giving away four copies of Head First Android and have David & Dawn Griffiths on-line!
See this thread for details.
Win a copy of Head First Android this week in the Android forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Rob Spoor
  • Bear Bibeault
Saloon Keepers:
  • Jesse Silverman
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • Al Hobbs
  • salvin francis

Tip: Processing values using lists

 
Author
Posts: 22
5
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Say you define an operation like:



Easy to use when you have two numbers, right? But what if you want to have a bunch of numbers that you add a single number to? You could:



But that's ugly and awfully imperative. Instead, we can use a built in method on arrays called `map(..)`:



Cool!

But we can do better than that. Let's pull out that function expression:



Notice how I only pass a reference to `add42`, but I don't call it like `add42()`. That's super important. `map(..)` will call `add42(..)` for us.

But, instead of defining that function manually, we could use another FP technique, closure, to make a utility that produces a composition on top of `sum(..)`:



The `makeAdder(..)` function makes and returns a new function. The new function that's returned is what we assign to the variable `add42`. That function has a closure over the variable `y`, which we pass in as `42`. It's then called by `map(..)` once for each value in the list, which will be the `x` parameter. Now that we have an `x` and a `y`, the `sum(x,y)` call computes the new value for each item in the list.

For our last trick, let's say we wanted to first add that `42` to all numbers in our list, and then sum all the numbers to get one big number. We can use another array method `reduce(..)` for that. `reduce(..)` takes a function similar to `map(..)`, but *that* function needs two values. The first parameter is the running total, and the second parameter is the current value in the list. In other words, it might be used like this:



Also, look at that `0` as the second argument to `reduce(..)`. That's the initial value to start the reduction with. But does that function signature look familiar? It's exactly the same as the `sum(..)` we already defined. So we could just call `reduce( sum, 0 )`. Next, we'll observe that since `map(..)` is returning a new array, we can *chain* the `reduce(..)` call directly off the `map(..)` call. Putting all this together, we have:



Processing values in lists is a lot more fun when we learn tools like `map(..)` and `reduce(..)`, and function closure. Happy coding!
 
Bartender
Posts: 2968
6
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
While I immediately loved the fact that I could apply functional programming (FP) techniques in JavaScript but as a personal experience it became clear to me while working through Functional Programming in JavaScript with libraries such as lodash and ramda that ultimately JavaScript's imperative bits prevented me from ever getting into the mindset of thinking functionally. I am going to have to actively use a functional language to start thinking functionally - which initiated
my detour to Clojure(Script) (Elm would have been another option).


My ultimate hope is that this excursion will enable me to apply FP techniques much more effectively in the imperative space - "more effectively" than just picking up an FP trick here and there - though we all have to start somewhere. Interestingly is was the ever-growing JavaScript tooling pipeline that desensitized me to ClojureScript's upfront tooling - most of us use transpilers already to get tomorrow's JavaScript features in today's browsers; these transpilers will eventually output WebAssembly which will likely also be accompanied by a proliferation of client side languages. But for some time to come it will remain important to maintain a competent handle on JavaScript itself to be able to leverage the already existing and evolving codebase effectively.
 
Kyle Simpson
Author
Posts: 22
5
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yeah, JS is not actually a FP language. But I do think you can *think functionally* in parts of your program, which helps improve things, even if you don't have an entirely pure FP approach to all the code.

I taught a 3hr Frontend Masters course called "Functional-Lite Programming" which tries to sift through the bits of FP theory/concept that we can easily apply to JS without getting into all the terminology and dogma. I encourage devs to explore this more fully, as I've found that it really helps to be 50% FP than 0% -- 100% is not necessary to improve code.

https://frontendmasters.com/courses/functional-js-lite/
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic