Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pipe Operator (|>) For JavaScript

github.com

Post reply on HN
Print view View original

421–430 of 437 posts

Re: Pipe Operator (|>) For JavaScript

#421

Post by nosianu »

krapp wrote: post #66
nosianu wrote: post #41

Earlier quoted context omitted.

> If you're compiling from another language TypeScript isn't another language though. It is the latest official ECMAScript plus type annotations. Only some very, very few, rare, old stuff like enums really is different code. 99% of TypeScript is just "remove the types to get ECMAScript". That TypeScript, the tool, also adds a transpiler is a distraction that made a lot of people believe TS is a different language. Bu…

>TypeScript isn't another language though. It is the latest official ECMAScript plus type annotations. Only some very, very few, rare, old stuff like enums really is different code. 99% of TypeScript is just "remove the types to get ECMAScript". That's another language. Javascript doesn't have type annotations - even the suggested addition of type annotation syntax to JS[0] doesn't actually do anything because it can…

It's not a different language as in "it's a different language". It's just types added. The actual executable code is pure Javascript. The type annotations have ZERO influence on what is executed, they are completely and used during development.

To call this "another language" as if it was C vs. Python does not make any sense, unless your main goal is to win some Internet argument no matter what.

Re: Pipe Operator (|>) For JavaScript

#422

Post by tgv »

AirMax98 wrote: post #171

That % syntax is just completely unlike anything else I have seen in JS. As a multi paradigm language, JS typically suffers from whatever programming style is on trend when these features are implemented. We are apparently on the other side of the pendulum now, but I can’t remember the last time I worked with a class and felt like that was right either.

> JS typically suffers from whatever programming style is on trend

Perhaps they are just jealous of the C++ committee. How many lambdas have they proposed and added to the language? At least 3: the C one, the Java one and now the Rust one.

Re: Pipe Operator (|>) For JavaScript

#423

Post by krapp »

nosianu wrote: post #421
krapp wrote: post #66

Earlier quoted context omitted.

>TypeScript isn't another language though. It is the latest official ECMAScript plus type annotations. Only some very, very few, rare, old stuff like enums really is different code. 99% of TypeScript is just "remove the types to get ECMAScript". That's another language. Javascript doesn't have type annotations - even the suggested addition of type annotation syntax to JS[0] doesn't actually do anything because it can…

It's not a different language as in "it's a different language". It's just types added. The actual executable code is pure Javascript. The type annotations have ZERO influence on what is executed, they are completely and used during development. To call this "another language" as if it was C vs. Python does not make any sense, unless your main goal is to win some Internet argument no matter what.

Yes, the language that Typescript emits is Javascript. I can write Python code that emits Javascript, but that doesn't make Python, itself, Javascript.

Languages can be structurally or idiomatically similar but still not be the same language. And there are more differences between Javascript and Typescript than just the type annotations (although that, alone, would be sufficient.) Typescript has generics, ffs.

Re: Pipe Operator (|>) For JavaScript

#424

Post by Rumudiez »

CyberDildonics wrote: post #400
Rumudiez wrote: post #87

Earlier quoted context omitted.

No, you don’t get it. Babel is for transpiling newer versions of JS to older ones, typically based on targeted browsers or Node runtimes. JS is a fantastic fp language and pipe/compose is commonplace for people writing in that style already. This just adds first class support to the language

> This just adds first class support to the language If it was a different language you could say it "just" adds something, but javascript is not compiled and any syntax change means you start over as far as compatibility goes. It is unique in its scope and usage and this feature doesn't enable anything new for users and is only marginally useful for programmers.

Browsers add support for new JS features every year. You can use them or not, I don’t care what you do. Every web stack I’ve worked on in the last 7 years has a compile step, too, so you’re either ignorant or being intentionally obtuse. Either way it’s not like anyone should listen to you.

So what’s your point, other than communicating how upset you are over a programming language? That we should be writing websites like it’s 1999?

Re: Pipe Operator (|>) For JavaScript

#425

Post by MathMonkeyMan »

runald wrote: post #415
MathMonkeyMan wrote: post #388

Can't javascript already do [this][1]? const thrush = (value, func, ...funcs) => func ? thrush(func(value), ...funcs) : value; // no new syntax required thrush( envars, Object.entries, x => x.map(([key, val]) => `${key}=${val}`), x => x.join(' '), x => chalk.dim('$ ' + x, 'node', args.join(' ')), console.log); [1]: http://www.davidgoffredo.com/thrush.html

Thrush combinator is neat. Here's another without using recursion: const thrush2 = (value, ...funcs) => funcs.reduce((value, func) => func(value), value); const thrush3 = (value, ...funcs) => { for (const func of funcs) value = func(value); return value }

Reduce is perfect for this, nice point.

Re: Pipe Operator (|>) For JavaScript

#426

Post by usrusr »

binarymax wrote: post #180
usrusr wrote: post #161

Earlier quoted context omitted.

Lots of low-value names required. Those names will inevitably either be badly chosen or have taken far more time to make up than they are worth. That's assuming the code isn't written by that one guy on every team who stubbornly insists on var x = three(); x = two(x); one(x): (having the names certainly is nice to have in the debugger, but I'd rather have those intermediate results be an explicit debugger feature tha…

Good point and yours does look better :)

The beauty of not using variables is that they don't pollute scope: a promise to the reader that it's perfectly fine to forget about that inermeditate result immediately after seeing it passed into the next step of the pipeline. Otherwise, you never know if it will perhaps show up later for some unexpected purpose. In a left-to-right language, those values that do get a name implicitly stand out

Re: Pipe Operator (|>) For JavaScript

#427

Post by xiphias2 »

vorotato wrote: post #211

These hack pipes are a trojan horse. People wanted elixir/F#/ocaml aka function pipes, and what we got was unreadable line noise. I argued against it until I was blue in the face, decided it was bad for my general wellness to keep it up. I genuinely would prefer no pipes over this. I couldn't find a single example where I preferred it. The token they chose already has a meaning in Javascript! The arrogance and willfu…

Can you give a link to the discussion? It would be quite relevant here.

Re: Pipe Operator (|>) For JavaScript

#428

Post by CyberDildonics »

Rumudiez wrote: post #424
CyberDildonics wrote: post #400

Earlier quoted context omitted.

> This just adds first class support to the language If it was a different language you could say it "just" adds something, but javascript is not compiled and any syntax change means you start over as far as compatibility goes. It is unique in its scope and usage and this feature doesn't enable anything new for users and is only marginally useful for programmers.

Browsers add support for new JS features every year. You can use them or not, I don’t care what you do. Every web stack I’ve worked on in the last 7 years has a compile step, too, so you’re either ignorant or being intentionally obtuse. Either way it’s not like anyone should listen to you. So what’s your point, other than communicating how upset you are over a programming language? That we should be writing websites…

I'm not sure why you're having a meltdown over this. You still haven't answered why someone needs compatibility breaking syntax sugar if you're already compiling to javascript.

Re: Pipe Operator (|>) For JavaScript

#429

Post by spiralx »

erixM wrote: post #373

What if you have to use the remainder operator? How would "|> % % 2" work?

The same way any other infix operator would, the operator has to have an expression on either side so the first % can't be an operator, and you can't have two expressions next to each other anyway i.e. you can't have "x x" or "f(x) x" or "% %"., so the second % has to be the % operator.

Definitely looks strange and could be confusing at first, but the syntax is unambiguous to parse. Add a comment, write "|> (%) % 2" perhaps, or just create a mod function and write "|> mod(%, 2)".

Re: Pipe Operator (|>) For JavaScript

#430

Post by hyperhopper »

chadlavi wrote: post #22

JavaScript isn't that kind of programming language. I don't know why people are constantly trying to make it something else.

What does that mean?

1. Javascript is at its core a functional programming language. In many ways it is more like lisp than like java (and lisp was the original intended syntax for javascript!) 2. Adding pipe operators is 100% in line for a functional programming language. 3. Even if it weren't, adding functional features to a high level language is definitely a good thing.

Post reply on HN