Hacker News Reader

Comment by pmontra | Hacker News Reader

Unfortunately all those

    .flatMap(_.wrapCallback(one))
    .flatMap(_.wrapCallback(two))
    ...

    .then(Promise.promisifyAll(one))
    .then(Promise.promisifyAll(two))
    ...

are noise making the signal difficult to read. It should come down to nothing more than

    one | two

plus the error handling clause. That's not JavaScript but you got the idea. Syntax is important. I still have bad dreams about arrays() hell in an app written by a customer with CakePHP 1 (a Rails clone with an approach that didn't suit PHP well). I'll skip over the $this-> mess.

I'm not much into asynchronous languages. Is there any examples around with a built in and slim syntax for concatenating callbacks? Thanks.

View on HN

In Haskell it would be

    do one
       two

because it's pretty well understood there that syntax can be a big differentiator.

What's more is that this syntax adopts for the binding aspect of flatMap. So if two is dependent on one...

    do output <- one
       two output

which is a shortcut for

    one >>= two

which might be

    Promise.promisifyAll(one)
    .then(function (output) {
       return Promise.promisifyAll(two(output)) 
    })

in Javascript

Haskell has the advantage that what you've proposed is an exact conversion of the "flatMap" code, meaning that anything else that you can do with flatMap can be used with do notation, which is a lot of things beyond just tying two bits of IO code together.

But in this specific case of just tying two bit of execution together, I'd observe that Erlang is

    One(),
    Two()

and Go would be

    One()
    Two()

and that's all regardless of whether One and Two have 0 accesses to IO or do IO dozens of times, and One and Two may also freely call other functions that do arbitrary IO with no further ceremony. The "solution" Erlang and Go offer to callback hell is simply not to have it, and pretty much no matter how you slice it, not having the problem in the first place beats any solution the JS community may or may not settle on.

That's completely fair and accurate. The challenge is handling the genuine concurrency model then, but both Go and Erlang have good tools for doing just that.

So it kind of comes down to whether you want to shave off ceremony for concurrency or for all monadic/sequencing operations at once. Honestly, that's a tradeoff.

> I'm not much into asynchronous languages. Is there any examples around with a built in and slim syntax for concatenating callbacks? Thanks.

Yeah it's called any language that offers good abstractions for concurrency. Elixir/Erlang, Haskell, Clojure and Go are a few good examples.

I played a little with Elixir (and Phoenix) months ago and I know the |> operator, which is not exactly what I was looking for in my reply. I'll look again at Elixir and at how it handles callbacks.

There aren't any callbacks in Elixir. The run time takes care of scheduling for you. The code you write looks synchronous but is executing asynchronously.

Not only does this make your code easier to read, it also means that the entire ecosystem is available to you rather than a partitioned between sync and async libraries.

|> is (not, see below) mere function composition

    function compose(f, g) {
      return function inner(x) {
        return f(g(x));
      }
    }

this is not the right kind of composition for something like nested callbacks. For that you need slightly more.

Edit:

It's actually the "apply" operator which looks like

    function apply(f) {
      return function applied(x) {
        return f(x);
      }
    }

Apply and compose work together nicely. For instance, in Haskell apply is ($) and compose is (.), so you can build a compositional pipeline and apply it like

    f . g . h $ x

or like

    f $ g $ h $ x

since association goes this way

    f $ (g $ (h $ x))

Deleted comment

Ah, my bad, I was distracted writing. It's Haskell's ($), not the (.).

No worries. I deleted my post before your reply came through because I didn't feel my example was good and I'm struggling to do better this early in the morning :D

In a lot of cases compose and |> will be similar due to operations that are commutative, but they are semantically different.

Rust is also worth a mention as one to watch.

Recently Rust removed libgreen from their standard library and went back to native threading so that users can choose and build their own abstractions. So as a language by itself Rust doesn't have a ton of concurrency abstractions but the community appears to be working hard creating concurrency abstractions and I'm sure it's only a matter of time.

To expand on this a bit, while they went back to native threading, they didn't ditch any of the type system and library work designed to make message passing convenient and memory safe, which is (arguably) more fundamentally important for concurrency than M:N threading.

Great point. I just meant in the context of the languages I cited Rust doesn't offer similar abstractions.

Yeah not disagreeing with you at all. It doesn't work the same way "concurrency-focused languages" generally work right now, but it does share the message-passing philosophy with them. Interestingly, I heard a rumor that Go is considering moving to 1:1 threading on Linux, which would align it with Rust's current approach, just without the memory protection capabilities of the type system (though I have no idea whether or not this is true).

C# has the 'await' keyword, which is pretty clean.

If you're dealing with vanilla node.js streams, you can just do:

   one.pipe(two)

Reply on news.ycombinator.com