Object.keys(envars)
     .map(envar => `${envar}=${envars[envar]}`)
     .join(' ')
     |> `$ ${%}`
     |> chalk.dim(%, 'node', args.join(' '))
     |> console.log(%);

  console.log(chalk.dim(
      `$ ${Object.keys(envars)
        .map(envar => `${envar}=${envars[envar]}`)
        .join(' ')
      }`,
      'node',
      args.join(' ')
  ));

Can also write it as:

   process.stdout.write(chalk.dim(
     `$ ${Object.keys(envars)
       .map(e => `${envar}=${e[envar]}`)
       .join(' ')
     }`,
   ))
   console.log(chalk.dim('node', args.join(' ')))

   console.log(chalk.dim(`$ ${dumpObj(envars)}`, 'node', args.join(' ')))

I also feel this:

> In the State of JS 2020 survey, the fourth top answer to “What do you feel is currently missing from JavaScript?” was a pipe operator.

Is the wrong way to go about language design. Everyone wants something different, and if you just implement the "top 5 most requested features" you're going to end up with some frankenbeast of a language.

    import {map, join} from 'lodash/fp' //iterators have better performance

    envars
    |> Object.entries
    |> map(([key, val]) => `${key}=${val}`)
    |> join(' ')
    |> x => chalk.dim('$ ' + x, 'node', join(' ', args))
    |> console.log

    envars
    |> Object.entries
    |> x => x.map(([key, val]) => `${key}=${val}`)
    |> x => x.join(' ')
    |> x => chalk.dim('$ ' + x, 'node', join(' ', args))
    |> console.log

    envars
    |> Object.entries(%)
    |> %.map(([key, val]) => `${key}=${val}`)
    |> %.join(' ')
    |> chalk.dim('$ ' + %, 'node', join(' ', args))
    |> console.log(%)

Just replace this:

    x |> f

    f(x)

    xs
    |> (x => x.join(' '))

    (x => x.join(' '))(xs)

    xs.join(' ')

Does join(a)(b) mean join(a, b) or join(b, a)? Does it mean a.join(b) or b.join(a)? And is a or b the delimiter? I don't really feel confident without looking it up or trying it out. I have a similar problem with Haskell's function syntax a -> a -> a.

If the function was called makeJoinerBy(sep)(array), it would be somewhat clearer:

    join = makeJoinerBy(' ')
    result = join(array)

(the requirement being that join(' ') returns a function that takes one arg)

The middle example would be using native stuff which is why you have the wrapper function (kinda like you'd have a function wrapping a callback)

That’s highly subjective I’m afraid.

“Take entries of envvars, turn that into k=v, join that by a space, make dim $, previous that, and args, log that”.

Personally I have no clue what’s going on at first glance with all these %%% “thats”. It’s meant to be declarative, but reads imperatively instead.

  console.log(chalk.dim(
    '$',
    ...Object.keys(envars)
      .map(k => `${k}=${envars[k]}`),
    'node',
    ...args,
  ))

With pipes you can visually follow the manipulations and function calls in the order that they happen instead of being forced to scan the code inside-out & outside-in, matching parentheses and function call parameters in your head, while still visualizing intermediate results to get 1 final return value.

I find Elixir code much easier and quicker to understand, in large part thanks to its (admittedly, imperfect) pipe syntax. Code written in this way is also much easier to debug because you can quickly add `console.log`, breakpoints, or equivalent between the pipes.

I find this unnecessarily time-consuming and difficult to parse and I'd likely raise some flags in a code review:

  console.log(chalk.dim(
      `$ ${Object.keys(envars)
        .map(envar => `${envar}=${envars[envar]}`)
        .join(' ')
      }`,
      'node',
      args.join(' ')
  ));

  const envStr = Object.keys(envars)
        .map(envar => `${envar}=${envars[envar]}`)
        .join(' ');
  const styled = chalk.dim(`$ ${envStr}`, 'node', args.join(' '));
  console.log(styled);
  

  const sensitiveEnv = [...];
  const envStr = Object.keys(envars)
        .filter(envar => !sensitiveEnv.includes(envar))
        .map(envar => `${envar}=${envars[envar]}`)
        .join(' ');
  const styled = chalk.dim(`$ ${envStr}`, 'node', args.join(' '));
  console.log(styled);

  const envs = Object.entries(envars).map(entry => entry.join('='));
  console.log(chalk.dim('$', ...envs, 'node', ...args));

"styled" seems entirely pointless here.

One habit introduced to my current team by a former co-worker involves having even more intermediate keys than that:

    const sensitiveEnv = [...];
    const envKeys = Object.keys(envars)
    const safeKeys = envKeys.filter(envar => !sensitiveEnv.includes(envar));
    const safeEnv = safeKeys.map(envar => `${envar}=${envars[envar]}`).join(' ');
    const styled = chalk.dim(`$ ${envStr}`, 'node', args.join(' '));
    console.log(styled);

Now, of course, with a pipe operator (or other similar constructions) you can get the consistency without the intermediate names.

I'm also one of those people that likes single-letter variables. I know some people hate it with a passion, but I find it very convenient. Just makes it easier to read as there's less to read.

I'm not smart enough to do Haskell, so I can't say much about that.

I agree with your remarks, there's no right or wrong, it's like tabs and spaces.

Btw I'm also not smart enough for Haskell, but it hasn't stopped me so far ;)

This is why I'm happy to see the pipe syntax proposal, it avoids unnecessary temporary variables while simultaneously aiding readability.

The thing is I don't think it's all that much more readable. No matter which syntax you use, there's still the same number of "things" going on in a single statement.

I do have to admit I never worked with a language that uses |>, so I'm sure that with increased familiarly with this it would become "more readable" to me, but one has to wonder: just how many calling syntaxes does one language have to support? More syntax also means more potential for confusion, more ways to abuse the language/feature, more "individual programming styles", more argueing over "should we write it like this or that?", more overhead in deciding how to write something, harder to implement the language and write tooling for it, and things like that.

There is always a trade-off involved. The question to ask isn't "would this be helpful in some scenarios?" because the answer to that is always "yes" for practically any language feature. The question to ask "is this useful enough to warrant the downsides of extra syntax?" I'm not so sure that it is, as it doesn't really allow me to do anything new that I couldn't do before as far as I can see. It just allows me to make things that are already too complex a bit more readable (arguably).

Have you never worked with Bash? It's basically the same thing

Given that the OP stated that they like the pipe syntax, and the refactored version illustrates the hoops you'd have to jump through without it, I guess your comment is just a strange way to agree with the OP?

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 pipe operator syntaxes: the various syntaxes that have been raised often introduce implicit variables which are passed, and i greatly fear the loss of clarity pointsfree style brings.

maybe there's something beyond the pointsfree vs not debate here that i'm missing, that makes you dislike the refactored example. personally i greatly enjoy the flatness, the step by step production of intermediate values, each of which can be clearly seen, and then assembled in a last final clear step. that is much more legible to me than one complex expression.

In languages that more easily support repl-driven development (e.g. Clojure), I think this is less of an issue. If you have a handful of pure functions, you can quickly and easily execute them via the repl, so you get a lot of clarity as to what those intermediate values look like even if the functions are ultimately used in a more point-free style.

But on the other hand, this would be a nightmare in C# (what I use in my day job). Sure, you can execute arbitrary expressions while debugging C#, but IMO you can't really achieve the same clarity. I'd rather see intermediate values like you suggest since it's easier while debugging, vs a bunch of nested function calls.

(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.

I have tools that can do it, but I'll still have a better time splitting out a variable for it, especially since what I really want is a log of all the intermediate values, so I can replicate what it's doing on paper

It makes me really question the judgement of the people that are working on this language, and it explains how some of the shittier proposals manage to slip in and why the good ones are misused all over the place in every real world codebase when this is the kind of guidance devs have on where to use fancy new features.

In a few years everyone is going to collectively lose their fucking mind once again and decide that ternaries are now the devil and every React component should be chock full of do expressions. I can see that coming clear as day. That might finally be enough to get me to throw in the towel if the also incoming decorator hell doesn't do it.

This example was literally taken directly from real-world code in the React codebase (a script to call jest-cli). While you're correct that there are probably a lot of clearer and more readable ways to write this snippet, the fact of the matter remains that people write code exactly like these "real world examples" all of the time.

I was an early adopter of the original decorators proposal as well as the F#-style pipeline operators. The more time has moved on and other bits made it into JS proper, I'm far more inclined to stick to what's "in the box"... Have even considered just writing straight JS + ESM (modules). Of course, I also like JSX, though not sure of any proposals of how to get that "in the box" as e4x died on the vine and a lot of other efforts didn't gain much traction either.

Only now?

Examples?

If the motivation behind these features are React components, javascript clearly lacks proper logic in array (and object) literals, like

  '[' if (cond) […]expr1 [else […]expr2] ']'

    [cond ? expr1 : expr2]

    [(() => {/*code*/})()]

  [...(cond ? [expr1] : [])]

I mean it looks exactly like JS with an additional % placeholder.

- we already have operators on values, such as +

- |> is just another operator on values

It's incredible to me TC39 would rather have this monstruosity over F# pipes which are actually pretty similar to how most pipes work and read in most functional languages including unix `|` one.

https://news.ycombinator.com/item?id=3780367

https://news.ycombinator.com/item?id=6418337

Use |> for the Hack proposal

and -> for F# -style.

    const slowSum = (lst: {x: number}[]) =>
      switch(list) {
        [{x}, ...y]   -> x + slowSum(y) //not tail recursive
        [{x}, {x: y}] -> x + y          //alias second x to y
        [{x}]         -> x              //handle length 1
        []            -> 0              //handle length 0
      }

|> is the best operator

    let keys = Object.keys(envars);
    let text = keys.map(envar => `${envar}=${envars[envar]}`).join(" ");
    console.log(chalk.dim(`$ ${text}`), "node", args.join(' '));

Pipes are probably better used on a set of operations that takes input and runs multiple functions on the input, rather than fiddling with string concatenation multiple times.

What do we use multi-pipes for in unix? I can't recall the last time I used one where the middle action wasn't a filter of some sort. grep -v to remove lines, or colrm or awk print to cherry-pick fields from a multi-field line. Once in a very long while I need to do three commands with filters between them. Beyond that it's too complicated and I make a script to handle several of the steps.

A more aggressive reformulation would be to prefix the original code with

  const envOutput = Object.keys(envars).map(envar => `${envar}=${envars[envar]}`).join(' ');
  const argsOutput = args.join(' ');

  console.log(chalk.dim(`$ ${envOutput}`, 'node', argsOutput));

  envOutput |> `$ ${%}` |> chalk.dim(%, 'node', argsOutput) |> console.log(%);

Only if the first parameter of the function is the sole subject & subsequent parameters are "additional". Which isn't the case in this example: all params are equal subjects.

But you can still think about this as merging in two additional pipes into the one you are processing. So 'node' and argsOutput are just very short pipes that you are merging into the flow of current one.

Btw... chalk API feels super weird.

For me the piped version seems way better, way cleaner, with cleanly separated processing steps.

I don't like nested steps because for nesting multiple arguments functions your expression tends to grow in both directions and parts belonging to the same step tend to end up really far from one another and clearly distingushes them from data that's pushed through the pipeline.

% is short so it keeps parts of the same processing step together.

This syntax also enables you to express which part is the data to be processed, what are the processing steps and what are additional parameters of the processing steps.

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 edge cases, such as using a pipe following chained function calls.

You cherry picked one example of a tangled/messy block of code that they used to communicate specific idea around "left to right" comprehension and flow of the data using the new syntax. For that specifically it did a fine job.

But that doesn't mean that's the way you should be writing code in the first place, given it started with a mess and only used one piece of syntax to change it.

I will admit it's a poor example to open with. But for a design doc about exploring and debating ideas it's fine.

I don't think it's fair to say it's "cherry picking" to focus on the example they focus on themselves. They have a few other examples too, but I would say "I don't see how [NEW] is better than [OLD]" for many of those as well (and for some, I think the [NEW] is significantly worse).

Plus the doc is #1 on HN after all, which could IRL push it beyond a proposal stage if done right.

Then again, this is my typical opinion to a lot of the proposals - I see what this is useful for but I haven't experienced enough pain to really argue for it. However, if it does make it into the spec then I will use it probably because it's there.

I also recognize my stance as one that not many people like in other contexts because it can be interpreted as me not looking to improve my situation. But on the flip side I think cluttering the language specification with a lot of superficial syntactic sugar is a mistake.

If i read a code and i want to now what it will do, i wanna first read that it will output something. If that is what i search for, i read the nested code.

With the pipe style i waste more time, even if the code looks clearer.

I not overused example could look like this:

  console.log(
    Object.keys(envars)
      .map(envar => `${envar}=${envars[envar]}`)
      .join(' ')
    |> `$ ${%}`
    |> chalk.dim(%, 'node', args.join(' '))
  )

I suspect that many developers expressed their desire for this operator under the believe that it would make their style of programming easier, which F# indeed does for many code bases, particularly those that use libraries such as fp-ts or rxjs.

However the advanced version fails to deliver that

    let _= Object.keys(envars).map(envar => `${envar}=${envars[envar]}`).join(' ')
    _= `$ ${_}`
    _= chalk.dim(_, 'node', args.join(' '))
    _= console.log(_);

You can also cram it into one line with semicolon:

    let _= Object.keys(envars).map(envar => `${envar}=${envars[envar]}`).join(' ') ;_= `$ ${_}` ;_= chalk.dim(_, 'node', args.join(' ')) ;_= console.log(_);

Additional 'benefit' is that until you leave the scope you can access output of the last pipe through _.

You can always use ;_= for consistency and pre-experess you intent to use the piping in the current scope by doing `let _;` ahead of time:

    let _;

    ;_= Object.keys(envars).map(envar => `${envar}=${envars[envar]}`).join(' ')
    ;_= `$ ${_}`
    ;_= chalk.dim(_, 'node', args.join(' '))
    ;_= console.log(_);

To better confer the direction of the pipe you might even use the letter that is oriented to the right:

    let D;
    ;D= Object.keys(envars).map(envar => `${envar}=${envars[envar]}`).join(' ')
    ;D= `$ ${D}`
    ;D= chalk.dim(D, 'node', args.join(' '))
    ;D= console.log(D);

    let D;
    return D= take(D) ,D= bake(D) ,D= serve(D);

    let D;
    return D= take(D) 
    ,D= bake(D) 
    ,D= serve(D);

Btw I think I'll name this operator duck ,D=

Maybe the pipe syntax extension will be introduced if we threaten to make duck operator a thing?

You can even use an array if you don't need to peek the value in the middle of a chain of operations

Example:

    createChain(
      Object.entries(envars)
      .map(([key, value]) => `${key}=${value}`)
      .join(' ')
    )
      .map(keys => `$ ${keys}`)
      .map(pattern => chalk.dim(%, 'node', args.join(' ')))
      .use(line => console.log(line))

Very much this. They need a new question on the survey "does JavaScript need new syntax or can we just leave it alone and work on perf/tooling/etc. of the existing stuff without throwing a bunch of new junk in"?

Can you imagine a survey where everyone says they're satisfied with the language as-is? Of course not. That's statistically impossible. Even if 99% of the needs of developers are satisfied by a language, people are going to eventually answer that they'd like something that the language doesn't have, and that's always the case.

Let's say JavaScript implemented nearly every single language feature that's ever been invented. That is except the goto statement. Upon being surveyed on what they think is currently missing from JavaScript, a significant number of developers will have to respond with goto. Does that mean JavaScript is actually "missing" goto and that it was a mistake that it was never implemented in the first place? Of course not.

On the other hand, pipe is less useful when you don’t have partial application of function built-in. So yeah I think this is not worth it.

Ironically, OO gets thrown under the bus a lot lately because it ain’t functional. But in reality, early OO languages like Smalltalk and CLOS were much more functional in this regard, you always had an implicit return of self, which could be chained easily.

I (over)use the piping operator (|>) in Elixir a lot. I just like the way it reads. But one thing I don’t love, is that it’s not an easy sequence to type.

I personally find pipe style much more readable.

However, the 5th most requested feature in that poll is somehow "functions", and "sanity" also appears in the results, so this particular source may not be a good one.

    Object.keys(envars)
      |> %.map(envar => `${envar}=${envars[envar]}`)
      |> %.join(' ')
      |> `$ ${%}`
      |> chalk.dim(%, 'node', args.join(' '))
      |> console.log(%);

    Object.keys(envars)
      |> % => %.map(envar => `${envar}=${envars[envar]}`)
      |> % => %.join(' ')
      |> % => `$ ${%}`
      |> % => chalk.dim(%, 'node', args.join(' '))
      |> % => console.log(%);

Reading this version though I also notice something else that the F# style enables that the Hack style doesn’t which is that it supports destructuring. So in F# style, I can more easily make pipe steps that pass on multiple values in a structured object or array, then access them easily down-pipe.

     chalk.dim(Object.keys(envars)
       .map(envar => `${envar}=${envars[envar]}`)
       .join(' ')
       |> `$ ${%}`, 'node', args.join(' '))
     |> console.log(%);

X

.this()

.that()

.then()

.do()

.a()

.thing()

And I expect this to let me keep that chain going for when I need to run a static function against the chain

X

.this()

.that()

.then()

.do()

.a()

.thing()

|>JSON.stringify(%)

  > I also feel this:
  >> In the State of JS 2020 survey, the fourth top answer to “What do you feel is currently missing from JavaScript?” was a pipe operator.
  > Is the wrong way to go about language design.

"Signor Rossi cosa vuoi? … E poi, e poi, e poi" (Viva la felicità by Franco Godi [1])

[1] https://www.youtube.com/watch?v=UrKKMtjNWCI

I just write things as stupidly as possible now, and just do the second one even though there are nicer "ruby-ways" to do them - maybe this is "bad" but I find it easy to read and grok...and it doesn't cause arguments during review <.<

    > `${50}: ${[1,2,3].map(a => `${a+1}`)}`
    '50: 2,3,4'

Yes! A hundred thousand times yes!

I have not seen this syntax in JavaScript before, but just by having the vague notion that it's pipe-like, I was able to generally understand what was happening within seconds of reading it. I'd have to read up on the syntax a bit to confidently write code in this style, or perhaps to fix a bug (does "${%}" do what I think it does) but I can quite literally comprehend the author's intent almost at almost the same speed as I can read.

    1. get all the keys of envars.
    2. convert every key into a "var=value" format.
    3. put a space between them all
    4. stick a dollar sign in front of the whole thing
    5. no clue what the `chalk` library is for?
      a. this *appears* to prefix a "node ${args}" call with the previously-created environment variable bits
      b. that tracks with what we've seen so far
      c. close enough for now
    6. log the whole thing

With the second one, I have to construct a tree in my head

    1. console.log…
      a. the result of chalk.dim, which is
        i. all the env vars
        ii. mapped to key=value format
        iii. joined by a space
      b. ^ actually do chalk.dim on that thing above
        i. sorry, back up, there were some additional arguments
      c. ^ actually do chalk.dim on the above with 'node' and space-separated args
        i. I think this concatenates them?
        ii. double-check [1.a] to confirm
        iii. did I miss `args` defined somewhere in [1.a]?
          A. no, it's apparently inherited from scope
    2. ^ actually log all the above
      a. wait is this a correct reading, based on reassembling the above?

I have no opinion on the merits of this particular syntax, its implementation details, or in comparison to alternate proposals of similar ideas. I'm sure there's worthwhile debate to be had on those details. But from a high level, I'm a fan. My head is not a meat-based tree traverser and I'm guessing most people's isn't either. Human brains are big fans of linear narratives. While I love movies and shows like Memento and Westworld, this kind of disjoint storytelling is quite literally done for the purpose of generating confusion and not for promoting comprehension.

Also, there may already exist better ways of expressing this particular example linearly and succinctly. If there is, I'd probably prefer that. Worst-case scenario you can always deconstruct nested function calls into sequential variable assignments, and maybe that's the "best" answer here instead of new syntax. But is an approach that can be understood linearly from start to finish clearer than one that requires mental tree-walking? Yes. Yes yes yes yes yes.

I can only hope this leads to Javascript becoming even more unbearable. Perhaps only this can weaken Google's resistance to WASM.

Is this Perl?

DROP jerkings_tab;

Is this really Perl?

> But there are reasons why we encounter deeply nested expressions in each other’s code all the time in the real world, rather than lines of temporary variables.

And the reason it gives is:

> It is often simply too tedious and wordy to write code with a long sequence of temporary, single-use variables.

Sorry, but...that's the job? If naming things is too hard and tedious, you don't have to do it, I guess, but you've chosen a path of programming where you don't care about readability and maintainability of the codebase into the future. I don't think the pipe operator magically rescues the readability of code of this nature.

The tedium of coming up with a name is a forcing function for the author's brain to think about what this thing really represents. It clarifies for future readers what to expect this data to be. It lets your brain forget about the implementation of the logic that came up with the variable, so as you continue reading through the rest of the code your brain has a placeholder for the idea of "the envVar string" and can reason about how to treat it.

The proposal continues:

> If naming is one of the most difficult tasks in programming, then programmers will inevitably avoid naming variables when they perceive their benefit to be relatively small.

Programmers who perceive the benefit of naming variables to be relatively small need to be taught the value of a good name, and the danger of not having a good name, not given a new bit of syntax to help them avoid the naming process altogether.

The aphorism "There are two hard problems in computer science: cache invalidation, and naming things." is not an argument to never cache and never name things. That's mostly what we software folks spend our time doing, in one way or another.

Sure, it can’t be completely eliminated, but why not do less of a thing that’s hard, when it can be avoided?

Values have a “name”, whether it’s a variable ‘keysAsString’ or the expression ‘keys.join(' ')’. The problem with keysAsString is that you have to type it twice, once to define it and again to use it. It’s also less exact, because it’s a human-only name, not one that has a precise meaning according to the rules of the language. (E.g. a reader might wonder what the separator between the keys was - if you don’t store it in a variable, then the .join “name” tells you precisely right at the site it’s used.) Making the variable name more precise implies more tedium in the writing and reading.

If the value is used twice or more, I would usually say storing it in a well-named variable is preferable, but if it’s cheap or optimizable by the compiler I might still argue for the expression.

This may be a irreconcilable split between different types of thinkers, perhaps between verbal and abstract.

    let field = ve.instanceContext.replace(/(#\/)|(#)/ig, "").replace(/\//g, ".")

    const fieldWithHashMarksUnesacped = ve.instanceContext.replace(/(#\/)|(#)/ig, "");
    const field = fieldWithHashMarksUnesacped.replace(/\//g, ".")

and this

    return moment(input).utc().format('YYYY-MM-DD HH:mm:ss')

    const inputAsMoment = moment(input);
    const inputConvertedToUTC = inputAsMoment.utc()
    return inputConvertedToUTC.format('YYYY-MM-DD HH:mm:ss')

In your first find, yes, your modification helps me understand that code much more quickly. Especially since I haven't looked at this code in several years.

In that case, patches welcome!

In your second case, as the sibling comment explained, I'm not opposed to chaining in all cases. But if the pipe operator is being proposed to deal with this situation, I'm saying the juice isn't worth the squeeze. New syntax in a language needs to pull its weight. What is this syntax adding that wasn't possible before? In this case, a big part of the proposal's claim is that this sequential processing/chaining is common (otherwise, why do we care?), confusing (the nested case I agree is hard-to-read, and so would be reluctant to write), or tedious (because coming up with temporary variable names is ostensibly hard).

I'm arguing against that last case. It's not that hard, it frequently improves the code, and if you find cases where that's not true (as you did with the `moment` example above) the pipe operator doesn't offer any additional clarity.

Put another way, if the pipe operator existed in JS, would you write that moment example as this?

    return moment(input)
      |> %.utc()
      |> %.format('YYYY-MM-DD HH:mm:ss');

If you program in object oriented style then . is mostly all you need.

If you program in functional style you could really use |>

Those typos leak out to calling code and it's hilarious when the typo is there 10 years later once all the original systems have been turned off

The code removes all “#/“ (or just “#” if a slash isn’t there). After that it replaces slashes with dots. How on earth is that “hash marks unescaped”?

This works the way human cognition does, by batching. The way humans can fit more items in short-term working memory is to batch up related concepts into one item. This is how chess masters do it - they don't see a piece and look individually at each square it is attacking, they see the entire set of attacked squares as one item. This is why "correct horse battery staple" passwording works - the human doesn't remember twenty-eight individual characters, they remember four words.

Temporary variables follow how human cognition works, particularly when the reader is going to be somebody else's cognition who didn't go through the process of writing it.

    function bakeCake() {
      return separateFromPan(coolOff(bake(pour(mix(gatherIngredients(), bowl), pan), 350, 45), 30));
    }

    function bakeCake() {
      return gatherIngredients()
        |> mix(%, bowl)
        |> pour(%, pan)
        |> bake(%, 350, 45)
        |> coolOff(%)
        |> separateFromPan(%)
       ;

    function bakeCake() {
      const ingredients = gatherIngredients();
      const batter = mix(ingredients);
      const batterInPan = pour(batter, pan);
      const bakedCake = bake(batterInPan, 350, 45);
      const cooledCake = coolOff(bakedInPan);
      return separateFromPan(cooledCake);
    }

I agree that the the control flow is more clearly elucidated in the pipe operator example, but it tosses away useful information about the state that the named variables contain. It also introduces two new syntactical concepts for your brain to interpret (the pipe operator and the value placeholder). I contend the cognitive load is no greater in the example with names, and the maintainability is greatly improved.

If you have an example where there are dozens of steps to the control flow with no break, I'd be really curious to see it.

1. Gather the ingredients, mix them in a bowl, pour into a pan, bake at 350 degrees for 45 minutes, let it cool off and then separate it from the pan.

2. Get ingredients by gathering the ingredients. Make batter by mixing the ingredients. Make batter in a pan by pouring the batter in a pan. Make a baked cake by baking the batter in the pan at 350 degrees for 45 minutes. Make a cooled cake by cooling the baked cake. Separate it from the pan.

For me personally #1 is more readable because #2 is unnecessarily bloated with redundantly described subjects.

Going back to the concrete scenario GP presented, naming things makes it much clearer to me.

    function bakeCake() {
      const bakeTemperature = 450;
      const bakeTime = 45;  // minutes
      // ... 
      const bakedCake = bake(batterInPan, bakeTemperature, bakeTime);
      // ...
      const finishedCake = separateFromPan(cooledCake);
      return finishedCake;
    }

Then naming it is just noise.

If your bake() function was rather named createBakedCake() than naming returned value bakedCake just increses reader fatigue through repetition.

Same way

Random random = new Random();

in C# is worse than

var random = Random();

I don't necessarily disagree with this. But even granting that this is true: congrats, you've just found the worst part of giving these intermediate steps a name! Like, that's the worst case example of the cost side of the tradeoff we're discussing here. And it's not that big a cost! Like, of all the code you write, how much of it fits this case? Where you're writing a function where there's a lot of sequential processing steps in a row with no other logic between the steps AND the intermediate state doesn't have any particular meaning?

In that worst case, you have a little extra information available (like your Random random = new Random()) example that your eyes need to glide past.

I would wager your brain is more used to scanning your eyes past unnecessary information and can do that with less effort and attention than it can either:

    - bounce back and forth between the chained function calls of the original nested example.
    - synthesize the type and expectations of the intermediate value at any arbitrary point in the piped call chain.

And the work to come up with "obvious" names isn't hard. Start with the easy name:

    batterInPan = pour(batter, pan)

Or maybe you want to just start with the unnamed nested or chained calls, and when you need to read or debug or refactor or test your code you pay the "naming things" price tag at that point. That's often the first thing I do when I come across code with a dearth of names, I just give everything a boring, uncreative temporary name, and then I can do whatever work I showed up to this code to do. It's not ideal, but it's better than every JS library sprinkling a new bit of syntax in just so they can avoid giving their variables names and can use an overloaded modulo operator instead.

Yes. But given that people would usually put you on a stake for naming function bake() because it doesn't tell anything about what the function expects or returns and bare minimum about what it does, this use case scenario is what happens very often, because naming your function in a very informative manner is very important because they are a part of the API.

If you really have functions like bake() or pour() in your code esp in weakly typed language then for the love of God, yes, please name the variables that you pass there and get from them always and as verbosely as possible.

Don't get me wrong, I'm very fond of naming intermediate things too. And with helpful IDE it can even tell you the types of intermediate things so you can better understand the transformations that the data undergoes as it flows through the pipeline.

But sometimes type, that IDE could show also automatically in |> syntax is even more important than the name for understanding. VS Code does something like that for Rust for chaining method calls with a dot. Once you split dot-chain into multiple lines it shows you what is the type of the value produced in each line.

My personal objection to naming temporary values too much in a pipeline is that it obscures distinction between what's processed and what are just options of the each processing step. But I suppose you might keep track of it by prefixing names of temporary values with something.

> Or maybe you want to just start with the unnamed nested or chained calls, and when you need to read or debug or refactor or test your code you pay the "naming things" price tag at that point.

Yeah, that's usually what I do. I start with chains and split them and pay for the names as I go.

> That's often the first thing I do when I come across code with a dearth of names, I just give everything a boring, uncreative temporary name, and then I can do whatever work I showed up to this code to do.

I'm also splitting and naming stuff in that case and checking types along the way. But I prefer that to encountering the code named verbosely and wrongly. Then I need to get rid of the names first to see the flow then split it again sensibly. Of course I don't usually commit those changes in shared environments. Only in owned, inherited ones or if the point of my change is to refactor.

Granted that chaining class member accessor mostly covers up this problem of naming intermediate things if you use classes. That's why we even survived without pipe syntax. But since we would like to move away from classes a bit to explore other paradigms maybe it's time?

    function bakeCake() {
      return do(
        () => gatherIngredients(),
        ingredients => mix(ingredients),
        batter => pour(batter, pan),
        batterInPan => bake(batterInPan, 350, 45),
        () => coolOff(bakedInPan),
        cooledCake => separateFromPan(cooledCake)
      );
    }

   function bakeCake() {
      const ingredients = gatherIngredients();
      const batter = mix(ingredients);
      const batterInPan = pour(batter, pan);
      bake(batternInPan, 350, 45); // this is an in-place modifying function, I guess
      const cooledCake = coolOff(bakedInPan);
      return separateFromPan(cooledCake); 
    }

It could at least be

    function bakeCake() {
      return do(
        gatherIngredients,
        mix,
        batter => pour(batter, pan),
        batterInPan => bake(batterInPan, 350, 45),
        coolOff,
        separateFromPan
      );
    }

    function bakeCake() {
      return do(
        gatherIngredients,
        mix,
        pour(pan), // assuming that pour(pan) returns a function that pours something into that pan
        bake(350, 45), // assuming that bake(temp, minutes) returns a function that bakes something at that temperature for that time
        coolOff,
        separateFromPan
      );
    }

... I further suspect that their problems are mostly self-inflicted, but maybe I'm wrong about that.

I often find flow-crutches like the one described in this proposal more confusing to decipher than plain old fashioned, well thought out code.

Lambda (=>) expressions in C# and closures in JavaScript are others I sometimes find myself pausing at to make sure I'm interpreting correctly.

I always figured it's just because I'm an older programmer and haven't used the new language features enough for them to become intuitive. I do acknowledge there are use cases where they're a perfect fit for the pattern in which you're coding.

But I feel like they're too-often taken as a shortcut to dump a bunch of operations in one place when it would be more readable to structure into well-organized functions that logically group concerns.

It's not that I don't like syntactic sugar to make code more concise, I just think languages need to remain judicious about how many different ways they dole out to accomplish the same task before they start to risk 'rotting their teeth'. Gotta keep striving for elegance - as you renovate over time it can get harder to keep the bar high.

I'm afraid these pipe operators will become like ternaries and will tend to produce "smart" lines of code which are difficult to parse at first glance.

Temporary variables are great for writing obvious code which is trivial to parse when reading.

```

return validate(get_response(value))

```

or

```

value = get_response(value)

value = validate(value)

return value

```

into

```

res = get_response(value)

new_res = validate(res)

return new_res

```

Why? Easier to read and when Sentry throws an error I have each value from the call stack. Much easer to debug. In the example 2 you can accidentally move a line and not notice the error.

I don't think the Pipe Operator would be as useful in comparison.

I really hate how long the Records & Tuple proposal has been languishing at stage 2. It could've shipped years ago if not for a syntax debate that dragged on and on without being fruitful[1]

EDIT: there is a class based version of this, that is stage one, for adding structs[2]. They behave similarly.

[0]: https://github.com/tc39/proposal-record-tuple

[1]: https://github.com/tc39/proposal-record-tuple/issues/10

[2]: https://github.com/tc39/proposal-structs

Personally, for the 3-case assignment I would love to see one of the smarter pattern matching "match" expression proposals make it further along over the over-generalized "do expressions". Especially now that C# has pattern matching switch expressions.

    const isSomething = (() => {
        switch (...) {
            case ...:
                return ...
        }
    })()

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.

They want classes to be more unique than plain objects (when initially introduced, aside from easy extending via `extend`, they really weren't in practice). You can see it in their frameworks and how they do development. I'm not shocked those proposals get traction quickly because they come from the vendors themselves. I imagine internally their many thousands of engineers take advantage of these features. It just isn't as common (since `class` received a ton of backlash in the JS community mindshare with a broader move to functional style programming)

Records & Tuples on the other hand, came from Bloomberg (largely) and later Meta endorsed it. Unsurprisingly, it solves real problems they face. React (and anything that uses diffing today in the same manner) would be sped up dramatically if they could just `===` two objects vs what they do today. Yet this languishes, despite being a nearly universal upside for the average language user.

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.

Adding those features to an Object would still necessitate creating a new primitive.

At that point, you might as well make that primitive record that is directly available and just use the constructor to convert (just like you'd use `Number("123")`, you'd use `Record({my: "object"})`).

You can deep freeze the objects and freeze their prototypes.

  const first = #{a: 'b', c: 'd'};
  const second = #{a: 'b', c: 'd'};
  first === second // true

I suppose V8 for example could easily optimize records and tuples which are structurally equal into the same memory, then separate them into distinct memory blocks when they differ. This way an equality check could have the speed of an identity check if the two are known to be structurally equal.

I could be talking out of my ass here – maybe this isn't a performance concern at all and has been addressed far better already, and this is nonsense. But I do wonder how you'd quickly check for equality of, say, a large state tree to discover changes. On one hand that could be addressed by architecture. On the other, it is nice sometimes to simply know if two variables reference the same memory.

Doing this for plain arrays and objects has been said by the vendors for years to be too hard and possibly break alot of existing applications, and a new type for this purpose would need to be proposed. This is an answer to that. There isn't much to be semantically gained by allowing this on frozen objects, you'd need to do something identical to this anyway, from an engine perspective. Using a new syntax / types to represent it semantically makes it easier for developers to understand it too, I'd argue.

If you freeze those objects and their prototypes you get exactly your records. === becomes structural comparison that costs exactly the same as reference comparison.

I made something like that for my own purposes for very simple types like Point.

To implement this you'd just need to be able to turn contents of an object into a key for a map. I agree that it's probably better to do this rather in the VM than in the library.

    > 0 === -0
    true
    > #{v: 0} === #{v: -0}
    ???

I could see an argument for `0 == -0 && 0 !== -0`. It would have made it possible to say "if a === b, then a and b can use the same bitwise representation internally without losing information". But that's not what we have.

I guess for maximum consistency, we could use the 3rd JS equality operator `Object.is` with records, so that

    0 == -0
    0 === -0
    ! Object.is(0, -0)
    #{v: 0} == #{v: -0}
    #{v: 0} === #{v: -0}
    ! Object.is(#{v: 0}, #{v: -0})

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 idiosyncratic build tools and so on. And we would have had much less compatibility churn.

In fact this proposal here, is trivial to implement with macros. Clojure has the same thing (threading operator) and it's just a macro.

[0] https://en.wikipedia.org/wiki/Douglas_Crockford

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. It's actually a subset of a real standard (E4X -- actually implemented in Firefox for a long time), but just one relatively small syntax addition has added complexity elsewhere.

For example, `const foo = <T>(x:T) => x` is valid Typescript for a generic arrow function, but is an error if your file is using JSX.

I like the idea of macros, but I suspect they made the right call here.

[0] https://www.sweetjs.org/

Wouldn't that just trade compatibility churn against running the transpilers on client side in javascript, making it even slower to execute? Moving this part of the execution on the developer side seems like a good choice to me.

You can write macros that are very declarative but generate very hairy code that you wouldn’t necessarily write by hand. The result might be much more machine optimized.

Sure, you pay some upfront cost for expansion, but generally speaking macros don’t hinder you to write fast code, they just give you more options and trade offs.

Second, I only trust macros to people who are disciplined to use them wisely.

Third, I've met only a handful of developers I would consider disciplined in this way.

I think that what you said is true in an ideal world. Sadly, there are many developers who want to believe they are the disciplined ones, when in fact they are the trouble makers trying to inflate their ego at their team's/company's expense.

Along with discipline, there must be humility. Good luck finding that combination reliably.

That brings me to something I really want in JS, actual unmutable values. If you use `const x = new SomeClass()`, you cannot reassign it, but you can change fields. The first time I encountered `const`, I thought it did the opposite. It would be cool if you could declare something (object, array) to be an immutable value.

If you really want to introduce new operators, how about operator overloading? For example vector and matrix calculations become a lot clearer and less error-prone with infix operators. It should be technically easy to add them to typescript - rewrite the expression to a function call depending on the types of the operands - but the TS devs refuse to implement this on philosophical grounds unless it is implemented in JS. I guess in JS it would require runtime dispatch, but maybe that is not such a big penalty given that it usually uses a JIT anyway.

Oh, and while we are at it, fix `with`. The JS with statement is ridiculous and deprecated anyway. It makes all fields of an object available in it's scope. Contrast with VB6's `with`, which requires you to use a leading dot and is much more readable:

    with (elem.style) {
        .fontFamily = 'Arial';
        .color = 'red';
        console.log(.borderWidth);
        // in actual JS this would just be
        // console.log(borderWidth);
    }

Example:

  return (
    <div>
      {foo(bar(stuff))}
    </div>
  )

React's declarative model makes it easy to write unreadable spaghetti React declarations that are nested ten levels deep. Nobody should be adding features to JavaScript to encourage that.

("Please, I'm begging you, for the love of sanity... Refactor into more than one component. Just one time. Look, functional components even make that cheap and easy now. Please please please, just take some of that nesting and put it in a new component.")

> that's a symptom of issues with React, not issues with JavaScript

IMO keeping as much as possible in an expression-context is preferable, even without React, because it simplifies control-flow and avoids mutation. The main problem in this case, as I see it, is that javascript doesn't fully support that style- it could and should have a feature that allows intermediate constants (but not variables!) inside expressions. (It should also have something better than ternaries for expressive conditionals, but that's a separate topic)

> Refactor into more than one component

Plenty of ink has been spilled here in the past about splitting functions when there's a real conceptual boundary, not just when they "get too large", and how otherwise keeping your code together in one place can actually make it easier to follow because you don't have to jump around all over the place. So I don't really want to get into all that again here, but suffice to say that's my stance on the subject.

If you have some complicated expression to say inline in a React declaration, pull it up to the preparatory layer. If there are performance reasons not to do that, push it down into a subcomponent.

  return (
    <div>
      {(() => {
        const barStuff = bar(stuff);
        return foo(barStuff);
  })()}
    </div>
  )

It would be great if we had expression if..else too (instead of just the tertiary operator)

There's a proposal for precisely that. Unfortunately, only Stage 1 though.

https://github.com/tc39/proposal-do-expressions

Which seems fine. There's not an obvious gain to having one giant super-complex return statement.

Also sometimes you should just give stuff a temporary name, and treat React like a templating language.

  let foo = bar in <expression>

That sounds like a fundamental mis-understanding. Variables do not hold objects, they hold references to objects.

    const foo = {};
    let bar = foo;

If you want the object itself to be unmodifiable there's Object.freeze.

    const foo ...

    let foo = new const SomeObject()

So

    let foo = {field:1};
    immutable let bar = foo;
    bar.field = 2; // error
    foo.field = 3; // ok

(The inverse problem is when I have a function that takes something like a string or a number, and I want to change that from within the function. There is no way to pass a value type by reference. You have to encapsulate the value in an object and pass that. It would be cool if you could say something like `function double(ref x) { &x = x*2; }`.)

It could be worse. You could be in python that has no const whatsoever :P

I also agree pass by reference is useful. JavaScript only has pass by value, similar to python.

https://www.typescriptlang.org/docs/handbook/utility-types.h...

  const x = Object.freeze(new SomeClass())

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]

In the JS ecosystem, idiomatic nested function calls are read from the inside out. And in most cases that is highly readable because a single layer of nesting is all you need.

This proposal flips that on its head, so you have to retrain yourself to read code in a new way based on the presence of a |>. That adds significant cognitive overhead, especially in code that isn’t well written or that is already complex.

Your example looks nice, but also just as nice is the .then() syntax you could have used.

Now we’ll see code bases with both styles. You’ll have some team members who love pipes so much they’ll never call a function the old way doing x |> console.log and the rest of the team doing console.log(x).

Sometimes, limitations are a good thing.

Without something like that, trying to add error handling to the things which may blow up would instantly turn it into gibberish. Every single function here can fail (the HTTP request could fail, the data returned could be unparseable as JSON, or not have the right format). We should be trying to make our languages encourage us to write code which can handle those errors naturally, rather than encouraging us to write fragile code.

[0] https://fsharpforfunandprofit.com/rop/

    Uncaught TypeError: Cannot read properties of undefined (reading 'periods')

   :3,$s/\./?./g

``` foo(bar(baz(new_function(other_function())))) ```

They offer this example of an improvement:

``` other_function() |> new_function() |> baz() |> bar() |> foo() ```

While yes, pipes improve readability, how do they deal with errors? How do they deal with understanding what each thing is supposed to return?

I would prefer something like this, (descriptive variable names):

``` var userData = other_function();

var userDetails = new_function(userData);

var userComments = baz(userDetails);

var userPosts = bar(userComments);

var finalUserDetails = foo(userPosts);

return finalUserDetails; ```

Then I can easily debug each step, I can easily understand what each call is supposed to do, if I'm using type script, I can assign types to each variable.

I strongly oppose clean code for the sake of looking pretty, or being quick to type. Code is meant to be run and read more then written, it should be descriptive, it should describe what it's doing not a nasty chain of gibberish. Hence why most people hate REGEX.

But these variables are rarely the kind of thing it’s hard to name, so it feels like a slightly disingenuous argument.

Getting rid of the name moves the hard problem, rather than solve it

Once you have good function names, which you should generally be spending a lot more effort on than good local variable names, you won't find any value in adding variables like `var foo = get_foo()`.

A good language treats errors as a first class type. Functions that can error have no business returning an A.

Example given, the fetch API, is basically typed as fetch<A>(): Promise<A>

In reality, there might not be A at all, it should return a data type such as Either (or Result) which encodes linearly and forces the consumer to consider and handle the error.

I already use Maybe patterns quiet a bit in my TS project but there always the libraries and frameworks you work with that don't. So yeah I can see it being a language level thing (the way Promises were used) pushing for wide adoption.

    pipe(one, two, three)

Yes, there are some limitations in comparison to Hack Pipes. But those are far outweighed by not messing yet again with the language’s syntax.

In order for TypeScript to check if the return value of one function has the correct type for the next function, you need to use generics, but generics don't allow for a variable number of generic parameters, so `pipe` would just have to use unknown or have dozens of overloads for each length of pipe usage (within reason).

I know TypeScript is a different, optional language, and I see no reason why they couldn't add the feature without it being in JavaScript, but that's not generally how TypeScript operates. If JavaScript doesn't add it, TypeScript won't. There's also lots of tooling that will type check your JavaScript when available, which will benefit from a simpler model.

In absence of |> % syntax I'd nearly always would go with intermediate temporary variables instead of pipe(). "point-free" syntax feels horrible for me and wrapping everything in lambdas feels excessive.

We know so much more about how to create programming languages today than we did then, and the whole "Year of the Linux Desktop" has become a WebAssembly meme now every year since its introduction six years ago, with it getting popular always next year, next version, with feature XYZ. Seemingly creating unmaintainable/debuggable mess from external languages with no true 1:1 into WebAssembly isn't as big of a hit as the originators expected.

Yet every time someone asks why there hasn't been movement here it is "Year of WebAssembly is next year!!!" WebAssembly has managed to slow actual progression towards something good. With the browser monoculture you'd think it would be easier now than ever to start a fully integrated second language with WebAssembly compilation for backwards compatibility.

As for GP, you're right... there have actually been MANY attempts at other languages for in-browser. In the end, the JS runtime has been hardened and all other roads have led to WASM being the second target. I still remember a lot of people using VBScript in IE. I was an outlier in that I used JScript for classic ASP.

In the past you had Java applets, Silverlight and Flash. Compile-to-JS languages depend on rather than replace JavaScript, but it's about as close as you can get without being a browser developer. Chrome did originally intend Dart to be supported natively in the browser but eventually gave up that effort. Perhaps now Chrome is dominant to push it through without getting buy-in from Apple and Mozilla, but I doubt they have any interest now that there's WebAssembly.

Like it or not, WebAssembly is seen as the answer for additional languages in the browser. And for most developers JavaScript functions well enough as either a development language or compilation target.

Stuff like that takes time though, so if you're antsy, you have two options: get involved, or wait patiently.

Yew (Rust) is one that I've been following with interest, the hello world examples are interesting enough. I know people that have been liking the direction of Blazor (C#) more, but it has a larger initial payload, that I don't care for, it's also closer to SSR approach in the browser.

The problem with both, IMO, is that they don't have a good UI library/toolkit. I find mui.com (with React) pretty much the best browser ui framework I've experienced (since 1996). To me, the first language + component library that targets WASM and that level of components will likely win.

Flutter is probably the closest example I'm aware of, though afaik it's JS as the browser target, not WASM, but wouldn't be surprised if this changes assuming DOM interop for WASM becomes better performing.

The DOM in IE was essentially a COM API and callable from any supported scripting language. This included JScript (their JavaScript clone) but also VBScript and PerlScript.

Personally, I do think JS is a better fit than Rust or C for almost everything people do on the web. And the support in other languages is still too bad to use. But you can use it whenever you want, differently from a second language you may invent.

If we used a normal function we might have to include a library or a dependency or heck, just take 5 minutes and write a pipeline function oneself. Sure, it will not be syntactically as minimal as a _change of the language itself_ to allow pipelining, but at least it will not introduce even more language features and everyone can easily look at the definition change it or include it in their own projects.

Ideally we would strive for a minimalistic set of features, which in turn can implement anything we want. Adding more and more features, without introducing a way for the user to modify the language without a commitee and a lengthy process, seems short-sighted.

If you want to give the user more power over syntax, introduce a well engineered macro mechanism (plenty of examples in other languages) and let people develop standards and libraries as macros and libraries. Later on decide what to take into the standard language. Similar to how jQuery influenced modern JS standard functions like querySelectorAll. Even if you don't take something into the standard language, users are still free to include it in their project. No harm done and everyone gets their lunch and can scratch their itches.

Entire ecosystems like `fp-ts` or `effect-ts` are regularly used with pipeable APIs and no one beats an eye.

The only thing that was needed was a syntax that would've allowed this:

    pipe(
      "foo ",
      capitalize, // "FOO "
      trim, "FOO"
      shout, "FOO!"
      console.log, undefined
    )

      "foo "
      |> capitalize
      |> trim
      |> shout
      |> console.log

`console.log(shout(trim(capitalize("foo"))))` which is unnatural as you need to read the chain in reverse order and is especially hard in less trivial cases than a sequential string manipulation.

In an alternative universe, Unix shell syntax may have used “—“ instead of “|” for piping.

Maybe it has a place in other languages. I really don't want to see it in JS. We don't need more ways to do things implicitly or bass-ackwards from how they're actually behaving underneath. Syntactic sugar rarely makes code more readable. This operator only makes code seem more concise and as if it's executing in a way that it actually isn't.

I can absolutely see junior developers running wild with this kind of thing.

JS should be kept simple. This operator is not simple. It now makes understanding expressions more complicated. JS has its quirks and rough edges, but its power is in its simplicity. Please do not import the mistakes of other languages into JavaScript. If someone wants this operator, they should be forced to use a Babel transform or to compile their own JS interpreter.

OR just compile your favorite language runtime with the pipe operator to WASM.

For example:

    left |> right

    right(left)

    const myPipeline = @[
        one(@),
        @.two(),
        @ + three,
        `${@} four`
    ]

    const myPipeline = (value) => {
        const _1 = one(value);
        const _2 = _1.two();
        const _3 = _2 + three;
        const _4 = `${_3} four`;
        return _4
    }

    const myPipeline = (value) => `${one(value).two() + three} four`;

    const myPipeline = @it [
        one(@it),
        @it.two(),
        @it + three,
        `${@it} four`,
    ]