Live data from Hacker News

Javascript Arrays and Functional Programming

zabanaa.github.io

71–80 of 92 posts

Re: Javascript Arrays and Functional Programming

#71
post #28

Author here: I wrote this article mainly as a note to self that I could refer to in the future and as an exercise to help me learn the concept and force me to structure my thoughts into a coherent blog post. I thought I'd share it for those of us who are more intermediate and would like to pick up a few tricks along the way. Thank you all for the positive (and not so positive feedback)

For learning the concepts, something that I found rather enlightening was writing map/filter/every (and I guess, some or any, and really just about any function that operates on a collection), -with- a reduce.

Then, write your own recursive implementation of reduce.

I found it really helpful in grokking what these things did, and more broadly improved my understanding and use of functional composition

Re: Javascript Arrays and Functional Programming

#72

I accept that this is a widely used phrase now but I never understood why just using map/filter/reduce and avoiding state is enough for code to be called "functional programming". Most functional languages feature pattern matching, algebraic data types, purity, currying, strong typing, type inference, recursion instead of loops and types that cannot be null. It's a completely different style of coding. Adding map/fil…

Very true, and it reminds me of the push to use "for each" statements in Java instead of looping with an index. Really it's just another "how to avoid for loops" movement.

Re: Javascript Arrays and Functional Programming

#73
post #33

Earlier quoted context omitted.

Sounds more like "coding with map, reduce and filter" to me. It beats complex for-loops where mapping, reducing and filtering are all mixed in together but I wouldn't call it functional programming.

As mentioned in one of the comments, this is nowhere near the definition of functional programming. > It beats complex for-loops Nvm. I still prefer for loops in most cases, in some way it's easier to understand for me if I read it some months later. For example the reduce function I would write something like this: getPlayersByCountry= ( footballPlayers= [], players= {} ) -> for player in footballPlayers if players.…

Even with a small loop like that there are potential problems. Should there be an 'else'? You might know because you wrote it, but the compiler/runtime doesn't, and neither do other programmers on your team without taking time to analyse your intention. Using map/reduce/filter/etc. is declarative and less likely to result in spurious errors.

That's the benefit of this declarative approach, it removes the relentless boilerplate, works solely with intent, and reduces cyclomatic complexity.

Re: Javascript Arrays and Functional Programming

#74
post #33

Earlier quoted context omitted.

Sounds more like "coding with map, reduce and filter" to me. It beats complex for-loops where mapping, reducing and filtering are all mixed in together but I wouldn't call it functional programming.

As mentioned in one of the comments, this is nowhere near the definition of functional programming. > It beats complex for-loops Nvm. I still prefer for loops in most cases, in some way it's easier to understand for me if I read it some months later. For example the reduce function I would write something like this: getPlayersByCountry= ( footballPlayers= [], players= {} ) -> for player in footballPlayers if players.…

[deleted]

Re: Javascript Arrays and Functional Programming

#75
As a side note, using .push() isn't something I would consider being functional because immutability is a core concept of functional programming.

Too bad, JavaScript makes it hard to do it that way, in that concrete example using Object.assign() and .concat().

Re: Javascript Arrays and Functional Programming

#76

Earlier quoted context omitted.

Python actually discourages using map anf filter. Which is kind of weird to me but whatever.

Well in some cases it really is more efficient. [func(x) if x in collection if cond(x)] makes a single pass over the data and gives you a list, but list(map(func, filter(cond, collection))) makes two passes and requires some extra function calls. I think the real reason is perceived legibility on the part of the Python core devs. I seem to recall a document from a while ago in which GvR himself came out in favor of l…

Both map and filter returns an iterator, so you only iterate once when creating the list.

Re: Javascript Arrays and Functional Programming

#77
post #75

As a side note, using .push() isn't something I would consider being functional because immutability is a core concept of functional programming. Too bad, JavaScript makes it hard to do it that way, in that concrete example using Object.assign() and .concat().

> immutability is a core concept of functional programming.

That depends very much on your definition of FP (or how "pure" the FP is, depending on your definition of "purity").

Re: Javascript Arrays and Functional Programming

#79
post #77
post #75

As a side note, using .push() isn't something I would consider being functional because immutability is a core concept of functional programming. Too bad, JavaScript makes it hard to do it that way, in that concrete example using Object.assign() and .concat().

> immutability is a core concept of functional programming. That depends very much on your definition of FP (or how "pure" the FP is, depending on your definition of "purity").

Fair point. All my touch points (Lisp, JavaScript, even a bit Haskell and several books) all proposed immutability as being a fundamental principle.

Would you mind expanding a bit on that point in case I totally misunderstood something?

Re: Javascript Arrays and Functional Programming

#80
post #24

Earlier quoted context omitted.

> why just using map/filter/reduce and avoiding state is enough for code to be called "functional programming" A better term would be "programming with functions as first class citizens", but many years ago that got shorted to "functional programming". > Most functional languages feature pattern matching, algebraic data types, purity, currying, strong typing, type inference, recursion instead of loops and types that…

Well... for some of us, when you say "functional programming", you say "Haskell". And it certainly had all of those features, and much more, more than 20 years ago. I really like another poster's recommendation that it be called "combinator-oriented programming". Because, while ES, Java, and even Rust, supports rich combinator-oriented programming, I wouldn't dare call any of them functional programming languages. Th…

> Well... for some of us, when you say "functional programming", you say "Haskell".

Haskell is a single, functional programming language. It is not the definition of what a functional programming language is. If you mean Haskell, say Haskell. But don't try and redefine "functional programming" to mean "this one specific functional programming language that I happen to like".

Post reply on HN