`no-pipe` ESLint rule | Hacker News Reader

`no-pipe` ESLint rule

github.com

2 pointsarendjr6 comments

The pipeline operator currently sits at Stage 2 as an ECMAScript proposal. Many people (including me) believe the current proposal is a harmful addition to the language, and it would be better to not have a pipeline operator than the current Hack proposal. For this reason, I created the linked ESLint plugin.

Can you give me the gist of why it would be considered harmful?

Unlike pipe operators in functional languages, the Hack proposal is aimed at composition of expressions instead of functions. This makes the proposal extremely pervasive and unfocused, enabling people to write `a |> %[0]` instead of `a[0]`, for instance.

Proponents argue it’s great because you can pipe arbitrary expressions without nesting or needing temporary variables, but opponents argue it harms readability and will result in needless style arguments.

Makes sense. Could linters solve this issue?

> Do you want your child to learn to code using "Hello, World!" |> console.log(%);?

Considering they already know how to use pipe operator in bash, why not? I have read one article about some JS proposal (sorry can not found the link) and the punchline was about not turning JS into trapedy of Common Lisp - that sounded to me significantly more convincing.

At least Bash doesn’t have that hideous topic selector

I would be sympathetic if it were purely `”Hello, World!” |> console.log`. I still wouldn’t use a pipe in such a trivial case, but at least it’s not really worse. But with the topic selector that example has strictly more concepts you need to understand than the example without pipe. From an educational perspective that’s already not great, but what’s more worrisome is that proponents tend to suggest the pipeline should be used wherever you can, despite simultaneously “knowing” when not to use it and ignoring examples where you cannot use it due to multiple subjects being composed.

It’s not the pipeline in general that I’m against, but I’m very opposed to this “let’s-add-a-third-syntax-to-compose-arbitrary-expressions-Hack” proposal.

Reply on news.ycombinator.com