Hacker News Reader

Comment by mfbx9da4 | Hacker News Reader

I don’t support the pipe operator. I want my code to look like it came out of a beginners book. Esoteric syntax makes it hard for somebody new to the language to understand your code. Codegolf is cool but not helpful

View on HN

Good news, it will look like it came out of a beginners book, as the pipe operator gets added to beginners books. Just like arrow functions.

Your argument at this point is "I don't like it because it's new."

You should possibly instead argue on the merits of what it is.

Simple syntax, and straightforward behavior.

Simple syntax, like how '=>' is a two-character ASCII art 'fat arrow', and not anything to do with logical equivalence. That's how you syntax for beginners!

Eh, programming re-uses tons of punctuation a beginner needs to learn anyways. Semicolons don't split sentences, parathesis change depending on where it's used, commas seem random.

This concept even gets generalized itself with the concept of operator overloading in some languages, etc.

Saying this about JavaScript of all languages... The pipe operator is about the least likely to be confusing to a beginner.

And it's hardly "esoteric" when it's been around for decades in well-established languages (including bash, for God's sake). Just like the other commenter, you're only showing your ignorance of other paradigms here. Just because you were introduced to something else first, doesn't mean it's automatically the most intuitive way for everyone forever.

> including bash

bash scripts famous for being readable and maintainable :P

I fully agree with your sarcasm, but you probably know that that was not my point.

But seriously, I don't see what's so controversial about it. It's just "do this, then take the result and do that, then take the result and..." Everyone understands this intuitively. Plus, lots of libraries already do method chaining, which is just a crappier and inconsistent version of piping anyway.

I disagree. A true begineer is unlikely to be familiar with bash or these other languages.

Syntax like + - / * () = etc. are not esoteric since, for the most part, they work similar to math they learned in school.

But => and |? They are esoteric. As a beginner you have no idea what they will do without study.

> for the most part

That's the important bit. If they always worked as expected, I'd agree. But they don't. I could give plenty of examples but I'm sure you know about them.

> A true begineer is unlikely to be familiar with bash or these other languages

I'm with you on Bash, but not necessarily about "these other languages". Lots of people are being introduced to functional languages first, and if you don't think so you're probably just old.

I also don't assume a beginner will just be given code without any guidance. What do you think about dot notation? If they can/can't understand `foo().bar().baz()`, then surely they can/can't understand `foo() |> bar() |> baz()` all the same?

Actually the "lack of familiarity" argument is the best argument for introducing it in JavaScript: It's the language beginners are learning nowadays, so if it has feature x as a prominent feature, in a few years everyone will know about it.

> … and if you don't think so you're probably just old.

I resemble that remark!

(apologies to all; too good to pass up)

=> also comes straight from math learned in school. There it's written → (for function signatures), and (the more rare) ↦ for function definitions.

I'm a firm believe in "keep it simple" and "don't be clever" when it comes to code I have to maintain. But at the programming language level I want powerful constructs. I want to maintain simple and straightforward code in a powerful language, not the other way around.

I think this argument makes sense in _some_ usecases, but definitely not everywhere.

There are genuine places where a FP approach to API/DSL design makes sense and writing code that abstracts away from concrete parameters and focuses on composition is important. Operators for function application and composition can now be used for a similar concepts on a higher level of abstraction.

Suddenly 'esoteric' syntax helps clarify your code and forces you to focus on meaning and intent, not syntactic details of your PL.

You have no idea how much it improves the readability and understandability of code.

It's not esoteric if you are a functional programmer.

"programming shouldn't evolve, it should look like what i learned N years ago"? ;)

That’s a strawman. Is it “evolution” if it makes the language harder to learn, with no practical benefits other than “it looks cooler”?

I believe "harder to learn" is highly subjective in the same way that Japanese is hard to learn for a native English speaker but easy to learn for a Chinese.

Granted, Haskell and Scala are pretty "rich" and not beginner-focused.

OTOH, a language like Elm has a pipe operator and manages to keep things pretty simple.

Now does javascript need the added complexity? Tough call.

> Japanese is hard to learn for a native English speaker but easy to learn for a Chinese

This isn't to detract from your overall point but I study Japanese and many of my fellow students are Chinese, they certainly don't find it easy, even with the advantage of being able to infer most kanji. Korean to Japanese might fit the example better.

Interesting. The few Chinese students I had in my Japanese class back at university were so much faster than the rest of us.

I agree than Korean to Japanese might be even closer.

Well, if we assume that as they can read better they can prepare better, and that they’re relatively time rich as students; whereas in my group we all work, have families etc, it might be harder to make that advantage count?

Whatever the reason, I do envy their kanji skills!

that's fair, i was in a spicy mood.

there's "esoteric" as in fundamentally complicated, and """esoteric""" as in syntax that's unfamiliar but easily explained w/ a quick web search.

i believe "it's nicer to express some things this way" is a very important practical benefit. for me, "being expressive for experienced users" is ultimately more important to optimize for than """learnablility""", scare quotes intended. because beginners will be beginners for a while, and then they won't. (i dislike e.g. Go for this reason, but let's not get sidetracked)

(before you or someone else asks: i've tutored many beginner/first-time programmers, and yes, i still think a bit of syntactic sugar won't hurt them)

The practical benefit is that, unlike say Lodash's chaining, it is outwardly extensible, you don't need to write every function into a big object (and worry about naming clashes).

  _.chain(inputSet)
      .filter((x) => x >= 0)
      .map((x) => x * 2)
      .thru((e) => new Set(e))
      .value()

Assumes chain returns a object with {filter, map, thru, value}, and if you want a new operation you need to assign it to that object, which means the library that returned the original object must expose that too, and everyone knows "Prototype Extension Is Bad" since you could come up with a method name that someone else came up with too, then you'd override things and introduce bugs.

With chaining (even ignoring the % Hack syntax for placeholder expressions) you can use functions from anywhere: local variables, other objects, anything you want, even if the library that provided the original data is not viable to modify, since it doesn't need to be modified.

Another way of approaching this extension problem is, well, with extension members, like Kotlin or C#, where you can declare free functions to operate on a "this" of a specific type, and then you can use it exactly as if it was a method of the type. Of course, JS is dynamically typed so that wouldn't be viable in this case.

Finally, I think that for JS specifically, a pipe function is enough. Sure you have a few more commas around but it's fine. I could see the appeal of having an operator in TypeScript, since it would mean that types would be preserved much better.

You can make a similar argument for JSX, private properties, etc. The point is that there will always be use cases that see massive improvements from a feature, but that doesn’t mean it’s worth adding it to the language and paying the price in specification and implementation complexity, surface area and learning curve. Especially if it doesn’t enable any new use cases.

If the 5% of people that benefit can get 90% there using userland libraries, the cost of that 10% improvement should not be bore by the other 95%.

> no practical benefits other than “it looks cooler”

That is a very ignorant take and only shows that you haven't taken the time to learn the first thing about functional programming.

Unfortunately we already have arrow syntax, which is as esoteric as it gets. I think the idea of arrow syntax is good, but the chosen syntax sucks.

js is already a mixed bag of stuff, at least the pipe is usefull in making code cleaner especially compared to other features like:

1. support for class because you know real programmer don't like prototypal inheritance and prefer to type the word class in their code. In the meantime, let's make a compiler to translate that code onto something an old engine will also understand, yeah that sounds like an amazing idea and tada babel is now the centerpiece of everything

2. so many way to create a for loop, put a few footguns with the for in syntax, mix it with a few functions in the array proto cleverly named: forEach and map so now we need a linter to enforce a style

3. let's put some await async everywhere but forget about cancellation because things can't go wrong anyway

4. let's make different standard for packaging and import with workaround everywhere so there's no code reuse in between front and backend code even though the primary arugment for nodeJS in the early day was code reuse

5. let's not talk about code that rely on null == undefined to be true and Number(null) to be 0 but Number(undefined) to be NaN, ....

...

Reply on news.ycombinator.com