Hacker News Reader

Comment by YuukiRey | Hacker News Reader

I wrote a blog post once, https://www.fbrs.io/ramda/, where I compared a functional solution and a vanilla solution. I tried to cover both performance and some vague notion of readability.

In the end the vanilla solution won in both areas. And I say that as an FP and Haskell fan boy.

View on HN

Ramda is what you get when people try to zealously make Haskell out of Javascript. The same happens in many other languages where people try to force Haskell idioms into languages.

Edit. For some reason people equate "functional" with Haskell, even though Javascript (and most modern languages) is perfectly capable of expressing functional idioms without the descent into madness.

Your vanilla solution is already a functional solution. Literally no need for `transduce pipe map over lens`

> [...] is perfectly capable of expressing functional idioms without the descent into madness.

Except of course deep recursion, which needs to be rewritten into a not so readable externalized stack or some kind of loop replacement. There are difficulties involved with rewriting some recursions as loops and some loops as recursion.

Of course, if JS engines adhered to the standard, they would all have TCO by now and the problem would not exist.

All you have to do is use a relocatable stack/heap hybrid like Go does.

I would argue that if you want to make an honest comparison than use an implementation that at least makes an effort to optimize functional code. And JS does jack shit for FP code compared to Haskell.

All code I've seen that uses Ramda looks like the one in the example.

No idea what your comment about jack shit is about. Haskell is often just as bad as Ramda.

Edit. By the way. All the unusable and unreadable jargon that Haskell uses can be much more easily explained with Javascript: https://github.com/hemanth/functional-programming-jargon Make of it what you will

What's wrong with Ramda?

Unusable unreadable unnecessary complex abstractions in a language that doesn't need them. Also, extremely non-performant.

As you can see even in the blog post: straightforward readable code using built-in functionality is turned into 8-12 imports, a bunch of auxillary functions and multiple function calls that obscure the actual functionality. At 35 times speed penalty and 2 times memory penalty.

The library itself is fine. The problem I see is twisting JS/TS in to a language it is not.

JS simply does not lend itself to currying, data-last signatures, piping, and pattern matching like an ML family language does. And as you can tell by the Ramda typings, neither does the TS type system. [0]

You will forever fight an uphill battle against every single tutorial and piece of documentation and colleague when going down this path. I don't think the effort is worth it.

0 - https://github.com/DefinitelyTyped/DefinitelyTyped/blob/dc9b...

Pipes and pattern matching have been proposed to JS.

https://github.com/tc39/proposal-pipeline-operator https://github.com/tc39/proposal-pattern-matching

As much as I like these concepts, I'd be hesitant about adding them to the language. At what point does a language support too many paradigms?

In contrast, take the recently stage-3'd Iterator Helpers[0]. These build on top of the language by using methods that already exists in other parts. It feels natural and is more of the same.

0 - https://github.com/tc39/proposal-iterator-helpers#implementa...

You can cherry-pick examples that go both ways, and we've all worked with individuals who have consistent biases towards and against functional idioms. In the end you have to rely on your own judgment for each case.

Reply on news.ycombinator.com