You can only build a synchronous API on top of an asynchronous API if they are (a) running in separate threads/processes AND (b) the sync thread can synchronously poll (busy loop) for the progress/completion of the async thread. On Oct 12, 2013 1:23 AM, "pira...@gmail.com" <pira...@gmail.com> wrote:
> >> Synchronous APIs are easier to use since it's how things have been done > since decades ago, > > > > > > No, they're easier to use because they fit the model of linear human > thought more naturally. The idea that asynchronous APIs are just as good > and easy as synchronous APIs, and that people only disagree because of lack > of experience with asynchronous APIs, is mistaken. APIs must be designed > around how programmer's minds actually work, not how you'd like them to > work. > > > I agree that APIs should have the least-surprise-factor, but are you sure > that's the reason why we use to program in a synchronous, linear way? > Because I've always though it was an heritage of the batch-processing > machines of the '60s... I don't believe event-oriented programming fit bad > with how humans thinks because the nature is event-oriented (if this then > that), and I don't believe I'm an alien so that's the reason I think in a > different way... > > >> but the required POSIX-like APIs would be better developed as external > libraries on top of the asynchronous ones. > > > > You can't build synchronous APIs on top of asynchronous APIs without the > mechanism this thread is specifically about. > > > I've always been taught that you can implement one on top of the other... > :-/ Obviously, asynchronous on top of synchronous is fairly easier thsn in > the other way... >