I'm a software engineer working as a full-stack developer using JavaScript, Node.js, and React. I write about my experiences in tech, tutorials, and share helpful hints.
The promise of functional programming rarely matches reality. Some of the supposed benefits of it are that programs are more concise and easier to understand (or "easier to reason about"), but I have found the opposite to be true.
In the JavaScript world, I feel there is an overuse of the map, filter, and reduce functions and the belief that less code = concise code. This leads to these being used simply for the looping aspect of them. I think that in order for code to be concise, it needs to provide a clear meaning, but it often does not happen when those functions are used.
These are not well-named and easy to understand functions due to their dynamic nature. The function names themselves are ambiguous, which is expected since they are built-in utilities.
These functions take a function as an argument which applies that operation to the data. Most times the function is declared right alongside the call to map, filter, and reduce. This means that there is no descriptive function to rely on to aid in your understanding, at first glance, you know there is a loop and some action being applied to the items. To understand further, you have to parse every line of code.
If these are used all over the code and do not have any descriptive names, it is harder to understand the code.
See the examples below. It is a contrived example, so it isn't that complex and you could argue that pulling out the function is overkill, but I am just showing the difference between the two methods. If the function that is passed into map, filter, and reduce gets more complex, the harder code becomes to parse and understand. The abundance of map, filter, and reduce being used as a "functional" for-loop can harm the readability of code.
letarray=[1,2,3,4,5];// Function is defined alongside the map, it is used once.letnewArray=array.map(number=>number*4);
The example below shows that logic being pulled out into a named function. I believe this is easier to read and understand. I think this is more in line with what is referred to as functional programming.
// This function can be tucked away somewhere and allows for it to be re-used.functionmultiplyBy(scale){returnfunction(number){returnnumber*scale;}}
letarray=[1,2,3,4,5];// Call map with a descriptive function passed in.letnewArray=array.map(multiplyBy(4));
I think strict functional programming in Javascript doesn't make sense. The lack of built-in currying and parentheses on function calls makes it awkward to write functional code. But, I think applying some ideas from it is useful. The most helpful thing I take from fp in Javascript is keeping functions as pure as possible. I don't mean not using for loops and mutability inside the function, but from the outside, nothing gets changed. Like returning a new array instead of modifying the one passed to it.
I'm a software engineer working as a full-stack developer using JavaScript, Node.js, and React. I write about my experiences in tech, tutorials, and share helpful hints.
Yeah, I agree. Writing pure functions and making an explicit choice to introduce a side-effect is a good concept/practice to incorporate into any code. I also like the ideas of immutability and referential transparency, since those are widely applicable.
// , “It is not so important to be serious as it is to be serious about the important things. The monkey wears an expression of seriousness... but the monkey is serious because he itches."(No/No)
Well, today I learned. "This set of functional expressions is referentially transparent" seems like yet another way of saying "this bit o' code has got no side effects," but with more syllables!
Referential transparency actually means that the reference of an object doesn't matter. Only the value is important. That basically means that even items in different places in memory that have the same value are considered the same.
// , “It is not so important to be serious as it is to be serious about the important things. The monkey wears an expression of seriousness... but the monkey is serious because he itches."(No/No)
Actually, according to Willard Quine[1], "a mode of containment φ is referentially transparent if, whenever an occurrence of a singular term t is purely referential in a term or sentence ψ(t), it is purely referential also in the containing term or sentence φ(ψ(t))," as in the following example:
(12) Ralph believes that the man in the brown hat is a spy.
(13) Ralph does not believe that the man seen at the beach is a spy.
The main in the blue hat = the man seen at the beach = Bernie Sanders
t = ‘the man in the blue hat’
ψ(t) = ‘the man in the blue hat is a spy’
ϕ(ψ(t)) = ‘Ralph believes that the man in the blue hat is a spy’.
I need to get more practice drawing lil tridents on whiteboards.
[1]Although ultimately, like many obtuse concepts in CS, we can safely blame Whitehead and Bertram.
Hmm, well I was talking about referential transparency as it relates to functional programming, as opposed to logic, I guess. I hadn't seen that definition before, it's pretty interesting.
When you start to go down the road of transducers, that's when you start to realize it might've been better to have just stuck to a for loop.
And while loops are highly underrated. I've trampolined enough recursive functions to know it's better to just use a while loop and reduce overall complexity-- computational as well as mental overhead.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The promise of functional programming rarely matches reality. Some of the supposed benefits of it are that programs are more concise and easier to understand (or "easier to reason about"), but I have found the opposite to be true.
In the JavaScript world, I feel there is an overuse of the
map,filter, andreducefunctions and the belief that less code = concise code. This leads to these being used simply for the looping aspect of them. I think that in order for code to be concise, it needs to provide a clear meaning, but it often does not happen when those functions are used.map,filter, andreduce. This means that there is no descriptive function to rely on to aid in your understanding, at first glance, you know there is a loop and some action being applied to the items. To understand further, you have to parse every line of code.See the examples below. It is a contrived example, so it isn't that complex and you could argue that pulling out the function is overkill, but I am just showing the difference between the two methods. If the function that is passed into
map,filter, andreducegets more complex, the harder code becomes to parse and understand. The abundance ofmap,filter, andreducebeing used as a "functional" for-loop can harm the readability of code.The example below shows that logic being pulled out into a named function. I believe this is easier to read and understand. I think this is more in line with what is referred to as functional programming.
I think strict functional programming in Javascript doesn't make sense. The lack of built-in currying and parentheses on function calls makes it awkward to write functional code. But, I think applying some ideas from it is useful. The most helpful thing I take from fp in Javascript is keeping functions as pure as possible. I don't mean not using for loops and mutability inside the function, but from the outside, nothing gets changed. Like returning a new array instead of modifying the one passed to it.
Yeah, I agree. Writing pure functions and making an explicit choice to introduce a side-effect is a good concept/practice to incorporate into any code. I also like the ideas of immutability and referential transparency, since those are widely applicable.
Well, today I learned. "This set of functional expressions is referentially transparent" seems like yet another way of saying "this bit o' code has got no side effects," but with more syllables!
More syllables is always better.
Referential transparency actually means that the reference of an object doesn't matter. Only the value is important. That basically means that even items in different places in memory that have the same value are considered the same.
Actually, according to Willard Quine[1], "a mode of containment φ is referentially transparent if, whenever an occurrence of a singular term t is purely referential in a term or sentence ψ(t), it is purely referential also in the containing term or sentence φ(ψ(t))," as in the following example:
I need to get more practice drawing lil tridents on whiteboards.
[1]Although ultimately, like many obtuse concepts in CS, we can safely blame Whitehead and Bertram.
Hmm, well I was talking about referential transparency as it relates to functional programming, as opposed to logic, I guess. I hadn't seen that definition before, it's pretty interesting.
When you start to go down the road of transducers, that's when you start to realize it might've been better to have just stuck to a for loop.
And while loops are highly underrated. I've trampolined enough recursive functions to know it's better to just use a while loop and reduce overall complexity-- computational as well as mental overhead.