Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Javascript Arrays and Functional Programming

zabanaa.github.io

Post reply on HN
Print view View original

81–90 of 92 posts

Re: Javascript Arrays and Functional Programming

#81

Post by seanwilson »

dahart wrote: post #57
seanwilson wrote: post #16

Earlier quoted context omitted.

> The other things you mention are just great language features, but not specific to functional languages. Imperative C++ also has type safety, Swift has non-null types, etc. All those features in combination are shared by the vast majority of languages called functional programming languages. They're pretty much the defining features of functional languages was my point. Other languages can have a subset of the feat…

None of pattern matching, algebraic data types, strong typing, type inference and types that can't be null are specific to functional, nor do they make it any more functional. Purity isn't a language feature, it's a measure of how functional a language is, so it's tautological to say functional languages share purity. Currying is a byproduct of first class functions, not of functional programming, and currying is com…

> Functional programming "treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data." That is the definition of functional, and it's the whole definition. No mutation, that's it. Including the features you wrote about is not functional programming, it's other things.

Are you meaning that "no mutation" is the definition of functional programming? That's such a vague definition I can't see how it is useful personally. "Stateless" is already a word that covers that.

If you're going to quote Wikipedia, keep going to the "Concepts" section that lists language features: "A number of concepts and paradigms are specific to functional programming, and generally foreign to imperative programming (including object-oriented programming). However, programming languages are often hybrids of several programming paradigms, so programmers using "mostly imperative" languages may have utilized some of these concepts.[40]"

> The author was pretty clear that this is functional programming concepts as applied to arrays in JavaScript, he never claimed that this post covers functional programming in general.

I even said I accept it's common usage of the phrase and I was just wondering why that was.

Re: Javascript Arrays and Functional Programming

#82

Post by qrohlf »

cygned wrote: 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().

agreed, the Array.prototype.reduce could be accomplished in a far more readable way using a simple forEach. If the function was doing a `concat` instead of a `push`, it would make a lot more sense to me as a functional example, because then the author would actually be taking advantage of the way the accumulator result from the previous call is passed into the next call.

Re: Javascript Arrays and Functional Programming

#83

Post by moosingin3space »

ablomen wrote: post #43
guiomie wrote: post #36

In his example Array.prototype.reduce, isn't this almost the same as just doing a foreach loop? I don't understand why doing this, it's pretty much the same number of lines.

In this example it is, but a nice thing about using map, reduce etc is that you can chain them together, ex: let out = ["a", "b", "c", 1, 2, 3] // Turn letters to upper case .map(i => { return typeof i === "string" ? i.toUpperCase() : i; }) // Add one to numbers .map(i => { return typeof i === "number" ? i + 1 : i; }) // split letters and numbers up .reduce((all, i) => { typeof i === "string" ? all.letters.push(i) :…

The problem with this is that it generates two intermediate arrays in the maps, then effectively drops them in the reduce. This may be inefficient.

I wish that JavaScript's map/filter/reduce functions returned lazy iterators, like in Rust, so that code like this doesn't produce intermediate arrays. Does anyone know of a library that provides this?

Re: Javascript Arrays and Functional Programming

#84

Post by delhanty »

seanwilson wrote: post #7

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…

>but I never understood why just using map/filter/reduce and avoiding state is enough for code to be called "functional programming"

Maybe that's enough to count as first-order functional programming ?

The Wikipedia article on Spreadsheet [1] seems to suggest that even a spreadsheet counts as first-order functional program:

>The formula may rely on the value of other cells, but those cells are likewise restricted to user-entered data or formulas. There are no 'side effects' to calculating a formula: the only output is to display the calculated result inside its occupying cell. There is no natural mechanism for permanently modifying the contents of a cell unless the user manually modifies the cell's contents. In the context of programming languages, this yields a limited form of first-order functional programming.[2]

[1] https://en.wikipedia.org/wiki/Spreadsheet

[2] https://www.cambridge.org/core/journals/journal-of-functiona...

Re: Javascript Arrays and Functional Programming

#85

Post by jarrettch »

kaishiro wrote: post #23
arkadiytehgraet wrote: post #10

TL;DR author provides an example of map, filter and reduce functions in JS. I have been wondering lately what is the value of articles like this. They do not convey any meaningful idea, they do not offer any useful insight on underlying matters; why do people even write something like this, except to litter the Internet even more? Anyone, who is distinctly familiar with functional programming or even just with the co…

Man, I had just worked up the nerve to start a personal dev blog but you've just scared me straight off.

Don't let this scare you.

When I first started learning this stuff, I started a blog. I made maybe 3 posts before giving up on it, thinking about how much I didn't know, how that everything I could write about at the time was probably covered elsewhere and better, etc.

Several years later I regret giving up.

A lot of writing is writing for yourself. Obvious benefits to that, one of which is hopefully you get better at communication, which is huge in life in general, not just a career as a dev on a team.

Another is learning through teaching or keeping a record. I've probably forgotten a bunch of things over the years that, had I written them in my blog I may remember, or at least know where to find the post instead of scouring the internet looking for another post by someone else that I used to helped me solve a problem.

Potential employers may like seeing a blog as well. You can tell someone you're passionate about x, but where's the proof of that passion? It may not be the most in depth blog like Dr. Axel Rauschmeyer's, but it'll still show what you know. And you never know who's reading, so you may help someone in the process.

The internet is already filled with "litter" or useless things. But if you're getting use out of it then that's the main point to focus on.

Re: Javascript Arrays and Functional Programming

#86

Post by dahart »

seanwilson wrote: post #81
dahart wrote: post #57

Earlier quoted context omitted.

None of pattern matching, algebraic data types, strong typing, type inference and types that can't be null are specific to functional, nor do they make it any more functional. Purity isn't a language feature, it's a measure of how functional a language is, so it's tautological to say functional languages share purity. Currying is a byproduct of first class functions, not of functional programming, and currying is com…

> Functional programming "treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data." That is the definition of functional, and it's the whole definition. No mutation, that's it. Including the features you wrote about is not functional programming, it's other things. Are you meaning that "no mutation" is the definition of functional programming? That's such a vague defi…

> Are you meaning that "no mutation" is the definition of functional programming?

You can see that I was intentionally summarizing wikipedia's definition in one word to make my point more clear that functional does not mean type inference or currying, right?

> That's such a vague definition I can't see how it is useful personally. "Stateless" is already a word that covers that.

Since I'm not offering "immutable" as the complete and final definition for functional programming, maybe you can find a better one to make your original point clear? Because the list of features you offered as defining functional programming doesn't define functional programming very well.

IMO, the entire first paragraph of Wikipedia's article on functional programming is pretty good. It repeats the concept of immutability in a bunch of different ways with clarifying examples, to make it more concrete and less vague.

I don't personally like "stateless" because it's not strictly true. Functional programs have state, and the state is contained in the stack. The point of functional programming is that the language avoids side effects, and the most direct word for something that avoids side effects is "immutable", not "stateless". I can accept that common usage of stateless is sometimes referring to immutability.

Note that WP's definition of "state" agrees with that, and talks about declarative state being indirect, as opposed to being stateless: "In declarative programming languages, the program describes the desired results and doesn't specify changes to the state directly."

https://en.wikipedia.org/wiki/State_(computer_science)

> I even said I accept it's common usage of the phrase and I was just wondering why that was.

Because it's true and meets the definition? Your objection is too vague. What, exactly, is wrong with calling map/filter/reduce "functional"? In my book, referring to map as an example of functional programming doesn't stretch the strict definition of functional programming at all.

map() and reduce() were some of the very first things I learned about when I was introduced to the concept of functional programming in Scheme, more than 20 years ago.

The post didn't claim that map, filter & reduce were 'enough for code to be called "functional programming"'. He only ever implied that map, filter & reduce are part of functional programming. That is absolutely true, always has been, and isn't a matter of common usage.

Re: Javascript Arrays and Functional Programming

#87

Post by jlg23 »

cygned wrote: post #79
jlg23 wrote: post #77

Earlier quoted context omitted.

> 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?

You did not "totally misunderstand something": Immutability is a virtue in FP, you should write in this style. But it is only a "fundamental principle" and "core concept" in highly pure languages - and even Haskell allows mutable variables[1].

Sometimes you just need them, e.g. when handling potentially very large vectors in finite memory. CL's (sort ...) for example mutates the input sequence (or "destructively sorts" it [2]).

[1] https://wiki.haskell.org/Mutable_variable [2] http://www.lispworks.com/documentation/HyperSpec/Body/f_sort...

Re: Javascript Arrays and Functional Programming

#88

Post by dave7 »

sleazybae wrote: post #55

this post introduced me to the arrow function (( https://stackoverflow.com/questions/24900875) ), which i'd previously not heard of. evidently it was introduced in ECMAscript 6 but for engines that use JavaScript and older browsers (amazingly, they still exist) it won't work

There is a spurious ) ending your link, resulting in page not found error.

For those using arrow functions these days for web, most will use Babel in the build process to provide compatibility with older platforms.

Re: Javascript Arrays and Functional Programming

#89

Post by marmart »

moosingin3space wrote: post #83
ablomen wrote: post #43

Earlier quoted context omitted.

In this example it is, but a nice thing about using map, reduce etc is that you can chain them together, ex: let out = ["a", "b", "c", 1, 2, 3] // Turn letters to upper case .map(i => { return typeof i === "string" ? i.toUpperCase() : i; }) // Add one to numbers .map(i => { return typeof i === "number" ? i + 1 : i; }) // split letters and numbers up .reduce((all, i) => { typeof i === "string" ? all.letters.push(i) :…

The problem with this is that it generates two intermediate arrays in the maps, then effectively drops them in the reduce. This may be inefficient. I wish that JavaScript's map/filter/reduce functions returned lazy iterators, like in Rust, so that code like this doesn't produce intermediate arrays. Does anyone know of a library that provides this?

Those intermediate iterations could be dropped by composing the map functions together (same with the reduce), if that really was a performance bottleneck.
Post reply on HN