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

221–230 of 437 posts

Re: Pipe Operator (|>) For JavaScript

#221

Post by dgb23 »

hajile wrote: post #197
dgb23 wrote: post #167

Saw a talk with Douglas Crockford[0] years ago. He said something like: Before JS classes got introduced he asked why they didn't just implement macros for the language. Classes are in fact just syntactic sugar. Just like async/await, and now this proposal. In hindsight he was right. JS would be better off if it did have macros. Much of the whole babel/webpack/react/ts stuff would be just a bunch of macros instead of…

Mozilla created SweetJS over a decade ago[0]. It added hygenic macros to JS and I'm sure everyone on the TC39 committee is familiar with it. There's a lot to like about it, but macros in such a complicated language as JS are hard to get right. They'd also potentially lead to huge fracturing in the JS ecosystem with different factions writing their own, incompatible macro-based languages. Look at JSX for an example. I…

The issues you describe have emerged regardless of macros. Just with more expensive tooling.

Re: Pipe Operator (|>) For JavaScript

#222

Post by vorotato »

matlin wrote: post #34

Can't wait for this. Pipes are awesome in Elixir and bringing them to JS/TS will be great. To me this is both concise and readable: const weather = `https://api.weather.gov/gridpoints/TOP/31,80/forecast` |> await fetch(%) |> await %.json() |> %.properties.periods[0]

This is not elixir pipes. Elixir pipes are sound because they are piping to a function. Piping to a statement is not the same thing and it will become more clear in actual usage just how bad these are. Remember % in js is also modulo, and "test" % "ing" returns NaN. NaN is infectious since basically anything that operates on NaN returns NaN. "test" % "ing" + "ana" returns NaNana . You can quickly see how these pipes (as implemented) are so bad they might as well be language sabotage.

Re: Pipe Operator (|>) For JavaScript

#223

Post by _boffin_ »

scotty79 wrote: post #151
_boffin_ wrote: post #148

Earlier quoted context omitted.

If i saw that in a colleague's code, i'd be angry at them as that's not legible.

It's no less legible than original code and at least expresses the intent of what's being processed, what are the processing steps and what are processing parameters. a(b(),c(),d(e(),f(g()))) is just function call soup.

And I’d be angry if I saw that too. Break out the soup into variables and have it all be In a clean layout

Re: Pipe Operator (|>) For JavaScript

#225

Post by hajile »

no_wizard wrote: post #205

I hope Records & Tuples[0] land before this does. It would have meaningful and far reaching positive effects for the language, without much controversy. Like most of these things, it takes about 5-7 years for it to permeate through enough of the engines to be meaningfully useful in the day to day of web developers (node / deno typically 12-18 months tops). It would drastically speed up existing code once wide adoptio…

I've been wishing for this for years.

It opens up whole new ways of doing stuff when tuples and records are just primitives. They never mutate, so representing them efficiently right from the start is possible. They are primitives, so passing should be easier to do.

Concurrency becomes a lot easier to add to the language because if you limit it to primitives (which are all immutable), you get a lot of safety guarantees. I'd love to see either channels or actors baked into the language in the future.

Unfortunately, I don't think the pipe operator is the issue. Both of the proposals are just syntax. Implementing either just consists of a very straight-forward translation into already-existing syntax then running through the rest of the JIT as normal.

The real issue is stuff like the private variables in classes garbage. It added unnecessary complexity to the syntax (and is very ugly and perl-like). I've never met a senior JS dev (outside of TC39) who actually wanted or used it. Despite this, the JIT engineers couldn't wait to refactor all kinds of stuff all across the JIT to make this happen.

The time spent implementing private variables SHOULD have been spent implementing the infinitely more useful records and tuples.

Re: Pipe Operator (|>) For JavaScript

#226

Post by dgb23 »

madeofpalk wrote: post #215
dgb23 wrote: post #167

Saw a talk with Douglas Crockford[0] years ago. He said something like: Before JS classes got introduced he asked why they didn't just implement macros for the language. Classes are in fact just syntactic sugar. Just like async/await, and now this proposal. In hindsight he was right. JS would be better off if it did have macros. Much of the whole babel/webpack/react/ts stuff would be just a bunch of macros instead of…

What would macros for JavaScript look like? Would you ship them to the client for browsers to execute?

Yes, JS is a dynamic language, so I would expect you ship them as-is.

Re: Pipe Operator (|>) For JavaScript

#227

Post by scotty79 »

no_wizard wrote: post #205

I hope Records & Tuples[0] land before this does. It would have meaningful and far reaching positive effects for the language, without much controversy. Like most of these things, it takes about 5-7 years for it to permeate through enough of the engines to be meaningfully useful in the day to day of web developers (node / deno typically 12-18 months tops). It would drastically speed up existing code once wide adoptio…

Is the point of those just immutability or something else too?

Wouldn't it be better to have a way to easily make any type deeply immutable?

EDIT:

I think tuples and records are also supposed to have value semantics, which is great, but why not a mechanism that turns on value semantics for arbitrary object type instead.

Also value semantics is separate concept from immutability. Maybe there should have separate ways to get expressed rather that combining them in form of just tuples and records.

To sum up, I can see why the community is hesitant.

Re: Pipe Operator (|>) For JavaScript

#228

Post by greggman3 »

rektide wrote: post #144
cokeandpepsi wrote: post #125

Earlier quoted context omitted.

the refactored version of the example is much worse

why? are you of a 'pointfree' opinion? what are your concerns? https://wiki.haskell.org/Pointfree personally i detest pointfree syntax. having intermediate values makes it much easier to step through code with a debugger & see what is happening. and it gives the reader some name for what the thing is, which is incredibly useful context. the enablement of pointsfree styles is one of my main concerns about potential pi…

I agree that

(1) named intermediate values are sometimes more readable ... though I have examples where it's very hard to come up with names and not sure it helped

(2) debugging is easier.

For (2) though, this IMO is a problem with the debugger. The debugger should allow stepping by statement/expression instead of only by line (or whatever it's currently doing). If the debugger stopped at each pipe and showed in values (2) would mostly be solved. I used a debugger that worked by statements instead of lines once 34 years ago. Sadly I haven't seen once since. It should be optional though as it's a tradeoff. Stepping through some code can get really tedious if there are lots of steps.

Re: Pipe Operator (|>) For JavaScript

#229

Post by dmix »

arp242 wrote: post #100
dmix wrote: post #57

Earlier quoted context omitted.

Just because pipe's aren't the ideal solution for that convoluted example they decided to list doesn't mean they aren't still extremely useful for a consistent set of problems. Like anything they can be abused to make code less readable. I also have a feeling this doc lists every sort of usecase, not because they are advertising it as "always the better version", but because it's a design doc that needs to factor in…

I'm just using the example they posted in the README as an "before-after". I think that's a reasonable thing to do when evaluating "do I think this would be a good feature?" Blame the author(s) of that document if you don't think it's a good example.

That seems to be missing the point of the document then. Before/after in a design doc isn't "this is a better way to do it".

Re: Pipe Operator (|>) For JavaScript

#230

Post by vorotato »

galaxyLogic wrote: post #59
hajile wrote: post #3

They should have stuck with the F# proposal. The hack proposal just takes one more giant step toward turning JS into Perl. Hack proposal value |> foo(%) for unary function calls, value |> foo(1, %) for n-ary function calls, value |> %.foo() for method calls, value |> % + 1 for arithmetic, value |> [%, 0] for array literals, value |> {foo: %} for object literals, value |> `${%}` for template literals, value |> new Foo…

Wouldn't it be better to use '->' as the operator? This is about dataflow so an arrow would represent that nicely. Whereas '|>' doesn't really "mean" anything. An arrow means that something flows in the direction of the arrow.

I also pushed for this in TC39 which was shut down for seemingly no reason. Since only one language with almost no user base uses |> to mean expressions, people are guaranteed to get the wrong idea about how it works. It almost seems like intentional misleading.
Post reply on HN