4 ms·

I pity the guy who has to debug a code base full of: let newScore = fetch(url) |> await # |> #.json() |> await # |> #.ID;

frabert 7y ago
I don't know, it seems pretty clear to me. It beats doing let newScore = (await (await fetch(url)).json()).ID and no, a myriad of intermediate variables is not always a nice alternative. This syntax gives a clear view of what happens to the data without having to untangle deeps expressions. I like it.
- dmitriid 7y ago
  The page shows a much more clear and readable alternative, F# pipelines: let newScore = fetch(url) |> await |> r => r.json() |> await |> obj => obj.ID;
  - Klathmon 7y ago
    Wouldn't this be a lot easier to understand and work with? let newScore = await fetch(url) .then(r => r.json()) .then(obj => obj.ID) I think another problem is that these are just examples that aren't necessarily representative of real-life use cases but more just try to show all the different ways of using the syntax in one small chunk.
    - dmitriid 7y ago
      Yes, in this particular case `then` works better. Pipes are a very generic pattern though, and are quite useful when you have a chain of operations (whether those operations are async or not).
    - ulucs 7y ago
      That example is wrapped perfectly, so it seems a bit unneeded. A more complex example would be // helper for method calls in pipes const _ = new Proxy({}, {get(_i, c) { return (...args) => e => e[c](...args)}}) document .querySelectorAll('.requestedIds') |> Array.from |> _.map(el => fetch(`//address/${el.value}`)) |> Promise.all |> await |> _.map(re => re.json()) |> Object.fromEntries |> processResponse In this case, there is both methods and function calls, which complicates reading quite a bit. Converted to pipes, it's simply from top to bottom.
      - spion 7y ago
        I'd like to see the type signature of that `_` construct. It seems to me like the bind operator would've made the extra complexity unnecessary.
        ulucs 7y ago
        _.map is basically syntatic sugar for p => p.map, only written with today's javascript capabilities. I just tried to implement the proposed #. Dynamic access to methods doesn't yield very nice type signatures.
      - Klathmon 7y ago
        But reading it like this I greatly prefer the F# style since it reads a lot more straightforward and easy to understand what is happening. That being said, can't you abuse the promise syntax to get something very similar right now? Since `.then` will wrap a non-promise return value in a promise, this would do the same as your example: Promise.resolve(document.querySelectorAll('.requestedIds')) .then(p => Array.from(p)) .then(p => p.map(el => fetch(`//address/${el.value}`))) .then(p => Promise.all(p)) .then(p => p.map(re => re.json()) .then(p => Object.fromEntries(p)) .then(p => processResponse(p)) But funnily enough, as I went to go write out that example, I realized that I have no idea what the hell is being passed into the `_.map` functions... Even me being lazy and using `p` as the variable name for each pipe, the version that writes it out is massively easier to understand in my opinion.
  - darepublic 7y ago
    Hopefully there will be no issue adding a breakpoint to see the structure of obj, a common debugging necessity
    - dmitriid 7y ago
      Chrome dev tools let you put breakpoints inside promises, and debug promises in general. I guess they'll update the tools to let you set breakpoints inside pipes (at least I'm hoping so :) )
- omegaworks 7y ago
  How does it read in your internal monologue? "await pound" doesn't convey a whole lot of semantic meaning to me. I'm curious how others read it.
  - adrusi 7y ago
    Perl programmers read "$_" as "it". So you could read the expression above as "fetch url, then await it, then get its json then await it, then get its ID" Although I don't know why a syntax needs to be verbally legible, seems like an odd requirement to me.
    - omegaworks 7y ago
      There's a reason why Pearl is considered a write-only language. Programming languages typically opt for either verbal legibility or having their symbols represent some understood structural / visual cue (like an arrow, for example). There's nothing about the character "#" that indicates the directionality of the operation visually, so I assumed there was some verbal mapping that I wasn't familiar with. ("Hash", "pound", "number", etc). Typically programming languages are used to communicate procedures in ways that would allow human people with a similar set of cultural references to understand what is going on by reading it. Having verbal legibility allows people who know the language to explain very quickly to new people what is meant by a given symbol. Otherwise why #? It could be any symbol. Communicating meaning for humans might not be the intent for javascript moving forward, given where WASM and transpilation is headed, so :shrug:
gforge 7y ago
The pipe operator has was introduced to R a few years ago. It is one of those things I miss the most in js. Debugging is an issue though. I commonly find myself splitting up the pipes into section in order to inspect the results and find exceptions. Breakpoints and stepping through code is probably the features I most often struggle with.
coldtea 7y ago
You should pity people debugging very different constructs than this. This is clear as day, and I haven't even read the proposal...
- sametmax 7y ago
  I never said understanding, I said debugging. There are 4 implicit objects here (discounting proxies and wrappers), so unless you know them by heart, you have now idea what's in there. Then of course most debuggers will consider that one line, so to debug, you will hall have to split it in several ones to have the right to know what's going on. Plus, now that you have done it, what ? You put them back as they were ? That's also hoping your code map files and your browser work well together, which is often not the case. Transpiled code is always a pain to debug at one point or another. And that's just one line, a code back "full of those" will let you do the dance again and again. A very slow dance at that, cause babel is not the fastest horse in town. Finally I'll pray your intern doesn't have to do it. But we all have teams full of good programmers right ?
- conradfr 7y ago
  But that's wishful thinking, you could be wrong about what that code does.
  - coldtea 7y ago
    Not really. There's no magic in the code, it's a pretty well established construct, used in other languages for decades...

frabert 7y ago

I don't know, it seems pretty clear to me. It beats doing let newScore = (await (await fetch(url)).json()).ID and no, a myriad of intermediate variables is not always a nice alternative. This syntax gives a clear view of what happens to the data without having to untangle deeps expressions. I like it.

dmitriid 7y ago
The page shows a much more clear and readable alternative, F# pipelines: let newScore = fetch(url) |> await |> r => r.json() |> await |> obj => obj.ID;
- Klathmon 7y ago
  Wouldn't this be a lot easier to understand and work with? let newScore = await fetch(url) .then(r => r.json()) .then(obj => obj.ID) I think another problem is that these are just examples that aren't necessarily representative of real-life use cases but more just try to show all the different ways of using the syntax in one small chunk.
  - dmitriid 7y ago
    Yes, in this particular case `then` works better. Pipes are a very generic pattern though, and are quite useful when you have a chain of operations (whether those operations are async or not).
  - ulucs 7y ago
    That example is wrapped perfectly, so it seems a bit unneeded. A more complex example would be // helper for method calls in pipes const _ = new Proxy({}, {get(_i, c) { return (...args) => e => e[c](...args)}}) document .querySelectorAll('.requestedIds') |> Array.from |> _.map(el => fetch(`//address/${el.value}`)) |> Promise.all |> await |> _.map(re => re.json()) |> Object.fromEntries |> processResponse In this case, there is both methods and function calls, which complicates reading quite a bit. Converted to pipes, it's simply from top to bottom.
    - spion 7y ago
      I'd like to see the type signature of that `_` construct. It seems to me like the bind operator would've made the extra complexity unnecessary.
      - ulucs 7y ago
        _.map is basically syntatic sugar for p => p.map, only written with today's javascript capabilities. I just tried to implement the proposed #. Dynamic access to methods doesn't yield very nice type signatures.
    - Klathmon 7y ago
      But reading it like this I greatly prefer the F# style since it reads a lot more straightforward and easy to understand what is happening. That being said, can't you abuse the promise syntax to get something very similar right now? Since `.then` will wrap a non-promise return value in a promise, this would do the same as your example: Promise.resolve(document.querySelectorAll('.requestedIds')) .then(p => Array.from(p)) .then(p => p.map(el => fetch(`//address/${el.value}`))) .then(p => Promise.all(p)) .then(p => p.map(re => re.json()) .then(p => Object.fromEntries(p)) .then(p => processResponse(p)) But funnily enough, as I went to go write out that example, I realized that I have no idea what the hell is being passed into the `_.map` functions... Even me being lazy and using `p` as the variable name for each pipe, the version that writes it out is massively easier to understand in my opinion.
- darepublic 7y ago
  Hopefully there will be no issue adding a breakpoint to see the structure of obj, a common debugging necessity
  - dmitriid 7y ago
    Chrome dev tools let you put breakpoints inside promises, and debug promises in general. I guess they'll update the tools to let you set breakpoints inside pipes (at least I'm hoping so :) )
omegaworks 7y ago
How does it read in your internal monologue? "await pound" doesn't convey a whole lot of semantic meaning to me. I'm curious how others read it.
- adrusi 7y ago
  Perl programmers read "$_" as "it". So you could read the expression above as "fetch url, then await it, then get its json then await it, then get its ID" Although I don't know why a syntax needs to be verbally legible, seems like an odd requirement to me.
  - omegaworks 7y ago
    There's a reason why Pearl is considered a write-only language. Programming languages typically opt for either verbal legibility or having their symbols represent some understood structural / visual cue (like an arrow, for example). There's nothing about the character "#" that indicates the directionality of the operation visually, so I assumed there was some verbal mapping that I wasn't familiar with. ("Hash", "pound", "number", etc). Typically programming languages are used to communicate procedures in ways that would allow human people with a similar set of cultural references to understand what is going on by reading it. Having verbal legibility allows people who know the language to explain very quickly to new people what is meant by a given symbol. Otherwise why #? It could be any symbol. Communicating meaning for humans might not be the intent for javascript moving forward, given where WASM and transpilation is headed, so :shrug:

gforge 7y ago

The pipe operator has was introduced to R a few years ago. It is one of those things I miss the most in js. Debugging is an issue though. I commonly find myself splitting up the pipes into section in order to inspect the results and find exceptions. Breakpoints and stepping through code is probably the features I most often struggle with.

coldtea 7y ago

You should pity people debugging very different constructs than this. This is clear as day, and I haven't even read the proposal...

sametmax 7y ago
I never said understanding, I said debugging. There are 4 implicit objects here (discounting proxies and wrappers), so unless you know them by heart, you have now idea what's in there. Then of course most debuggers will consider that one line, so to debug, you will hall have to split it in several ones to have the right to know what's going on. Plus, now that you have done it, what ? You put them back as they were ? That's also hoping your code map files and your browser work well together, which is often not the case. Transpiled code is always a pain to debug at one point or another. And that's just one line, a code back "full of those" will let you do the dance again and again. A very slow dance at that, cause babel is not the fastest horse in town. Finally I'll pray your intern doesn't have to do it. But we all have teams full of good programmers right ?
conradfr 7y ago
But that's wishful thinking, you could be wrong about what that code does.
- coldtea 7y ago
  Not really. There's no magic in the code, it's a pretty well established construct, used in other languages for decades...