That said, what the article proposes as a solution is bananas. You don't need to do crazy functional acronym things; just don't use callbacks. Good C/C++ programmers in the field where I work (video games) do this all the time. It's not hard except that it requires a little bit of discipline toward simplicity (which is not something exhibited by this article!)
http://www.haskell.org/haskellwiki/Reactive-banana
Secondly, you come off sounding defensive and ignorant. This is a new programming paradigm. Hopefully it will give people new ways to approach the same difficult problems. (And I really hope you believe GUIs are inherently difficult...)
No one is twisting your arm to learn FPR. If callbacks work for you in your job, then stick with what works.
What you are hearing now is not ignorance, it is experience. I am a tremendously better programmer than I was in those days, and the way I got better was not by getting excited about wacky ideas; it was by really noticing what really works, and what doesn't; by noticing what are the real problems that I encounter in complicated programming projects, rather than what inexperienced / pundit / academic programmers tell me the problems are.
Clearly you didn't really read my comment, though, since you are saying "If callbacks work for you in your job..." and my entire point is that callbacks are terrible.
If a GUI is your example of something that is difficult, we are just living in different worlds and it's a challenge to have a productive conversation. I think a difficult task is something like "make this ambitious AAA game run on the PlayStation 3 performantly". That is pretty hard.
In Objective-C, the @protocol keyword gives the language first class delegation and works really, really well. More details here: http://developer.apple.com/library/ios/#documentation/Cocoa/...
With respect to the original article, he's talking about callbacks with respect to Node.js. That's not a callback issue. Async is unnatural for the mind to grasp. What did he expect?
(FWIW my own architectures tend to turn callbacks into queues and polling.)
I'm sorry but that's not how it works. I've been coding for 20 years or so and I'm always open to new things. The first time I heard about using immutable objects in Java nearly everybody was laughing at the idea, making fun of it. Nowadays it's the contrary that is true. Same thing for using composition instead of concrete inheritance: everybody was there, ten years ago, saying that there was no problem with Java's concrete (implementation) inheritance. Or checked exceptions. Etc.
It's nearly always the same thing: a concept that is not mainstream but that looks very promising is explained in great details and yet people come here, bragging: "You're too stupid to understand ${common way of doing things}, there's no need for ${less commonly used technology}".
This really saddens me.
Programs that write programs? When would you ever want to do that? Not very often, if you think in Cobol. All the time, if you think in Lisp. It would be convenient here if I could give an example of a powerful macro, and say there! how about that? But if I did, it would just look like gibberish to someone who didn't know Lisp; there isn't room here to explain everything you'd need to know to understand what it meant.
http://www.paulgraham.com/avg.html
Hopefully though, people who are open to new ways to do things can achieve harder things.
People resist the new ideas until a critical mass of people start admiring it.
Only then they'll 'jump on the bandwagon' and tell everyone all about how cool this new idea is.
Don't be sad, it's clearly a natural reaction that has some utility. I agree that there's a better way to phrase it, usually something like "is it really that much better than what we have now?"
Whether this project will even be finished -- or much less, be better than other solutions -- is yet to be seen. Any features that make Elm's callback solution stand out from the crowd are not being advertised.
foo.doSomethingAsync(function(err, result) {
if (err) {
...
}
...
});
It allows you to write code like this:
val query = "Brian"
val result = for {
db <- connectToDatabase
user <- userFromDatabase(db, query)
friends <- friendsFromDatabase(db, user.friends)
} yield friends
An example from the Play! Framework for form submissions:
def submit = Action { implicit request =>
contactForm.bindFromRequest.fold(
errors => BadRequest(html.contact.form(errors)),
contact => Ok(html.contact.summary(contact))
)
}if (typeof result === Error) {
The problem is that if you count on the caller to check on the error value for the data, he might forget to do that. And the code works just fine in testing, and it seems like it works. But in the error case, we merrily continue on and try to pass the error around as if it were data.
When we return two values, error and data, then the developer is forced to think about the fact that the result could be an error, and think right then about what should happen. THis is a good place to be thinking about it.
Also, the developer may not even know at-a-glance that the function could sometimes return an error, unless consulting the documentation.
Or more succinctly: it's not about making the code easier to write (which the version you mentioned does); it's instead about making it easier to do the right thing.
The solution to GOTO was to remove it and replace it with a few control structure forms that enforced locality. I remember converting someone's GOTO-laced code once and basically everything could be re-written with some clever use of do-while with break statements and an occasional flag variable. do-while, while, for, etc. replace GOTO in 99% of cases and enforce the desired code locality for readability.
So what syntactical structure could enforce locality of time-connected variables?
E.g. some idea like this:
data, err <- $.ajax(requestUrl1)
if( err ) {
console.log(err)
return
}
data2, err <- $.ajax(makeRequestUrl2(data))
http://msdn.microsoft.com/en-us/library/vstudio/hh191443.asp...
The main advantage tat not many people see is that you get backwards compatibility with sync code (if statements, while loops, etc) basically for "free".
In addition, there is:
Q (implementation of the CommonJS Promises spec) https://github.com/kriskowal/q
Streamline.js https://github.com/Sage/streamlinejs
Await.js (New, inspired by Tame/IcedCS) https://github.com/greim/await.js
jQuery.Deferred http://api.jquery.com/category/deferred-object/
...And less current libs like Node-promises and FuturesJS.
Here's a comparison from last year: http://www.infoq.com/articles/surviving-asynchronous-program...
And IcedCS's debut on HN: http://news.ycombinator.com/item?id=3522839
In JS devs seem to like to reinvent the wheel. I'd love to see the community rally around one of these solutions, instead of creating new half-finished ones and abandoning them. I'm partial to IcedCS because it's the least verbose, and it also works as a lib outside of CS. The Promises spec has been (partially) implemented by jQuery and I'm sure is here to stay.
Elm's syntax won't easily translate to any existing solution I'm aware of. It is a nice research project, but I will be sticking with established, well-tested methods instead of risking my business on another half-finished wheel.
If you have functions, loops, and nested loop control, in 100% of cases you can replace GOTO code with code that is equally efficient. With flag variables and if checks, you can likewise always replace the code, BUT efficiency and verbosity suffers because of the need to check the flag variable repeatedly in the loop.
As for your syntax suggestion, I am reminded of http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html which manages to use a preprocessor trick to generate working coroutines in C. (This trick is actually used in PuTTY.) I also think that the strategy that you describe would work well enough for my tastes.
With a callback, you can get into 'callback hell,' however the root cause of that is that you probably don't understand the nuances of properly architecting a solution that involves the power of first-class functions.
JavaScript is nice because the scoping of the callback is easily controllable through your invocation method, and if you've created a good object model then it's relatively easy to maintain an understandable state.
When you explicitly define callbacks like in the examples, you're tightly coupling the response handlers to their requests, which is a relatively poor implementation and will bite you in the ass later on.
The analogy is that callbacks create non-linear control flow. Using a monadic syntax like in Roy, we can easily have callbacks without having them look non-linear:
let deferred = {
return: \x ->
let d = $.Deferred ()
d.resolve x
d.promise ()
bind: \x f -> x.pipe f
}
let v = do deferred
hello <- $.ajax 'examples/helloworld.roy'
alias <- $.ajax 'examples/alias.roy'
return (hello ++ alias)
v.done console.log
var deferred = {
"return": function(x) {
var d = $.Deferred();
d.resolve(x);
return d.promise();
},
"bind": function(x, f) {
return x.pipe(f);
}
};
var v = (function(){
var __monad__ = deferred;
return __monad__.bind($.ajax('examples/helloworld.roy'), function(hello) {
return __monad__.bind($.ajax('examples/alias.roy'), function(alias) {
return __monad__.return((hello + alias));
});
});
})();
v.done(console.log);
http://lib.store.yahoo.net/lib/paulgraham/cint.lisp
((call/cc
(lambda (goto)
(letrec ((start
(lambda ()
(print "start")
(goto next)))
(froz
(lambda ()
(print "froz")
(goto last)))
(next
(lambda ()
(print "next")
(goto froz)))
(last
(lambda ()
(print "last")
(+ 3 4))))
start))))I agree, if anything this is an argument about notification vs delegation. Callbacks should be used when you need to delegate a feature, like when an array object needs to call outside its scope to ask for a sorting function. Notifications should be used when the calling object doesn't care who handles the information, like in the case of an asynchronous load, and in a proper notification environment you wouldn't have the spagetti code this blog is illustrating.
Well, continuations are the functional equivalent of GOTOs, and callbacks and continuations are closely related, so I don't know how you can make that statement.
Even if you want to argue that they avoid some of the pitfalls of GOTOs (which I'd still contest), you still can't say that they're "not even remotely close to gotos".
The one I've personally played with is called Arrowlets[1], which introduces a control structure called an arrow that lets you abstract over callbacks and event handling (among other things). Using that style of programming can significantly simplify some fairly common tasks in JavaScript; the drag-and-drop demo on their site is a good motivating example. However, unless you are already familiar with functional programming and arrows, you should probably read some background before diving into the examples.
[1]: http://www.cs.umd.edu/projects/PL/arrowlets/
Another interesting option I've toyed with is RX.js[2]. This is a JavaScript version of C#'s Reactive Extentions (RX). If you are familiar with Linq, then this library's style should seem natural immediately. The core idea here is to abstract over events as streams that can be composed and manipulated conveniently.
If you don't mind using a different language, but want something that mostly looks like JavaScript, another option is FlapJax[3]. I haven't tried it myself, but I've certainly heard good things about it.
[3]: http://www.flapjax-lang.org/
There are probably more options in the same vein that I forgot or don't know about. However, I think these three are a good starting point and could help clean up much of your event-driven JavaScript code in the short term.
Of course, if you are willing to use a language radically different from JavaScript, then Elm is a great option. Once you get used to functional languages with good type systems, there is really no going back ;). The syntax is also simpler and more minimalistic than JavaScript's, which leads to more readable code.
Node.js had promises early on, then were removed, but they're slowly gaining traction again.
q seems to be a popular choice. https://github.com/kriskowal/q
How long until we get tired of adding epicycles and just specify a VM and bytecode standard that all the browsers can implement and all the client-side languages can compile to?
I'm not sure who you think "we" are, who should specify a VM and bytecode standard. If we wanted a bytecode standard, there doesn't seem anything deeply wrong with Java, and we seem to be in the process of phasing that out of every browser.
Java and Flash are no-gos because they're not open enough - they're owned by companies that want to maintain tight control over the platforms. They're also too heavily built around their own private APIs; what would really be needed is something that sticks to the same APIs and DOM that JavaScript interacts with, in order to ensure a reasonable migration path for existing technologies.
My guess is that the easiest option would be to base such a standard on a VM and bytecode format that a major browser already does implement: the one from the Spidermonkey Javascript engine.
Higher level languages are easier to optimise for. Creating a bytecode would also mean another backwards compatibility hell and another format is not as general as people would like.
I agree it would be nice to have that stuff, and that callbacks can get a little hairy, but they are the best solution available at present. Shall we stop developing applications in the mean time while the language catches up, or even worse, browsers actually consistently implement the changes?
At least, that's what the article is saying. There are a few interesting things on the horizon there, but I've been watching elm with some interest.
At its core, FPR only requires higher-order functions to work. (And nearly every modern language supports them to some degree).
The things that Elm provides are additional niceties:
* A type system with parametry polymorphism (aka generics) helps you spot otherwise nasty runtime errors ("expected a function, got a signal").
* Abstract data types - The only way to create a signal is through the API. The only thing you can do with a signal is pass it around and feed it back into the API.
* Language purity - This one is probably the hardest sell for average languages, since every modern language (save Haskell) allows for unrestricted side-effects. However, as long as you don't bypass the API and update the UI directly, you don't actually NEED purity.
The nice thing about Elm is that it compiles directly to Javascript. You can integrate it into new pages on your existing site without giving up anything. I think the language -- and more generally FPR as a basic tool in your toolkit -- has a lot of potential in the future.
This is definitely more hairy to use than if the language supported it natively, but not so bad, and can be implemented in a very lightweight way (this approach http://daemon.co.za/2012/04/simple-async-with-only-underscor... is a few lines of code on top of Underscore.js which a lot of sites are using already).
(PS: sorry if OP's article already mentioned this stuff, I can't load it at the moment)
Full disclosure: I wrote async.js.
Not making any comments about Elm's output, but the author clearly doesn't consider it a priority in the post.
At the end of the day this is more a call for language authors and the people around them to develop tools to debug the language.
Is the resultant Javascript just a bunch of nested callbacks, as in the example the blog post uses to illustrate spaghetti code?
This is analogous to goto's - programming with goto is a nightmare, but all code 'compiles to' some sort of immediate form using goto's. The goto is not the problem, programming with goto is.
Has anyone touched the Google Chrome code base? It is quite difficult to start debugging problems because of the sheer volume of callbacks. Add to that the stack-traces are massive because of the use of templates and other C++ language features.
Async coding needs to be an abstraction within the language. I am curious how languages manage the shared memory. What about the risk of dead locks?
Yes. This can be solved by maintaining your own backtrace of callbacks (say, as part of your request object/structure), but it's really something that should be implemented in the language or framework.
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.
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.
return doItWith(getSomething());
var result = function() { ... handle the returned value in here }
var self = this;
this.getSomething(function(something){
result(self.doItWith(something));
});
# this appears very synchronous
function getPhoto(tag) {
var photoList = syncGet(requestTag(tag));
var photoSizes = syncGet(requestOneFrom(photoList));
return sizesToPhoto(photoSizes);
}
# Two getPhoto() "processes" are spawned. After this,
# the language multiplexes between them via the (single) event loop,
# in a single OS thread.
job1 = spawn getPhoto('tokyo');
job2 = spawn getPhoto('tokyo');
# Wait for both of them to finish. This too happens in an asynchronous
# fashion, i.e. calling job1.join() does not prevent the two jobs from
# running. In effect at this point we have three "processes" running
# (the main process doing the joins, the job1 process and the job2 process).
photo1 = job1.join();
photo2 = job2.join();
drawOnScreen(photo1);
drawOnScreen(photo2);
NOTE: It seems this approach is not new; "green theads" seems to be the right term, and there seem to be a lot of Python-based implementations. Go's goroutines also appear similar (but you can have them run truly in parallel).
BUT note a crucial difference from the "green threads" approach - in my suggested design, there would be no real scheduling. If you perform sequence of operations and they are all guaranteed not to block, this sequence is automatically atomic, and cannot be interrupted by another "process".
I should also mention this programming language I'm developing, called NCD [1], which employs the same idea. See the in-browser demo [2], click on the Spawn example.
Note that NCD implements a unique extension of imperative programming. Statements in general persist even after they have "returned", and they get the chance to do stuff when they are about to be "deinitialized" (see what happens when you click "Request termination" in the Spawn example). Plus, any statement can trigger "backtracking" to its point within the process, causing automatic deinitialization of any statements that follow (try Count example).
Also, IMO promises [3] are just a hack around the fact that the language is not inherently asynchronous. Seriously, who would prefer:
doFoo()
.then(function (foo) {
return doBar(foo);
})
.then(function (bar) {
return doBaz(bar);
})
.then(function(baz) {
console.log(baz);
});
function myWork () {
foo = doFoo();
bar = doBar(foo);
baz = doBaz(bar);
console.log(baz);
}
spawn myWork();
NCD looks interesting, in particular the backtracking feature. But I'm a bit concerned by your choice of developing a new language from scratch, with a very awkward syntax (at least at first sight). Why not extend an existing language?
See CPC for instance, which extends the C language with a spawn primitive (disclaimer - this is my PhD thesis project): http://www.pps.univ-paris-diderot.fr/%7Ekerneis/software/cpc... and http://www.pps.univ-paris-diderot.fr/%7Ekerneis/research/ for more details.
Considering NCD: you might have noticed that NCD was never meant to be a general-purpose language, but rather a simple scripting language for controlling other programs and OS configuration. My thinking was that extending a language with the features that define NCD (asynchronous execution, backtracking and extended statement lifetime) would essentially require a complete rewrite of a language implementation. However after seeing tamejs and your CPC I'm not so sure anymore :)
P.S. Check out the Read File example I just added to the NCD demo page; it shows how backtracking can be used to handle errors elegantly.
def process(job):
http.put(job.destUrl, munge(http.get(job.srcUrl)))
print "Processing some jobs"
workerPool(MAX_CONNECTIONS).map(process, jobs)
print "All done!"
We hit pain points when we can't have parallelism in our programs, and are forced to make elegant the work-arounds intended to unclog those programs.
Inline callbacks as implemented in python can make asynchronous code a lot easier to read: http://hackedbellini.org/development/writing-asynchronous-py...
Give it a try! You almost definitely won't regret it!
For example: http://www.tornadoweb.org/documentation/gen.html
0. it plays hell with threadlocals-as-dynamic-scoping, which is the only way most "modern" languages permit dynamically scoped variables
1. it needs to be correctly passed along to callers, and given it's usually used in dynamically typed languages there's a high risk of forgetting and dropping a yield
2. yield being also used for iteration, it can be confusing to keep them straight.
It's definitely a better solution than callback hell though. An other approach is runtime support as in gevent, where the "yielding" is done by the library/IO code and invisible to the caller. The final two I know of are baking lightweight concurrency and communications into the language itself (Erlang, and to a lower extent Go and Rust) or monadic systems (Haskell)
Also, why is nonlinear code a bad thing? If the program behavior should be nonlinear, then neither should the code.
And two, I like his contrast between async vs synchronous flows, and recognizing synchronous style programming has many benefits that CPS doesn't. However, I think even this style still hasn't solved the bigger problem with asynchronous style programming. The ability to reuse it easily. In synchronous style programming I can reuse code and add to that block by calling the method, then after that method is done add my code.
... my code before ...
var result = someMethod()
... my code after ...
I'm intrigued by the ideas of signals over callbacks, but I don't know if they fix enough problems with callbacks yet.
Debugging is one of the problems with FRP/signals, or functional code in general. No one has come up with a good dataflow debugger yet, and it might not even be viable. The best you can do is interpose "probes" on your code like you would take measurements with an oscilloscope. Disclosure: I did my dissertation on signals (object-oriented ones to be precise), and am a bit disillusioned with it.
On the other hand, the argument from the declarative community is that you don't need to debug your code.
A better alternative to FRP/signals might be immediate mode user interfaces. Since they are conceptually called on every frame, you get the benefits of FRP while still being able to debug in the old way. On the other hand, they are quite inefficient, though I think we could play some tricks with technology to make them better (memoize, refresh blocks of computations only as needed via dependency tracing).
It'll be interesting to see if people start doing this. Requires people to understand continuations and closures (which more people have exposure to now via JavaScript), and library support.
* The async library mentioned by other posters helps a lot.
* Libraries like backbone make writing event-driven software easier.
But to sum it up: it's like anywhere else, bad programmers write "callback hell" code, and good programmers don't.
* Programmers who need a higher level language (e.g. C instead of assembly) are just bad programmers.
* Programmers who can't manage manual memory allocation are just bad programmers.
* etc
It seemed impossible to completely escape imperative programming. Mouse click handlers for example were much more natural to write imperatively; changes made in the imperative code would propagate as signals in a reactive way.
Reasoning about what happened around the boundaries of imperative and reactive code was hard, especially as the application grew in complexity. If I have a UI element that depends on two other signals - think spreadsheet cell with a formula that depends on two other calculations - do I want to update it as soon as one signal changes? do I wait for both to change? Do I want different behaviors in different circumstances? It often led excessive layout changes as values passed through intermediate states, or code being executed multiple times unnecessarily.
It depends on what else your user can realistically do before the call completes. In many cases the answer is "nothing." He needs the result of the call before he can proceed in his task. In simple web apps this happens a lot. In those cases I will often just make a synchronous call and avoid all the callback complexity.
Thankfully other browsers work fine. Makes me wonder what they are doing to completely break rendering on IE though...
You can then layer your favourite libraries or tools on top of that to make things better to live with. (For example, a promise-based wrapper for the low level libs or a compiles-to-js dialect)
I do agree that all those posts with people writing callback-based code as though it were the future were kind of sad though.
The problems with Javascript and callbacks are usually (in reverse importance): noisy verbosity (all those "function()"s), the deeper and deeper indentations, and then ensuring execution order on interdependent async steps while keeping it readable. In the blog post's example, you pretty much of a serial chain of dependent steps, and the only thing really wrong with it is that it's just ugly and approaching unreadable (syntax highlighting will help quite a bit, though).
I think most people heavily involved with Javascript recognize those problems, though. Promises/deferreds have entered mainstream js usage. They can be somewhat confusing for newcomers, but several libraries can help, as others have pointed out. Language support is evolving: "let" as an option for more control over scoping, the arrow syntax for simpler function expressions, yield for shallow continuations, etc. These will in turn feed back into making libraries smaller and easier to use (I'm really looking forward to when I can use http://taskjs.org/ for all my async needs. Combined with the arrow syntax, I feel like I can pretty much always avoid a callback mess and retain clarity of (high-level) flow at a glance).
This isn't a knock on elm (this article is the extent of my knowledge of it), and it isn't a dismissal of the problem, but it isn't clear to me from this article what is broken in JS that is fixed in elm. In other words, this could be another tutorial on promises in Javascript and make the same points about excessive callbacks being poor coding style and bad news for readability and maintainability.
Syntax that makes clear code the lowest energy state is a feature, but (if we limit our discussion to callbacks) in JS it's partly solved, partly being worked on, and it's not clear to me yet what the energy differential is in typical elm usage between this code and the nasty spaghetti code you can always write if you try.
Callbacks themselves, when used wisely, can often enhance code readability, hell LISP has had function references since forever, but I think the most complain about callbacks are actually complains about callbacks in noisy languages, mostly likely languages with noisy syntaxes like Javascript and Java. When read that way, the disgust towards callbacks do seem to have merits. As the author has pointed out, the 2 getPhoto() functions at the end express and do exactly the same things, but obviously the CoffeeScript version reads better.
Callbacks have been around a long time and I've never heard of people complain as much about them as people have for Javascript and I conjecture the reasons are as follows:
1) There's no named parameters (keyword arguments) in Javascript, so people pass around objects literals into functions to emulate them. 2) Making lambdas in JS is too easy, but the syntax is too noisy. 3) Oh so many aliasing of this; 4) Self-chainable JS libraries like jQuery makes the style of calling multiple functions too easy. But lines can only go to long before becoming unwieldy, so people tend to indent chained method calls multiple times. 5) No modules and global namespace pollution is frown upon, so people are hesitant to flatten deeply nested callback chains. 6) There are a dozen ways to make a JS class and/or object depending on frameworks, and they are not at all compatible.
All of these "features" coagulate in JS into giant blobs of snot like this:
<script>
$(document).ready(function() {
var $main = $("#main");
$main.
hide().
click(function(e) {
$.ajax({
type: "POST",
dataType: "json",
contentType: "application/json",
success: function(data, textStatus, jqXHR) {
data['rows'].forEach(function(line) {
$main.append($("<p>", {
className: "row"
}).append(line));
});
}
});
}).
show();
});
</script>
There are fairly simple syntactical solutions to both problems.
result = doSomeAsyncTask()
result.yield() // drops the thread, picks it up on response
// do stuff with result here
You could have similar code to solve the multiple task problem:
result0 = doSomeAsyncTask0();
result1 = doSomeAsyncTask1();
while (result = getNextCompletedTask(result0, result1)) {
// do something to result
}
The most popular was his article about gotos.
Another idea in his writings was that time-dependent programming was dangerous. He was talking about interrupt based programming specifically, and also addressed the common practice of some hardware to have asynchronous IO. You would start an IO operation, and go on and do other things, come back later and see the values there.
So these two things are not alike. They both cause confusion about what the program is doing, but they are not "like" each other.
To be a better programmer, it is good to read Dijkstra. It is really all about avoiding errors in programming.
So, it is even worst!
https://github.com/strangeloop/strangeloop2012/blob/master/s...
mpolun> I agree that raw callbacks can get out of hand, but the typical solution in js is to use an event emitter (http://nodejs.org/api/events.html) or promises (like https://github.com/kriskowal/q), the latter of which seems to be pretty close to what this article is talking about. Is there a fundamental difference, or are promises an example of functional reactive programming in a language without direct support for it?
Forget Javascript for a second, and take a look at a typical http proxy written in C using callbacks to see what a callback hell looks like. If 5 developers are working on such a project, it will require a lot of mental effort from each developer to keep the callback flow up-to-date in their head.
Debugging huge, complicated, and even poorly written Node applications doesn't feel much different to me than debugging huge, complicated, or poorly written Java applications. Sometimes it's a pain, that's unavoidable. You can prevent it to an extent by writing clean, tested code.
I don't see a strong resemblance between goto and callbacks. The resemblance is just as strong between goto and any function, or class
I'm not familiar with the last approach but it seems to me that with a couple of higher-order functions in JavaScript, the code will quickly become more manageable.
function getPhoto(tag, handlerCallback) {
asyncChain(requestTag, requestOneFrom)(tag, function(photoSizes) {
handlerCallback(sizesToPhoto(photoSizes));
});
}
getPhoto('tokyo', drawOnScreen);Yes, that's a bit vague, but that's all I've got to go on. :)
http://brandon.si/code/dilly-dot-js-a-library-for-loops-with...