The functional paradigm fundamentally alters the way the entire program is constructed, and you can do it without map reduce or filter. You really need to play with haskell or lisp to see the light.
Map and reduce are more clear as to intent for the subset of what a for loop does that they, together, do, and that clarity and limitation has practical advantages for things like parallelization and distribution, which is why MapReduce is an important distributed computation model and ForLoop isn't.
> The functional paradigm fundamentally alters the way the entire program is constructed
Programming paradigms are useful at levels other than “entire program”, which is the reason many modern languages are multiparadigm.
>Programming paradigms are useful at levels other than “entire program”, which is the reason many modern languages are multiparadigm.
Again I agree with this but your missing the point. To be a multiparadigm language the language needs to provide syntax for switching between muteability and immuteability. The original poster is not talking about this, he is talking about higher order functions which is an entirely different beast.
I would even argue that map filter and reduce aren't even part of any paradigm: functional or imperative as all of these functions can be implemented both using recursion and a for loop... The for loop however is strictly an imperative programming concept.
and how many of these "parallelized and distributed" map and reduces actually exist out in the wilderness of javascript code ?
For one thing, because it's more work to convince ourselves that a loop is correct, than that a couple of canned list processing functions are used correctly.
So? They abstract out common patterns. You could write the great majority of functions' implementations inline instead of calling them.
I originally stated that for loops and HO functions are equivalent and this entire thread consists of people disputing that statement. You're the one dude telling me that what I'm saying is old news and totally obvious. I'm not sure if you realize it, but we're on the same side.
As a side note, the equivalency between recursion and for loops is not limited to tail recursion. Recursion itself in all computing languages is implemented using a stack. So all recursion is equivalent to a for loop + a stack. This has been long known ever since programming languages utilized something called a call stack.
> I originally stated that for loops and HO functions are equivalent and this entire thread consists of people disputing that statement.
My read of the thread is that your posts seem to be going beyond saying they're functionally equivalent, and saying that there's no value in using reduce and friends because they're functionally equivalent.
Most of your posts aren't addressing that tail recursion is a form of iteration (yes, or alternately that recursion can be done without a lexically recursive function) and that map/reduce/etc can be implemented in terms of recursion or for loops; you're contrasting the HOF's with for loops like they're competitors. The HOF's are an abstraction over iteration, whatever syntax was used to write that iteration.
Most of the responses aren't disputing that they accomplish the same thing, they're just saying that there is value in using the HOF's. You would be getting the same kinds of replies if you were insisting there's no difference between HOF's and direct recursion.
> You're the one dude
I'm not a dude.
I quote myself: > it's just a bit cooler or convenient to use map in place of a for
>Most of your posts aren't addressing that tail recursion is a form of iteration (yes, or alternately that recursion can be done without a lexically recursive function)
Why should I address this? This is not the main point. Even recursion without a tail can be considered a form of iteration. But how is this the topic of conversation? We are talking about the equivalency between HOFs and loops. Why are you bringing up the fixed point combinator?
>you're contrasting the HOF's with for loops like they're competitors. The HOF's are an abstraction over iteration, whatever syntax was used to write that iteration.
No I'm not! Not at all! I'm saying HOFs and LOOPS are ultimately the same thing!!! and thus when you use them in code you are not ultimately changing the paradigm of your programming to functional. The overall structure of your program is still imperative.
>You would be getting the same kinds of replies if you were insisting there's no difference between HOF's and direct recursion.
There's not much of a difference, I quote again: >> it's just a bit cooler or convenient to use map in place of ...
I didn't mean the fixed point combinator, I was responding to "So all recursion is equivalent to a for loop + a stack." A recursive algorithm implemented with a for loop and a stack instead of function calls and the processor stack isn't equivalent to recursion, it is recursion, just not the lexical kind. This is just semantics and we agree with each other.
> Why should I address this? We are talking about the equivalency between HOFs and loops.
Because for loops are equivalent to recursive procedures, not to map and reduce; map and reduce are much more restricted.
You can implement a for loop using pure function application, and you can implement recursive pure functions using a for loop. Map and reduce live on a higher abstraction level, and because the two lower level strategies are equivalent, which one is used is irrelevant. Saying that they're not functional because they can be implemented with a for loop makes as much sense as saying that a for loop is functional because it can be implemented with pure function application.
To me, a for loop is an imperative construct, and map and reduce are functional constructs, regardless of how any of them are implemented.
Well if the map is implemented using muteable variables then it is not a functional construct is it? If your entire program utilizes maps and filters and folds but is muteable then it is not a functional construct. Here is the definition of a functional language according to Wikipedia:
"In computer science, functional programming is a programming paradigm—a style of building the structure and elements of computer programs—that treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data. It is a declarative programming paradigm, which means programming is done with expressions[1] or declarations[2] instead of statements."
Also, why would you prefer an imperative construct over different kinds of folds?
Why are maps and folds so prevalent in functional programming? Because immutability and imperativeness render the concept of a for loop to be non-existent.
Try to use a for loop with all const variables and no IO... your for loop will not be able to do any meaningful change to the state of your program.
You realize that reduce, filter and map are all higher order functions that can be implemented with for loops?
Are you indicating in your latest response that I am correct and your original statement is incorrect? You seem to be going in on a tangent... Where is this going?
Most of the traditionally non-functional languages don't support loops as expressions.
Here's my main point. There is no meaningful change to your imperative program when you replace for loops with maps. The core structure of your code is exactly the same. What you have introduced is a convenience aka sugar.
If you were to truly do functional programming the architecture of your entire program will be drastically different from imperative code... To counter the posters original statement: There is a gigantic difference between just using map and reduce in your imperative javascript code vs. actually writing a functional program... It is not a trivial difference.
I feel many people who understand javascript fp libraries like underscore think they know functional programming when all their really doing is sprinkling map and reduce all over their imperative code. You guys don't get it yet, and you'll never get it if you keep coding in javascript. The difference is night and day, it's like SQL vs python.