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

Functional programming in JavaScript is an antipattern

hackernoon.com

Post reply on HN
Print view View original

81–90 of 92 posts

Re: Functional programming in JavaScript is an antipattern

#81

Post by zumu »

k__ wrote: post #70
zumu wrote: post #28

I've been doing FP in JavaScript fulltime for a few years now. I find it much easier than the OOP approach. My advice to the author is: choose ImmutableJS, Ramda, OR lodash. Don't choose all three. I think that is his anti-pattern. > I could be more productive if I didn’t have to wonder things like ... “Should I mutate this variable?” If you're doing FP the answer is likely 'No.'

Or? Ramda doesn't even have the same functionality as Lodash.

Excuse the overstatement -- there are sane ways to use the libraries in the same project. The point was the 3 libraries all prescribe a certain model of structuring and operating on data. One cannot reasonably expect to use all 3 without some cognitive overhead.

Re: Functional programming in JavaScript is an antipattern

#82

Post by acemarke »

yomly wrote: post #67
bestest wrote: post #12

In my opinion the top rated comment is right on point there: "I’d say that ImmutableJS is your anti-pattern here, not FP in JavaScript as a whole."

I agree - I use ImmutableJS in one of my projects and the pros vs cons are substantial - it's hard to keep track of when something is Immutable or not and it has been slowly infecting more and more of my codebase. I would be interested in hearing strategies of mitigating this, my first step has been to let Immutable creep through the project, but adopt a convention of creating a layer through which guarantees JS outp…

Interesting you should say that. I wrote a Reddit comment about a year ago listing reasons why I generally advise against use of Immutable.js, and the "infectious" API is exactly one of the reasons that I listed ( https://www.reddit.com/r/javascript/comments/4rcqpx/dan_abra... ).

Also worth noting that if you are going to do Immutable -> POJO conversions, you should avoid using `toJS()` as much as possible. The conversion process is expensive, _and_ it always creates new object references. Either use `getIn()`, or use memoized selectors to ensure the conversion only happens when the data actually changed.

Re: Functional programming in JavaScript is an antipattern

#83

Post by shamas »

Just a note on immutability, I feel like this is pretty straightforward in ES6 (map, spread operator, and Object.assign) and will be more so with spread-operator for objects in ES7. Am I missing something?

I mean, you still have to THINK about whether you need to keep something immutable or not, but that's the difference between a junior developer and a more seasoned engineer, right?

Re: Functional programming in JavaScript is an antipattern

#84

Post by k__ »

zumu wrote: post #81
k__ wrote: post #70

Earlier quoted context omitted.

Or? Ramda doesn't even have the same functionality as Lodash.

Excuse the overstatement -- there are sane ways to use the libraries in the same project. The point was the 3 libraries all prescribe a certain model of structuring and operating on data. One cannot reasonably expect to use all 3 without some cognitive overhead.

I see.

I was just reminded of last week, when I needed a utils lib. I read many good things about Ramda, but then I wanted to debounce a function and it failed me, haha.

Re: Functional programming in JavaScript is an antipattern

#85

Post by mannykannot »

mcphage wrote: post #78
_lce0 wrote: post #71

Earlier quoted context omitted.

Mathematically a Function is a Relation that has two special properties: uniqueness and existence. (these properties names can be wrong as I've not study calculus in English) So on the machine, Immutability plays an important role on the first piece, uniqueness, so it tries to guarantee that results are not just "equal objects, but different instances", which breaks the function definition. Of course that functions t…

Mathematical functions aren't too great a metaphor for computer functions. They share a lot of similarities—domain, range, inputs, outputs, composability. But mathematical functions just are , there's no notion of changing things—however, the most common purpose of computer software is to change things. So it breaks down, or you come up with some way of defining a change without anything changing, which adds a layer…

I think it is correct to say that, in the functional paradigm, you effect change by making something new (and forgetting some older things.) Regardless of the paradigm (other than self-modifying code, perhaps) programs just are, but they must be evaluated if they are to do something useful.

I will leave that last sentence as I wrote it, but it immediately leads me to wonder if functions that write functions have wandered into the self-modifying code realm?

Re: Functional programming in JavaScript is an antipattern

#86

Post by cronjobber »

coldtea wrote: post #30

Funny, but HN oldsters probably remember when functional programming wasn't at all tied to immutable data structures, and when Lisp and derivatives where considered enough functional programming, without every discussion of the topic requiring strictly requiring purity and immutability -- just first class functions, map, fold, and the like.

The book "Functional Programming" by Field and Harrison (1988) was already very much into referential transparency as the panacea for all our programming woes:-)

Re: Functional programming in JavaScript is an antipattern

#87

Post by _lce0 »

mannykannot wrote: post #85
mcphage wrote: post #78

Earlier quoted context omitted.

Mathematical functions aren't too great a metaphor for computer functions. They share a lot of similarities—domain, range, inputs, outputs, composability. But mathematical functions just are , there's no notion of changing things—however, the most common purpose of computer software is to change things. So it breaks down, or you come up with some way of defining a change without anything changing, which adds a layer…

I think it is correct to say that, in the functional paradigm, you effect change by making something new (and forgetting some older things.) Regardless of the paradigm (other than self-modifying code, perhaps) programs just are , but they must be evaluated if they are to do something useful. I will leave that last sentence as I wrote it, but it immediately leads me to wonder if functions that write functions have wan…

I really agree with you. Think that there's a tension between how a computer works and how a functions operate on data.

Immutability and Referential Transparency help reduce that friction, but in the end we still have not found a real solution. That's why languages like Haskell require a bunch of gymnastics just to allow IO to be seen as pure functions.

Re: Functional programming in JavaScript is an antipattern

#88

Post by yomly »

acemarke wrote: post #82
yomly wrote: post #67

Earlier quoted context omitted.

I agree - I use ImmutableJS in one of my projects and the pros vs cons are substantial - it's hard to keep track of when something is Immutable or not and it has been slowly infecting more and more of my codebase. I would be interested in hearing strategies of mitigating this, my first step has been to let Immutable creep through the project, but adopt a convention of creating a layer through which guarantees JS outp…

Interesting you should say that. I wrote a Reddit comment about a year ago listing reasons why I generally advise against use of Immutable.js, and the "infectious" API is exactly one of the reasons that I listed ( https://www.reddit.com/r/javascript/comments/4rcqpx/dan_abra... ). Also worth noting that if you are going to do Immutable -> POJO conversions, you should avoid using `toJS()` as much as possible. The conve…

Yep memoized selectors was on my list of things to look at - great tip!

My philosophy is when providing the POJO from the immutable data structure is to select the absolute minimum from the bigger object, which I suppose is in line with your advice on using getIn

Re: Functional programming in JavaScript is an antipattern

#89

Post by marcus_holmes »

yomly wrote: post #66
tasuki wrote: post #25

Earlier quoted context omitted.

What did you mean?

If I had to guess: that macros in LISP are natural, owing to the fact that its syntax are all s-exps which make it parsing it easier than in other languages?

I had to go down a small rabbit hole of my own ignorance here.

My initial thought was that since JS is the target environment for a LISP compiler, it would necessarily have to be more flexible and "powerful" (whatever that means). With a bit more thought I realised that that's not the case.

Thanks for the prompt to look into this more, and learn :)

Re: Functional programming in JavaScript is an antipattern

#90

Post by zurn »

shamas wrote: post #83

Just a note on immutability, I feel like this is pretty straightforward in ES6 (map, spread operator, and Object.assign) and will be more so with spread-operator for objects in ES7. Am I missing something? I mean, you still have to THINK about whether you need to keep something immutable or not, but that's the difference between a junior developer and a more seasoned engineer, right?

This is the C++ trap - you keep piling on more features to the language and then you can answer some criticisms by saying "just use this subset". But this is not how the usage of programming languages pans out. Programmers can't agree even with themselves (=consistency) about what subset to use, or have accidents with it. And libraries / practices in that PL's culture can't rely on those conventions and subsets, so they can't really leverage the benefits. It's basically inventing your own mini-language with borders drawn in the sand and not enforced by any tooling.
Post reply on HN