←back to thread

Why Isn't Functional Programming the Norm? [video]

(www.youtube.com)
296 points gyre007 | 7 comments | 17 Oct 19 10:10 UTC | HN request time: 0.647s | source | bottom
Show context
onion2k ◴[17 Oct 19 10:39 UTC] No.21280617[source]▶
JavaScript isn't a functional language itself, but you can use a functional library like lodash/fp (https://github.com/lodash/lodash/wiki/FP-Guide) on top of it to get all that lovely functional goodness in your frontend and node code. Using lodash/fp has made my frontend state management code a lot nicer, and I'm really only just starting out with it.
replies(4): >>21280640 #>>21280696 #>>21280761 #>>21281273 #
Tade0 ◴[17 Oct 19 10:56 UTC] No.21280696[source]▶
You may want to consider Ramda.js instead: https://ramdajs.com/

IMHO does a better job than Lodash, because:

1. All functions are automatically curried.

2. The order of parameters lends itself to composition.

EDIT: 3. Transducers.

replies(3): >>21280709 #>>21280791 #>>21281336 #
1. enlyth ◴[17 Oct 19 12:35 UTC] No.21281336[source]▶
I never understood the point of Ramda. It's like it's trying to replace the core functionality of JS with something that's completely orthogonal to what the language actually is, but it's just a bolted on library.

I've worked on codebases where people ignore all built-in JS functions (like Array.map/filter) and write Ramda spaghetti instead with multiple nested pipes and lens and what not to show off their FP purism.

Most of the time, you don't need any of this, it just makes the codebase unreadable, and hard for new people to join the project and be productive in a timely fashion.

replies(4): >>21281470 #>>21281810 #>>21281831 #>>21292365 #
2. onion2k ◴[17 Oct 19 12:51 UTC] No.21281470[source]▶
Most of the time, you don't need any of this, it just makes the codebase unreadable, and hard for new people to join the project and be productive in a timely fashion.

This is exactly how I felt when I inherited a big project that uses lodash/fp. Having spent ~6 months with the code now I prefer having a functional layer on top of JS. It does make sense.

3. wdroz ◴[17 Oct 19 13:30 UTC] No.21281810[source]▶
Maybe to avoid questionable behaviors, like in the article posted 3 months ago "Why ['1', '7', '11'].map(parseInt) returns [1, NaN, 3] in JavaScript" [0]

[0] - https://news.ycombinator.com/item?id=20242852

replies(1): >>21289076 #
4. tashoecraft ◴[17 Oct 19 13:32 UTC] No.21281831[source]▶
I only reach for Ramda when the built in Js functions can not accomplish what I want to do, or it would be very messy/hard to reason about. Now that’s very subjective, but I hate when I see people using lodash/ramda map to just map over an array. There’s a lot you can do with the built in methods and they will probably be the superior option
5. Roboprog ◴[18 Oct 19 06:14 UTC] No.21289076[source]▶
Things like Ramda and jquery help avoid fighting against IE and other browser nuances, as well.

Even when there seem to be native functions/ methods to do something. That’s where the monster lives.

6. Roboprog ◴[18 Oct 19 15:46 UTC] No.21292365[source]▶
You stick with your “polyfill”, I’ll stick with mine , so to speak.

It’s nice to be able to make a function as concisely as something like:

Const foo_finder = R.find( R.propEq( ‘prop’, ‘foo’ ) )

...

Const a_foo = foo_finder( a_list )

replies(1): >>21295719 #
7. enlyth ◴[18 Oct 19 22:57 UTC] No.21295719[source]▶
See this is one of the things I personally hate, accessing or evaluating properties on objects using a string.

We have code so use code which can be parsed, evaluated by the type checker, and so on. What if you mistype 'fop' instead of 'foo'?