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

431–437 of 437 posts

Re: Pipe Operator (|>) For JavaScript

#431

Post by kbp »

8note wrote: post #348
jameshart wrote: post #273

Earlier quoted context omitted.

I think there is merit to the argument that if naming is one of the hard problems , programmers writing that code are having to do a lot of ‘naming’ and that is hard for them. The proposed pipe operation eliminates those names and lets the programmer just use %. But these variables are rarely the kind of thing it’s hard to name, so it feels like a slightly disingenuous argument.

Naming is hard because names are useful. Getting rid of the name moves the hard problem, rather than solve it

Usually that effort should go toward naming functions rather than their results, though, and if the functions have good names, the results don't need them. In this example, `other_function` could have been named `get_user_data`, `new_function` could have been called `extract_user_details`, whatever.

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

Re: Pipe Operator (|>) For JavaScript

#432

Post by whstl »

dns_snek wrote: post #107
arp242 wrote: post #27

Is this: Object.keys(envars) .map(envar => `${envar}=${envars[envar]}`) .join(' ') |> `$ ${%}` |> chalk.dim(%, 'node', args.join(' ')) |> console.log(%); Really better than: console.log(chalk.dim( `$ ${Object.keys(envars) .map(envar => `${envar}=${envars[envar]}`) .join(' ') }`, 'node', args.join(' ') )); That's the real-world example they have (I reformatted the second one slightly, because it looks better to me). N…

I won't speak about the specifics of the chosen syntax (Hack/F#) but in general - absolutely. 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 m…

Late reply, but I find that with a bit more of modernizing, and more consistent usage of chalk's arg-concatenation feature this can be turned into something much terser:

  const envs = Object.entries(envars).map(entry => entry.join('='));
  console.log(chalk.dim('$', ...envs, 'node', ...args));
I don't really have a point to make, perhaps just that there's often simplifications possible with extra creativity.

Re: Pipe Operator (|>) For JavaScript

#433

Post by prmph »

chadlavi wrote: post #265
prmph wrote: post #46

Earlier quoted context omitted.

But clearly we need "that kind of programming language" for rich client web apps. We need many of the modern language constructs in such a language. Would you advocate for an entirely new language to meet that need?

This is perhaps a controversial opinion, but I don't think that you need this at all to do programming. This is just syntactic sugar! Type some parentheses and move on.

Then we might as well give up async/await, promises, generators, recursion, null coalescing, and more.

After all, they are all “syntactic sugar”, right?

Re: Pipe Operator (|>) For JavaScript

#434

Post by gorjusborg »

dgb23 wrote: post #217
gorjusborg wrote: post #193

Earlier quoted context omitted.

First, syntactic macros are great, and I've often wished for them to exist in javascript (and other languages). 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.

People who write widely used macros are typically of that last category.

I've been thinking about your response since you left it.

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.

Re: Pipe Operator (|>) For JavaScript

#435

Post by aabbcc1241 »

arp242 wrote: post #27

Is this: Object.keys(envars) .map(envar => `${envar}=${envars[envar]}`) .join(' ') |> `$ ${%}` |> chalk.dim(%, 'node', args.join(' ')) |> console.log(%); Really better than: console.log(chalk.dim( `$ ${Object.keys(envars) .map(envar => `${envar}=${envars[envar]}`) .join(' ') }`, 'node', args.join(' ') )); That's the real-world example they have (I reformatted the second one slightly, because it looks better to me). N…

Within the current js syntax, you can make the code looks readable with a chain or pipe with a simple function https://github.com/beenotung/tslib/blob/master/src/pipe.ts

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))
In each step, you can name the intermediate result accordingly to it's meaning, should be more readable than calling it %

Re: Pipe Operator (|>) For JavaScript

#436

Post by ljharb »

zackmorris wrote: post #173

Cool stuff, but I miss the "it" variable from HyperTalk (the language used by HyperCard) which contained the result of prompts to the user. Just search for "The it variable": http://www.jaedworks.com/hypercard/HT-Masters/scripting.html ask "How many minutes do you want to play?" put it * 60 into timeToPlay -- convert it into seconds Today we could have a reserved keyword that holds the result of the last statement ex…

it, _, result, and $ are all valid identifiers already; the only choices would have to be syntax errors currently.

Re: Pipe Operator (|>) For JavaScript

#437

Post by substation13 »

dalmo3 wrote: post #401
charles_f wrote: post #266

Earlier quoted context omitted.

> I don't see how this is better Case in point: > you can add helpful comments to pipeline code if needed The pipeline with explanatory variables explain to you what the steps are with code . Using pipeline you need to add comments to explain "what" you are doing.

And then it's a pleasure to open the debugger and immediately see the values for each step.

If pipes are added to JS then IDE support will follow very swiftly.
Post reply on HN