Ask HN: What do FP languages have that JavaScript doesn't? | Hacker News Reader

Ask HN: What do FP languages have that JavaScript doesn't?

4 pointsmuunbo12 comments

Whenever I read a functional programming tutorial or course, it always sings the praises of how there's an amazing REPL you can use to experiment with your code, or it will teach how to map and reduce over sequences, or first-class functions, or currying.

The problem for me is, all of these awesome features already exist in popular languages like JS and Python.

Then there's the "purity" side of things. For e.g. tutorials for Haskell and Clojure say that "mutation and side effects are not allowed" which makes for a more predictable program. But in my experience, I can totally just re-define variables in the REPL and no one stops me. I don't even get a warning. So I'm not sure if I'm missing something, but so far it doesn't feel so different from writing fancy ES6 syntax.

The last thing is "macros". This one seems to be actually unique to FP languages like Clojure, etc. But is this the only unique feature of FP languages?

Genuinely curious, please help me clear up my understanding. I have so far been following some fun Clojure and Haskell tutorials and these languages are very fun/sleek/logical to write in.

I am just wondering if I could accomplish the same in JS easily without learning whole new languages and ecosystems.

Functional Programming (FP) can be extremely elegant, and you should do your best to at least get familiar with it to see how using it can improve your code quality. There's a lot of theoretical reasons why this paradigm might be particularly great in a future where all devices seem to be adding lots of processing cores. For instance, without a function having side-effects, the potential for conflicts between threads or processes could be completely eliminated, so FP can potentially have some real-world benefits beyond just more elegant code.

That said, you should also think in terms of "What does JavaScript have that functional programming doesn't?". As a working-stiff programmer, most of the time the problems you're going to encounter are going to be a lot easier and faster to solve if mutating state is available as an option.

That's true, concurrency is becoming an important consideration and is probably why predictable and FP-oriented langs like Elixir, Rust, Clojure are having good growth.

As for mutating state, I come from an embedded software (microcontrollers) background haha and there's no option but to mutate state

Remember you can mix FP with other paradigms.

For example, feel free to use mutation if it's limited to the implementation of a small function. The function will still be effectively pure (to callers of the function).

Or when implementing "functional core, imperative shell," Gary Bernhardt says he tends to start with imperative code in the shell, then refactor it into the functional core[1].

[1]: https://hw.leftium.com/#/item/34866473

Most likely you know that Functional Programming (FP) is a Programming paradigm, that is, an approach to write the programs you have in mind. You have already mentioned some features of such paradigm, I am revisiting JavaScript myself (Since it was a long time since I use it) these days. And I am glad to find famous functions associated with FP, like flatMap, already available in JS. Since you already mentioned lots of these features, the only one that comes to my mind is Lazy Evaluation, which gives you the ability to work with "Infinite structures".

Perhaps you are already aware of these resources, but I will never get tired of recommending the following: * FP101x by Mr. Erik Meijer (The course is archived on edx.org but you can work your way through it). * The above is based on the outstanding book by Graham Hutton, Programming in Haskell. * And, if you can afford it in terms of time, a book from Mr. Peter Van Roy, Concepts, Techniques, and Models of Computer Programming. (There is a section devoted to FP).

Last but not least, I do love JavaScript.

Hope that helps.

Yes lazy evaluation is a good one. I believe Python does have that with its generators/yield syntax, but I found lazy evaluation simpler to work with in Haskell

One easy advantage is predictability due to thing not changing. Let's say there is an array (maybe I should have written list). Since that array cannot change in fp, when you do operations with that array, you don't have to worry it changed.

Then the language itself will also know this and manage memory accordingly.

So if you have array with 1,2,3 and an array with 3,4,5 if you unite the arrays memory can just reference the two array as if they were one instead of creating a new one, because for sure they will never change. Imagine this on very big arrays

That's a really cool example of how it can work behind the scenes, thanks

Another example of this is referential equality testing. You know deeply nested data structures are the same just by comparing their memory addresses since they cannot change.

Someone was able speed up React's virtual DOM using Clojure data structures.

Purity is about knowing that functions cannot change the state of variables. It is not about what you can do in the REPL.

Ah ok, thanks for clarifying that

The best way to answer these questions, I think, is to just try them out. For instance, Haskell has a very advanced type system that you won't get from Typescript, and it might change the way you approach your work in other languages.

FP is a way of thinking, which FP languages give nice features/syntax for. You can do non-FP style programming with an FP language.

In fact, many FP language features have been borrowed by non-FP languages to the point people don't consider them "FP" anymore[0]. (Like JS `.map()` and `.reduce()`. Even Excel macros now support first-class functions[1].)

Three features that would make FP thinking in JS easier:

1. immutable tuples and records[2]

2. pipe operator[3]

3. pattern matching[4]

Major epiphany: According to Grokking Simplicity[5], good functional programming isn't about avoiding impure functions; instead it's about giving extra care to them. Impure functions depend on the time they are called, so they are the most difficult to get right. In the end, the purpose of all software is to cause some type of mutation/effect (flip pixels on a screen, save bits to storage, send email, etc).

"Functional Core, Imperative Shell"[6] is probably the most useful FP concept. It is about pushing mutation/errors/impure functions to the outer edges of your code, so the inner code can focus on the "happy path." Complex business logic lives in the inner core; the outer shell is often simple/branchless so unit tests aren't even needed.

[0]: https://hw.leftium.com/#/item/21280429

[1]: https://hw.leftium.com/#/item/26900419

[2]: https://hw.leftium.com/#/item/23924933

[3]: https://hw.leftium.com/#/item/34454184

[4]: https://hw.leftium.com/#/item/16921652

[5]: https://www.manning.com/books/grokking-simplicity

[6]: https://hw.leftium.com/#/item/18043058

Reply on news.ycombinator.com