[chrisdotcode]

What's interesting is that all of the 'niceness' seen is the result of a switch to the functional style.

Excluding the singleton class (which could have been a single function itself), you've got your map/filters in the gif processing, and encapsulation of async activities[0] through monads via promises.

Seems like JavaScript got good when it started embracing what functional programmers have been drowned out saying for years.

Looking good indeed.

[0] Async actions as a language-level construct, as opposed to a syntactic abstraction have always been A Bad Idea. Promises should have always been the default, and manually writing callbacks should have never been a thing.

[lucian1900]

Except for immutability. It's still nowhere near the norm.

[nwienert]

I'm working on a JS stack that leverages React, es6, functional style programming, and immutable data. Check my profile for more info.

[_greim_]

> Async actions as a language-level construct, as opposed to a syntactic abstraction has always been A Bad Idea.

Are you saying that the upcoming async/await features of JS are a bad idea? Or maybe I'm not following; can you give an example?

[chrisdotcode]

This:

    images <- get "http://example.com/images.json"

is objectively easier to reason about than:

    var images;
    get("http://example.com/images.json", (err, resp) =>
        if err throw err;
        images = resp;

even though the former might be internally implemented as the latter.

In addition, the former doesn't give the programmer the 'opportunity' to cause a race-condition, and encapsulates the failure entirely for you (automatically and defaultly); If `images` ends up erroring, and you use it again, then it'll short-circuit without crash, very similar to `then()`.

[zak_mc_kracken]

It's mostly easier to read because it no longer deals with error cases. All code becomes easier to read if you ignore errors.

I can make my code arbitrarily short if it doesn't have to be correct.

[chrisdotcode]

That's the magic of monads: the errors are all handled for you (in an encapsulated, lossless way), and you can deal with them (if you choose) at the end of the chain, just the same as promises (because promises are a monad).

[zak_mc_kracken]

The same can be said of exceptions.

However, my comment above had nothing to do with how you handle errors, it was about the unsoundness of comparing code that handles errors to code that doesn't.

[chrisdotcode]

Right - What I'm saying is that the above former code does handle the error, in the exact same way as the latter code.

For clarification, the error is handled implicitly (but you'd know what kind of error it was due to the type signature), but you can always handle it in manner you choose to at any point.

[tel]

It's not really the same as exceptions in a typed language because it's forced to be delimited. Even in Javascript you'll have to do a little ceremony to "escape" the golden path driven by the monad, though you'll have many ways to take short-cuts and forget details.