3 ms·
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, p
by gherkinnn 4y ago
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/dc9b44bf728c2c49f22055ddf0dec39d74ce2722/types/ramda/index.d.ts#L4021 https://github.com/DefinitelyTyped/DefinitelyTyped/blob/dc9b...
- tacotacotaco 4y agoPipes and pattern matching have been proposed to JS. https://github.com/tc39/proposal-pipeline-operator https://github.com/tc39/proposal-pipeline-operator https://github.com/tc39/proposal-pattern-matching https://github.com/tc39/proposal-pattern-matching
- gherkinnn 4y agoAs 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#implementations https://github.com/tc39/proposal-iterator-helpers#implementa...