...How do you ask for something that may or may not yet exist? Maybe some data that you don't want to care if it's about the past (already exist), abut the present and in the process of being computed, or about the future and not existing yet, not even the request for its computation is fired - yet you just want to write the same code that says "do this with this kind of data, always, whenever, wherever", I don't care if it the data does not exist yet now. Or how do you ask "how many time X happened since last time I asked"?
You'll end up implementing some kind of pooling loop, and sooner or later voila, you've reimplemented an event loop, and now you have a badly ad-hoc implemented event driven system anyway.
The only way to handle a "naturally push based system" is to accept that this is the natural way for it to be, a find a declarative way to express it as a rules based system instead of tangles of imperative event handlers. But this is really hard! So you settle for the "push based system" or "event driven" system instead quite often...
Have you ever queried a database? That's how. You just ask. If you don't get data, do deal with it.
Yes, there is a polling loop. Is this bad? Nope. You just have to understand the system you're building. Will you get data in a mostly consistent timing? Polling works. Is is sporadic? Try event driven. One size does not fit all. Event driven should not be used for everything and it's not in any way more natural than polling.
Definitely varies by the system, but, in my small-business internal-software experience, 99% of the time polling is good enough. Something feels innately ugly about polling, but it's simple, has failure modes that are easy to understand, and gets the job done.
In a pure push, how do you ask for data to be resent?
There's trade-offs either way. No way is "best"; it all depends on what you're doing. I communicate with equipment over TCP, that I have to poll. There's _no_ mechanism for push. You just work with what you have and do the very best you can.
You'll end up implementing some kind of pooling loop, and sooner or later voila, you've reimplemented an event loop, and now you have a badly ad-hoc implemented event driven system anyway.
The only way to handle a "naturally push based system" is to accept that this is the natural way for it to be, a find a declarative way to express it as a rules based system instead of tangles of imperative event handlers. But this is really hard! So you settle for the "push based system" or "event driven" system instead quite often...