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

341–350 of 437 posts

Re: Pipe Operator (|>) For JavaScript

#341

Post by [deleted] »

sfink wrote: post #331
scotty79 wrote: post #292

Earlier quoted context omitted.

You could create class that keeps static Map with references to all created objects of given type. On creation it would check if structurally same object was already created and return reference to previous instance instead of creating a new one. 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…

I believe this approach was proposed, but implementers pushed back because the initial interning is expensive and there are a lot of scenarios where it would never be used. You don't really expect creating a Point to do a hash lookup.

[deleted]

Re: Pipe Operator (|>) For JavaScript

#342

Post by scq »

sfink wrote: post #332
scotty79 wrote: post #227

Earlier quoted context omitted.

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…

Sadly, JS weirdness interferes with value semantics: > 0 === -0 true > #{v: 0} === #{v: -0} ???

That's not a JS thing, 0 and -0 comparing as equal is specified in the IEEE 754 floating point standard.

Re: Pipe Operator (|>) For JavaScript

#344

Post by 8note »

greggman3 wrote: post #239
notdonspaulding wrote: post #132

Earlier quoted context omitted.

Exactly. As the proposal contemplates this alternative, it claims: > 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…

and yet looking through code from the place you work I see something like this let field = ve.instanceContext.replace(/(#\/)|(#)/ig, "").replace(/\//g, ".") Which you apparently claim should be const fieldWithHashMarksUnesacped = ve.instanceContext.replace(/(#\/)|(#)/ig, ""); const field = fieldWithHashMarksUnesacped.replace(/\//g, ".") https://github.com/mirusresearch/firehoser/blob/46e4b0cab9a2... and this return m…

I like that the expected variable name has a typo.

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

Re: Pipe Operator (|>) For JavaScript

#345

Post by pcthrowaway »

arp242 wrote: post #254
dns_snek wrote: post #200

Earlier quoted context omitted.

Extracting `envStr` is definitely the highest impact change for me. I dislike temporary variables too when they don't represent a meaningful intermediary result, but in this case I see them as a lesser evil. I agree that `styled` is more about personal preference. This is why I'm happy to see the pipe syntax proposal, it avoids unnecessary temporary variables while simultaneously aiding readability.

> 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 t…

> I do have to admit I never worked with a language that uses |>

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

Re: Pipe Operator (|>) For JavaScript

#346

Post by arp242 »

whstl wrote: post #245
arp242 wrote: post #169

Earlier quoted context omitted.

I dislike variables that are used just once. Sometimes they're a "necessary evil", but rarely. For "envStr" it's defensible IMHO as it splits up some of the complexity, but I would rather just use a helper function, which has the same "splits complexity" effect and is re-usable. "styled" seems entirely pointless here.

This actually surprises me! 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('…

I just find it easier "thing" that happens is one self-contained statement, if that makes sense. Makes it easier to see what does what. I don't think one way is "better" or "worse" btw; all I can say to my brain, I find it harder to follow. This is what can make programming in a team hard.

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.

Re: Pipe Operator (|>) For JavaScript

#347

Post by masswerk »

masswerk wrote: post #203

I don't think that it's a good idea to introduce a left-to-right flow into a language, which strictly assigns righthand values by general design. The text mentions a back-and-forth in reading, this introduces a back-and-forth intellectually. (There's already a limited left to right capability, namely by chaining expressions using logical operators, especially when used outside of condition. It should be mentioned, ho…

  !(funcA(transferObject) || true) || !(funcB(transferObject) || true) ...
  // ceci n'est pas une pipe

  function pipe(func, obj) {
    return !(func(obj) || true);
  }
  pipe(funcA, transferObject) || pipe(funcB, transferObject) ...
  // cecie n'est pas une pipe non plus

  function pipeB(func, obj) {
    func(obj);
    return 0 | 0;
  }
  pipeB(funcA, transferObject) | pipeB(funcB, transferObject) ...
  // no more pipes, please!
 
  funcA(transferObject), funcB(transferObject) ...
  // finally...
;-)

Re: Pipe Operator (|>) For JavaScript

#348

Post by 8note »

jameshart wrote: post #273
snow_mac wrote: post #271

I * HATE* pipes. For example from Elixir School ( https://elixirschool.com/en/lessons/basics/pipe_operator ): ``` 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 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

Re: Pipe Operator (|>) For JavaScript

#349

Post by arp242 »

pcthrowaway wrote: post #345
arp242 wrote: post #254

Earlier quoted context omitted.

> 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 t…

> I do have to admit I never worked with a language that uses |> Have you never worked with Bash? It's basically the same thing

Indeed it is, but it's kind of a different context than a "real" programming language. What works for one doesn't necessarily work well for the other.
Post reply on HN