5 ms·
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
by chrisdotcode 12y ago
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 12y agoExcept for immutability. It's still nowhere near the norm.
- nwienert 12y agoI'm working on a JS stack that leverages React, es6, functional style programming, and immutable data. Check my profile for more info.
- _greim_ 12y ago> 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 12y agoThis: 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 12y agoIt'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 12y agoThat'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 12y agoThe 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 12y agoRight - 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 12y agoIt'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.