4 ms·

This just complicates things if you have any kind of complex nesting. Something "simple" like: a(b(),c(),d(e(),f(g()))) Turns into the following: valu

This just complicates things if you have any kind of complex nesting. Something "simple" like: a(b(),c(),d(e(),f(g()))) Turns into the following: value |> b() |> a( %, c() , v2 |> e() |> d(%, v1 |> g() |> f(%) ))

aabhay 4y ago
Not to mention the confusion of nested percent vars
scotty79 4y ago
Nope, it becomes: g() |> f(%) |> d(e(), %) |> a(b(),c(), %) Which makes super clear what processing is actually done. Which is the data to process and which are just parameters of processing. Because it could equivalently be: e() |> d(%,f(g())) |> a(b(),c(), %) If the data you process is rather produced by e() not by g(). This new syntax allows you to express intent beyond what's possible without it.
- _boffin_ 4y ago
  If i saw that in a colleague's code, i'd be angry at them as that's not legible.
  - scotty79 4y ago
    It's no less legible than original code and at least expresses the intent of what's being processed, what are the processing steps and what are processing parameters. a(b(),c(),d(e(),f(g()))) is just function call soup.
    - yamtaddle 4y ago
      At least I can instantly tell which call is ultimately returning something, in that version.
      - scotty79 4y ago
        There's nothing preventing you from not using the pipe for last call or even introducing that rule in your team if you can convince your colleagues it's a good idea or even automate it with the use of a linter. If it's really good rule you can advocate for it at this stage. It might be prudent to use |> % only inside function call parameter or possibly as right hand of an assignment instead of everywhere where parser expects an expression. a(b(),c(), g() |> f(%) |> d(e(), %)) Although I'll be honest, I don't like it. Other parameters of a() call for me occlude the flow and the intent. We could make it a bit better with newlines. a(b(),c(), g() |> f(%) |> d(e(), %)) ) But if a() takes more parameters after the main one then we have the same problem as usual where parts of the same call can end up far away from one another. a(b(),c(), g() |> f(%) |> d(e(), %)) x(), y(), z()) For me g() |> f(%) |> d(e(), %)) |> a(b(), c(), %, x(), y(), z()); is still better and I wouldn't want it to be prevented by language syntax.
        yamtaddle 4y ago
        That's almost worse. I think I'd have to break out pen and paper to figure out which of those things end up returning arguments to function "a".
        scotty79 4y ago
        I agree that such restriction would make it worse.
    - _boffin_ 4y ago
      And I’d be angry if I saw that too. Break out the soup into variables and have it all be In a clean layout
      - coffeebeqn 4y ago
        Use a functional language if you want to chain 10 functions together! I would definitely tell them in the PR to stop being clever and rewrite it
- tgv 4y ago
  Except that the order of evaluation is different now. Side effects? Who cares.

aabhay 4y ago

Not to mention the confusion of nested percent vars

scotty79 4y ago

Nope, it becomes: g() |> f(%) |> d(e(), %) |> a(b(),c(), %) Which makes super clear what processing is actually done. Which is the data to process and which are just parameters of processing. Because it could equivalently be: e() |> d(%,f(g())) |> a(b(),c(), %) If the data you process is rather produced by e() not by g(). This new syntax allows you to express intent beyond what's possible without it.

_boffin_ 4y ago
If i saw that in a colleague's code, i'd be angry at them as that's not legible.
- scotty79 4y ago
  It's no less legible than original code and at least expresses the intent of what's being processed, what are the processing steps and what are processing parameters. a(b(),c(),d(e(),f(g()))) is just function call soup.
  - yamtaddle 4y ago
    At least I can instantly tell which call is ultimately returning something, in that version.
    - scotty79 4y ago
      There's nothing preventing you from not using the pipe for last call or even introducing that rule in your team if you can convince your colleagues it's a good idea or even automate it with the use of a linter. If it's really good rule you can advocate for it at this stage. It might be prudent to use |> % only inside function call parameter or possibly as right hand of an assignment instead of everywhere where parser expects an expression. a(b(),c(), g() |> f(%) |> d(e(), %)) Although I'll be honest, I don't like it. Other parameters of a() call for me occlude the flow and the intent. We could make it a bit better with newlines. a(b(),c(), g() |> f(%) |> d(e(), %)) ) But if a() takes more parameters after the main one then we have the same problem as usual where parts of the same call can end up far away from one another. a(b(),c(), g() |> f(%) |> d(e(), %)) x(), y(), z()) For me g() |> f(%) |> d(e(), %)) |> a(b(), c(), %, x(), y(), z()); is still better and I wouldn't want it to be prevented by language syntax.
      - yamtaddle 4y ago
        That's almost worse. I think I'd have to break out pen and paper to figure out which of those things end up returning arguments to function "a".
        scotty79 4y ago
        I agree that such restriction would make it worse.
  - _boffin_ 4y ago
    And I’d be angry if I saw that too. Break out the soup into variables and have it all be In a clean layout
    - coffeebeqn 4y ago
      Use a functional language if you want to chain 10 functions together! I would definitely tell them in the PR to stop being clever and rewrite it
tgv 4y ago
Except that the order of evaluation is different now. Side effects? Who cares.