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 willful disregard for readable code was astonishing. The only tangible reason I could pull as to why they picked the least popular implementation despite all the outrage was "someone at google didn't like the function pipes". Even if you think we should avoid it because some google employee doesn't want it, that doesn't mean you should ram in an even worse implementation. I had to block the TC39 discussion because I was just going to get argumentative because they weren't listening at all, and they were dismissing actual concerns without any explanation.
Pipe Operator (|>) For JavaScript
211–220 of 437 posts
Re: Pipe Operator (|>) For JavaScript
#212I had a hard time rethinking decades of frontend projects where pipes would simplify code at least two times. However, in the backend please go ahead.
Having said that, can anybody provide an example with error handling per pipe?
You know servers are bitches :)
Re: Pipe Operator (|>) For JavaScript
#213Is 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…
All of the examples look unreadable and hard to debug to me. Why not something like this rather than one massive nested instruction? let keys = Object.keys(envars); let text = keys.map(envar => `${envar}=${envars[envar]}`).join(" "); console.log(chalk.dim(`$ ${text}`), "node", args.join(' ')); That way you can easily inspect and verify the intermediate values at runtime. Helpful for you to see if your code works as e…
Bad examples can doom a project. It's amazing how much time people can spend on a solution while completely ignoring the documentation.
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.
Re: Pipe Operator (|>) For JavaScript
#214JavaScript isn't that kind of programming language. I don't know why people are constantly trying to make it something else.
There is an increasingly large population of "programmers" that have never known anything other than Javascript and don't understand the concept of "different languages for different purposes". They want Javascript to do everything so they don't have to leave their comfort zone.
I can't say I blame us, as its the utility lingua franca for UIs, especially with cross platform UIs via React Native or NativeScript.
Web browsers are a long ways off from WASM being acceptable as an alternative in most cases, as it yet can't access the DOM directly.
Its not that we don't understand different languages for different purposes, its more what real alternative do we have here and if we want certain features in the language we have to follow the process to get them.
Re: Pipe Operator (|>) For JavaScript
#215Saw 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?
Re: Pipe Operator (|>) For JavaScript
#216I love the pipe operator in Elixir, but I've never really wanted it in JS. It's critical in Elixir because the design of the runtime (immutability, functions only, no methods). In the rare cases that you might need it, like their three(two(one(value))) example, function composition is available from libraries or easy to do yourself.
It's just my opinion, but I think turning JS into a kitchen sink of language features is a mistake.
Re: Pipe Operator (|>) For JavaScript
#217Saw 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…
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.
Re: Pipe Operator (|>) For JavaScript
#218Anyone doing data analysis knows the value of a pipe.
Re: Pipe Operator (|>) For JavaScript
#219I know I'm in the minority, but I dislike both version of the syntax, since I think chained code is almost always worse than just being forced to use intermediary variables for everything.
While it's fine to say Object.entries().map(), anything more is not only harder to read, but makes debugging and maintenance more difficult.