3 ms·

I disagree. It is not analogous to cooperative multitasking, since Windows 3.1 dealt with different applications -- but asynchronous programming is targeting o

I disagree. It is not analogous to cooperative multitasking, since Windows 3.1 dealt with different applications -- but asynchronous programming is targeting only a single (server) application. I also would add, that asynchronous implemented server applications are doing oftentimes better than systems that primarily rely on threading.

amelius 12y ago
> but asynchronous programming is targeting only a single (server) application As systems get more complex, this is not true anymore, because thinking otherwise would put the composability of the software at risk. Large software is typically built from many heterogeneous components. > I also would add, that asynchronous implemented server applications are doing oftentimes better than systems that primarily rely on threading. In the case of purely I/O bound applications, you may be right. Otherwise, it is a matter of finding the "sweet spot": just like bubble-sort is faster for certain applications than quicksort, does not mean it is the sort-routine we should be putting at the center of our frameworks, and build our software around. Also note that asynchronously servicing N users, where each of the N services has a certain probability p>0 to "lock" the system for longer than expected, will increasingly become an unresponsive experience for increasing N.
- PythonicAlpha 12y ago
  > Large software is typically built from many heterogeneous components. That is just one of the reasons, why software is getting more and more unreliable (not the asynchronous implementation). Software stacks are getting more and more complex and implementors loose track of the complexity. Throwing dirt on software with clear and less complex implementations, is not going to make things better. Of course I would not argue, that asynchronous implementation is for any software and in particular with today's development tools, but just to compare it with different types of things to make it look bad, is no proper argumentation style.

amelius 12y ago

> but asynchronous programming is targeting only a single (server) application As systems get more complex, this is not true anymore, because thinking otherwise would put the composability of the software at risk. Large software is typically built from many heterogeneous components. > I also would add, that asynchronous implemented server applications are doing oftentimes better than systems that primarily rely on threading. In the case of purely I/O bound applications, you may be right. Otherwise, it is a matter of finding the "sweet spot": just like bubble-sort is faster for certain applications than quicksort, does not mean it is the sort-routine we should be putting at the center of our frameworks, and build our software around. Also note that asynchronously servicing N users, where each of the N services has a certain probability p>0 to "lock" the system for longer than expected, will increasingly become an unresponsive experience for increasing N.

PythonicAlpha 12y ago
> Large software is typically built from many heterogeneous components. That is just one of the reasons, why software is getting more and more unreliable (not the asynchronous implementation). Software stacks are getting more and more complex and implementors loose track of the complexity. Throwing dirt on software with clear and less complex implementations, is not going to make things better. Of course I would not argue, that asynchronous implementation is for any software and in particular with today's development tools, but just to compare it with different types of things to make it look bad, is no proper argumentation style.