11 ms·

> People say they're doing FP in JavaScript. What they mean is they sprinkle reduce and map around and they use some pure functions. There's a lot of value in t

> People say they're doing FP in JavaScript. What they mean is they sprinkle reduce and map around and they use some pure functions. There's a lot of value in that. But otherwise their code is procedural. They have not learned the paradigm, only the features. Yeah, but that's probably okay. I feel like there's a strong implication here that following the paradigm has inherent value but I'm not sure why I should think that's the case. Basically, I agree with the claim above that "there's a lot of value in that." :)

crimsonalucard 9y ago
I disagree with you. Map and reduce achieve the same result as a for loop so why not use a for loop? The end result is the same it's just a bit cooler or convenient to use map in place of a for loop, that's the only reason why you would use one instead of the other in a imperative program. 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.
- fnord123 9y ago
  The result (return value) of a map is the list of results. A for loop has no result. So building up generic stream operators ((reduce (filter (map ...))) can't be done using for loops. It needs higher order functions or iterators.
  - gaius 9y ago
    Additionally the for construct implies that you want something done in a certain order, map implies all operations are independent and the order can be decided by the runtime itself. A program written in a language supporting map (which requires first class functions) can be trivially parallelised, whereas every for loop must be carefully analysed first.
    - crimsonalucard 9y ago
      Then replace the for loop with a parallel construct that's imperative. In terms of the language itself, map, reduce and filter are just sugar... different ways to loop through collections. Using one does not mean you are using FP, using immutability in java means that you are. That is the difference.
      - steinuil 9y ago
        Actually, for loops in languages like Ruby and OCaml are just syntactic sugar for map. Also, why would you prefer an imperative construct over different kinds of folds?
        crimsonalucard 9y ago
        I don't. My point is, it's all sugar, so in a sense it's the same thing when you're doing imperative programming. Whether you use a map or a for loop in your imperative code the structure of your program remains the same, the only difference is sugar... This is my point. 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.
  - crimsonalucard 9y ago
    Obviously the for loop either transforms a list, or builds up a new list via an accumulator. That accumulator or the original list is your return value that you can imperatively pipe into other for loops. You realize that reduce, filter and map are all higher order functions that can be implemented with for loops?
    - fnord123 9y ago
      Yes because for loops are syntax sugar around gotos. It all boils down to the same thing. However maps can be determined to be turing incomplete if the mapped function has no function calls and no loops and if the input list is not infinite. This means that it's suitable for a wide range of dsls that would like to know if programs are susceptible to the halting problem (e.g. bpf -which doesnt have maps but I think it could...)
      - crimsonalucard 9y ago
        You just said a for loop returns no results. I responded saying that it can via an accumulator or mutating the original list... 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?
        mclehman 9y ago
        Returning a result and modifying a data structure you've decided to use as an accumulator are two different things. Modifying the original structure is even more different. Most of the traditionally non-functional languages don't support loops as expressions.
        crimsonalucard 9y ago
        Yes, I get what your saying, but I can implement the map filter and reduce abstractions with a for loop using this accumulator pattern or pass in the parameter by value (aka copy) then modify the original structure. If I can implement MAP using a FOR loop then they are relatively the same thing as I can just replace a MAP with it's FOR loop definition and get the same result. 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.
- dragonwriter 9y ago
  > Map and reduce achieve the same result as a for loop so why not use a for loop? 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.
  - crimsonalucard 9y ago
    Your first statement is correct but it's diverging away from my main point. >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.
  - jcelerier 9y ago
    > and that clarity and limitation has practical advantages for things like parallelization and distribution, and how many of these "parallelized and distributed" map and reduces actually exist out in the wilderness of javascript code ?
- kazinator 9y ago
  > Map and reduce achieve the same result as a for loop so why not use a for loop? 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.
  - crimsonalucard 9y ago
    The canned list processing functions can be implemented with a for loop.
    - kbp 9y ago
      > The canned list processing functions can be implemented with a for loop. So? They abstract out common patterns. You could write the great majority of functions' implementations inline instead of calling them.
      - crimsonalucard 9y ago
        So if the implementation of a HO function is a for loop then then an HO function and a for loop are equivalent. Thus proving my original point: It's the same thing. Using HO functions in an imperative language is not much different from using a for loop, it's all sugar.
        kbp 9y ago
        Is that news to anyone? Sussman and Steele showed that tail recursive functions are equivalent to for loops over 40 years ago. Map, reduce, et al can be built on top of either of them, and they're just as useful built on top of either. They're factoring out common patterns, the same way printf, strlen, and memcpy do.
        crimsonalucard 9y ago
        Apparently this concept is not even believed by the majority of people on this thread if you read the whole thing. 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.

crimsonalucard 9y ago

I disagree with you. Map and reduce achieve the same result as a for loop so why not use a for loop? The end result is the same it's just a bit cooler or convenient to use map in place of a for loop, that's the only reason why you would use one instead of the other in a imperative program. 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.

fnord123 9y ago
The result (return value) of a map is the list of results. A for loop has no result. So building up generic stream operators ((reduce (filter (map ...))) can't be done using for loops. It needs higher order functions or iterators.
- gaius 9y ago
  Additionally the for construct implies that you want something done in a certain order, map implies all operations are independent and the order can be decided by the runtime itself. A program written in a language supporting map (which requires first class functions) can be trivially parallelised, whereas every for loop must be carefully analysed first.
  - crimsonalucard 9y ago
    Then replace the for loop with a parallel construct that's imperative. In terms of the language itself, map, reduce and filter are just sugar... different ways to loop through collections. Using one does not mean you are using FP, using immutability in java means that you are. That is the difference.
    - steinuil 9y ago
      Actually, for loops in languages like Ruby and OCaml are just syntactic sugar for map. Also, why would you prefer an imperative construct over different kinds of folds?
      - crimsonalucard 9y ago
        I don't. My point is, it's all sugar, so in a sense it's the same thing when you're doing imperative programming. Whether you use a map or a for loop in your imperative code the structure of your program remains the same, the only difference is sugar... This is my point. 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.
- crimsonalucard 9y ago
  Obviously the for loop either transforms a list, or builds up a new list via an accumulator. That accumulator or the original list is your return value that you can imperatively pipe into other for loops. You realize that reduce, filter and map are all higher order functions that can be implemented with for loops?
  - fnord123 9y ago
    Yes because for loops are syntax sugar around gotos. It all boils down to the same thing. However maps can be determined to be turing incomplete if the mapped function has no function calls and no loops and if the input list is not infinite. This means that it's suitable for a wide range of dsls that would like to know if programs are susceptible to the halting problem (e.g. bpf -which doesnt have maps but I think it could...)
    - crimsonalucard 9y ago
      You just said a for loop returns no results. I responded saying that it can via an accumulator or mutating the original list... 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?
      - mclehman 9y ago
        Returning a result and modifying a data structure you've decided to use as an accumulator are two different things. Modifying the original structure is even more different. Most of the traditionally non-functional languages don't support loops as expressions.
        crimsonalucard 9y ago
        Yes, I get what your saying, but I can implement the map filter and reduce abstractions with a for loop using this accumulator pattern or pass in the parameter by value (aka copy) then modify the original structure. If I can implement MAP using a FOR loop then they are relatively the same thing as I can just replace a MAP with it's FOR loop definition and get the same result. 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.
dragonwriter 9y ago
> Map and reduce achieve the same result as a for loop so why not use a for loop? 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.
- crimsonalucard 9y ago
  Your first statement is correct but it's diverging away from my main point. >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.
- jcelerier 9y ago
  > and that clarity and limitation has practical advantages for things like parallelization and distribution, and how many of these "parallelized and distributed" map and reduces actually exist out in the wilderness of javascript code ?
kazinator 9y ago
> Map and reduce achieve the same result as a for loop so why not use a for loop? 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.
- crimsonalucard 9y ago
  The canned list processing functions can be implemented with a for loop.
  - kbp 9y ago
    > The canned list processing functions can be implemented with a for loop. So? They abstract out common patterns. You could write the great majority of functions' implementations inline instead of calling them.
    - crimsonalucard 9y ago
      So if the implementation of a HO function is a for loop then then an HO function and a for loop are equivalent. Thus proving my original point: It's the same thing. Using HO functions in an imperative language is not much different from using a for loop, it's all sugar.
      - kbp 9y ago
        Is that news to anyone? Sussman and Steele showed that tail recursive functions are equivalent to for loops over 40 years ago. Map, reduce, et al can be built on top of either of them, and they're just as useful built on top of either. They're factoring out common patterns, the same way printf, strlen, and memcpy do.
        crimsonalucard 9y ago
        Apparently this concept is not even believed by the majority of people on this thread if you read the whole thing. 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.