I played with coconut recently (fp layer on top of python) and the `|>` syntax felt very annoying compared to `.` (even though it felt ok in Ocaml..)
But in an OO underlying language it's probably impossible to reuse it.
Pipe Operator (|>) For JavaScript
261–270 of 437 posts
Re: Pipe Operator (|>) For JavaScript
#262Earlier quoted context omitted.
I struggle to think of real-world examples where I've just needed to chain and chain and chain values of different types more than a handful of times. The claimed need for the pipe operator is this construction: function bakeCake() { return separateFromPan(coolOff(bake(pour(mix(gatherIngredients(), bowl), pan), 350, 45), 30)); } The piped code looks like: function bakeCake() { return gatherIngredients() |> mix(%, bow…
How about function bakeCake() { return do( () => gatherIngredients(), ingredients => mix(ingredients), batter => pour(batter, pan), batterInPan => bake(batterInPan, 350, 45), () => coolOff(bakedInPan), cooledCake => separateFromPan(cooledCake) ); }
...which is just
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
);
}Re: Pipe Operator (|>) For JavaScript
#263Earlier 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…
You've confused method chaining and nesting. The proposal itself says that method chaining is easier to read, but limited in applicability, while it says deep nesting is hard to read. The argument against the proposal by the GP comments is that temporary variables make deep nesting easier to read and do it better than pipes would.
Re: Pipe Operator (|>) For JavaScript
#264Cool 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…
Kotlin uses "it" as the name of the implicit arg in lambdas. Makes things very readable imo:
``` listOf(1, 3, 5).map { it * 100 } ```
Re: Pipe Operator (|>) For JavaScript
#265JavaScript isn't that kind of programming language. I don't know why people are constantly trying to make it something else.
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.
Re: Pipe Operator (|>) For JavaScript
#266Earlier quoted context omitted.
The intermediary names are extremely relevant to the next poor sucker who has to understand what you were trying to do. Code is read far more than it is written. Use temporary variables. Put in the effort to name them once, and then that effort pays back every time anyone needs to read and understand the code.
> The intermediary names are extremely relevant to the next poor sucker who has to understand what you were trying to do. I just don't think that this is always true. Consider: const highestScore = players |> filter(x => x.isAlive) |> map(x => x.score) |> tryMax I don't see how this is better: const alivePlayers = filter(x => x.isAlive)(players); const scoresOfalivePlayers = map(x => x.score)(alivePlayers); const hig…
> 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.
Re: Pipe Operator (|>) For JavaScript
#267Is 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…
They're all horrific
Re: Pipe Operator (|>) For JavaScript
#268Earlier quoted context omitted.
It's annoying to have to decide on and write out so many names. The intermediary names are not relevant to solving the problem. This is so much less noisy: value |> one |> two |> three
It's only less noisy because of the simplistic nature of the example. In real world code, `one`, `two` and `three` and probably a chunk of code put together in a single line and it's difficult to find out what the hell they are doing. Concat together a few of these and that's a recipe for disaster. Less experienced engineers would add a comment at the top of the pipe chain explaining what's going on. More experienced…
Agreed. I'm not the one coming up with the one/two/three, I took it from the proposition.
Explanatory variables help understand the steps of the process, this |> operator is receipe for unmaintainable, expedited code.
Re: Pipe Operator (|>) For JavaScript
#269I don't understand why you can't just use temporary variables. The article mentions mutation is bad, but what actually happens is that the name gets reassigned. No value is mutated. 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 w…
A problem is that you can only declare intermediate constants in a statement context, not an expression context. And with React, more and more JS devs are spending time in expression contexts Example: return ( {foo(bar(stuff))} ) There's no way to break out inline intermediate constants here; you have to bail out and do it up above the `return`. In this case that may not be too bad, but when you've got a hundred line…
The way to fix that then would be to introduce a way to create named values within an expression. E.g. have something like
let foo = bar in
Re: Pipe Operator (|>) For JavaScript
#270Earlier quoted context omitted.
I would propose -> instead of |>
but then is not a pipe!
It’s a horizontal pipe. It arguably actually makes more sense when the values flow horizontally from left to right through the pipe.
In an alternative universe, Unix shell syntax may have used “—“ instead of “|” for piping.