What does HackerNews think of proposal-pipeline-operator?
A proposal for adding a useful pipe operator to JavaScript.
That is, it's a yet another library trying to force Haskell/Haskellisms into Javascript and claiming with no proof other than emotions that it's so much better and more readable than something.
Here's an actual readable version of that:
try{
return getTurnPromptMessages(state, action)
.map(mkCCRequestFromMessages)
.map(addSchemaToRequest)
.map(handleChatCompletion)
.map(extractFirstCompletionChoice)
.map(extractChatCompletionMessage)
.map(decodeSchema)
.map(detectLocation);
} catch (e) {
mkMessageError(e);
}
It can be further simplified. For example, you don't need two separate functions to extract the first chat completion message etc.This version:
- uses existing language constructs
- can be immediately understood even by the most junior devs
- is likely to be 1000 times faster
- does not rely on an external dependency that currently has 143 issues and every two weeks releases a new version adding dozens of new methods to things
Note: one thing I do wish Javascript adopted is pipes: https://github.com/tc39/proposal-pipeline-operator
There are few exceptions (namespaces, enums) but typescript has been quite averse to adding non-standard language level features outside type annotations. This feature will likely come to ts after this proposal has been accepted for js.
Perhaps the two committees should learn a bit from each other.
import { map, takeWhile, forEach } from "iterlib";
getPlayers()
|> map(%, x => x.character())
|> takeWhile(%, x => x.strength > 100)
|> forEach(%, x => console.log(x));
1: https://github.com/tc39/proposal-pipeline-operatorThere's a long-standing TC39 proposal to add it to JS. It's interesting to read it to see examples of the aforementioned differences.