4 ms·

"It is pretty much the same as using goto to structure your programs." I don't see how a self contained block of code can be equated to goto where the flow can

"It is pretty much the same as using goto to structure your programs." I don't see how a self contained block of code can be equated to goto where the flow can bounce around all over the place. The example callback "hell" code doesn't look any more complicated than the solution Elm code to me. Maybe the improvement is going over my head and I need to read it again. I just don't see it. Then again, I feel the same way about Coffeescript. These javascript helper languages just seem like an unnecessary added level of complication and cognitive load.

SoftwareMaven 14y ago
This is the typical "blog sample" complaint: "Four lines of code doesn't prove your conjecture". Of course, putting an entire application in would make for a challenging read. While I'm not sure I would go as far as saying goto==callback, after wading through a fairly extensive browser extension, I know that callbacks are inherently more difficult to reason about than imperative code. I haven't decided if the tradeoff of more flexible code versus more difficult reasoning is a good one. In some ways, I think the article got it right: we are expecting the programmer to do a lot of book-keeping that a compiler could do more cleanly. After all, it is possible to write goto-laden code that is just as readable as function-laden code. It's just nice to let the compiler manage all the baggage of frames, stack pointers and jumps for us.
tluyben2 14y ago
With continuations (I cannot read the elm page right now as it is stuck), you can write something like; return doItWith(getSomething()); where getSomething() does something async. This is very clear and readable, in JS: var result = function() { ... handle the returned value in here } var self = this; this.getSomething(function(something){ result(self.doItWith(something)); }); When you are wading through large JS chunks this really gets hard. I do code reviews for my employees and there is a lot of time wasted on fixing bugs related to these callback structures. It's just too easy to make mistakes. I'm not sure if elm or opa or ... are final solutions, but they do improve working with Javascript imho.

SoftwareMaven 14y ago

This is the typical "blog sample" complaint: "Four lines of code doesn't prove your conjecture". Of course, putting an entire application in would make for a challenging read. While I'm not sure I would go as far as saying goto==callback, after wading through a fairly extensive browser extension, I know that callbacks are inherently more difficult to reason about than imperative code. I haven't decided if the tradeoff of more flexible code versus more difficult reasoning is a good one. In some ways, I think the article got it right: we are expecting the programmer to do a lot of book-keeping that a compiler could do more cleanly. After all, it is possible to write goto-laden code that is just as readable as function-laden code. It's just nice to let the compiler manage all the baggage of frames, stack pointers and jumps for us.

tluyben2 14y ago

With continuations (I cannot read the elm page right now as it is stuck), you can write something like; return doItWith(getSomething()); where getSomething() does something async. This is very clear and readable, in JS: var result = function() { ... handle the returned value in here } var self = this; this.getSomething(function(something){ result(self.doItWith(something)); }); When you are wading through large JS chunks this really gets hard. I do code reviews for my employees and there is a lot of time wasted on fixing bugs related to these callback structures. It's just too easy to make mistakes. I'm not sure if elm or opa or ... are final solutions, but they do improve working with Javascript imho.