Hi All,
In last 1 year I was working on Java and flex. While coding flex, most of my code parts went for a toss since its asynchronous. It made me to think about the real advantages and disadvantages of synchronous executing languages vs asynchronously executing ones.
What are the areas where they are stronger compared to other and what are the areas they falls?
(Leaving aside the semantics level discussion i.e. "sync/async language")
A "framework" built on a "language" (whatever it is) should be able to handle such cases (sync/async programme flow) in order to be useful (read: $ wise).
Asynchronous idioms are appropriate at every scale.
At large scale, asynchronous techniques help build reliable systems because the real world is anyhow asynchronous in nature. In other words, one needs to think in "asynchronous thoughts" to cope with real-life situations such as failures, losses, delays etc.
Even on a smaller scale (e.g. GUI application), events (such as "mouse clicks") tend to be "asynchronous". Of course they are "serialized" at some point (in order to be processable by an application running some software) but it doesn't change the fact that events (probably) occurred "asynchronously" with regards to the flow of the programme in question.
I think it's not about the language, but about the framework.
Counter-case in point:
When writing 'Classic Mac' (MacOS 9 and before) applications in C (a 'synchronous' language if there ever was one), you don't have preemptive multithreading, so all potentially blocking system calls have an async counterpart, where you fill a block of data with parameters including a callback function. Then you do the system call (which would return immediately), and your callback would be called asynchronously (in what's called 'interrupt level'). It wasn't uncommon that a callback would do another async system call, creating a long background thread that ran asynchronously with the main one.
I've spent most of the last year coding in Silverlight, which means I've spent a good deal of time thinking through (and fighting with) the same issues you're describing.
In brief, as other folks have pointed out, the real strength to the asynchronous model is its ability to create robust systems that interoperate well with the real world. Nobody could realistically use a Silverlight (or Flash) application if the UI thread came to a halt every time it took a few seconds for a web service call to return.
The biggest downside is that it the resulting code is complex and difficult to troubleshoot. Things like error handling are a PITA, but the most annoying stuff I've had to deal with is coordinating responses from multiple asynchronous calls. If, say, you need information from call A before making call B, and you need information from call B before making call C (and so forth), the resulting code looks really unpleasant, and is susceptible to all sorts of weird side-effects. There are techniques for making all this stuff work, and even reasonably clean, but if you're coming from the synchronous world (as I was), it's a significant learning curve. (And it doesn't help that Microsoft pushes events as the way to deal with WCF calls when callbacks, in my opinion, are much cleaner and less susceptible to the sort of weird side-effects I was talking about.)
(And yes, other folks are correct in saying that it's not the language that's asynchronous so much as that particular frameworks require constructing your code in an asynchronous manner -- but I get what you mean.)