Hacker News Reader

Comment by sthatipamala | Hacker News Reader

Not that it's terribly relevant but a clever reader may notice that a Promise is a monad that encapsulates and stands in place of some to-be-done operation.

The .then() method is this monad's bind operator. It allows you to chain a Promise through functions that do not have to know or care about how to accept promises as arguments.

Hopefully this might help Javascript programmers who are curious about the relevance of these esoteric functional programming ideas. They are in your language too! (just with less frightening names)

View on HN

Oh, yes, of-course, now it makes it perfectly clear!

Reading HN sometimes make me wonder how I'm still getting paid for writing code / managing others that do so. Was software reinvented in the past few years while I was sleeping? Is functional programming taking over the world? Is understanding things like Monads and Promises now a must have for anyone calling themselves a programmer / developer / software engineer / hacker?

People are simply giving names for useful patterns that you can use to solve certain classes of problems. You can still write great code without using them and you can even use them without knowing what they are called.

Giving names to these ideas just makes it easier to communicate common concepts to yourself and others. (imagine how hard it would be if you didn't know the terms "binary tree" or "MAC address").

The existence of these concepts is not an affront to your existing knowledge. Learn them only if you think it helps you.

The point of the article is that Promises should not be just the name of a general pattern or idea for a common concept, but adhere to a very specific definition. Monads as far as I know are already that, not a pattern but a very specific type of construct.

That's one of the reasons I hate the reality of design patterns in modern software: they start off as useful vocabulary, then some specific variants of the pattern hijack the name, and soon it's impossible to communicate clearly as nobody knows which variants have which names and meanings, and vocabulary starts to diverge wildly (see also: MV* patterns).

The worst example of that phenomenon is Singleton, which everyone believes is about a static factory method that returns the instance. In fact, that was only an EXAMPLE given in the GoF book for a mechanism to get the singleton instance...

true - to quote richard feynman: http://www.youtube.com/watch?v=05WS0WN7zMQ

Thanks for putting me on to this - I love Feynman but have never seen these talks!

Promises go back several years in Java. Any use of asynchronous functions with callbacks is basically a Promise.

No, it clearly isn't. A Future, from Java 5's concurrency libs is close, but it doesn't offer the chaining construction -- it only offers get. The most similar-looking code commonly used in Java is probably people who use Option (or Maybe for those who stole from Haskell instead) with a .transform.

I don't think there's as much a need for it in Java because I'm less likely to want to write defensive code in that way outside of the browser.

It looks like Play supplies F.Promise, which provides the same functionality with a different API. I do like the simplicity of the API in the JS promises. The something.transform(good, bad, progress) is very easy to understand from the start.

I've never thought of the two mentioned monads (Promise and Option) as defensive. Option doesn't seem defensive because sometimes you need to represent the possibility that there is no value to be returned.

Could you elaborate on how it's defensive?

> Was software reinvented in the past few years while I was sleeping? > Is functional programming taking over the world?

Yes and yes, and it's awesome! :) Previously functional programming was mostly an academic pursuit but in the last decade it has definitely entered the mainstream. Once you understand FP, you become a much more skilled programmer and can make more efficient solutions even in languages not designed for FP like C.

> Is understanding things like Monads and Promises now a must have > for anyone calling themselves a programmer / developer / software engineer / hacker?

I don't understanding it per se is the water branching point. Instead the difference between an "office drone engineer" and a hacker is a natural curiosity and interest in learning new things. An office drone will say "damn! now i have to learn this NEW thing, argh." A hacker will instead enjoy it and have a very fun time learning about monads.

I love learning new things, but only if they serve a purpose, "back in the days" the "new things" were ground braking technologies like XHTML, Adobe Flex / MS Silverlight / JavaFX. Thank God I was an "office drone" back then and skipped it. (I don't have the time to waste, I have 2 small kids and I rather spend time with then then learning things for fun, no matter how fun it is)

And when I learn something new, it's rarely a new language construct, I rather create something new, or learn a new technology, not a design pattern. (e.g. can't wait to find some spare time for Meteor 0.5 experimentation. I wonder if I can write a TypeScript interface for it)

So call me an office drone, but if Promises are syntactic sugar, I rather have my coffee unsweetened.

I don't know if I agree that learning technologies that does not prove to be commercially viable are a waste of time. You can learn a lot from a topic even if it is not directly related to your income. Machine learning is a hobby of mine, which I, sadly, haven't had the chance to work with professionally. But by learning about it, I think my mind has sharpened and I think I now have a much better grasp of linear algebra which is related to my work.

Similar experiences can probably be derived by learning about JavaFX, like understanding its pretty smart canvas api. Silverlight has, I don't know, state of the art drm technology for video streaming?

The point is that learning is almost always a good investment that pays off. If you love what you are learning about, then the investment becomes much smaller and the payoff almost immediate.

In general, I get excited about learning new things. Regarding monads, I've made several efforts to grasp them over the course of multiple years now. I no longer get excited about trying to understand them. I'm currently taking Odersky's functional programming class at Coursera, and that has been coming naturally to me. But monads seem to inhabit a magical space which my mind cannot enter.

I wrote a blog post on exactly this a few months ago: http://kybernetikos.com/2012/07/10/design-pattern-wrapper-wi...

In this vein, it's also worth looking at Microsoft's "Reactive Extensions" (which have a JS implementation, too.) It's a similarly monadic approach to asynchrony, but deals in "observables" which produce zero or more events, compared to promises which produce only one.

(Edit: corrected "one or more" to "zero or more".)

And the same can be said about Twisted's Deferred.

Not exactly, unless the fulfilledHandler returns a promise. The examples didn't seem to have that requirement.

If fulfilledHandler is a regular function, then then() is just Functor's fmap.

If fulfilledHandler is allowed to be either variant, then you can imagine then() as applying an implicit return when needed, which makes the types a bit less clear

Reply on news.ycombinator.com