4 ms·

I think that, like programming in general, there are different styles that click for different people. Different analogies, like the "push" vs "pull" described

by Shank 8y ago

I think that, like programming in general, there are different styles that click for different people. Different analogies, like the "push" vs "pull" described in this article come with different trade offs, and different people see them more easily than others. In reality, I just want more options. I know that synchronous IO on UI threads is bad, but I also know that I can avoid bottlenecks by not pulling from slow IO sources. Choice means that a problem can be expressed in the most natural way to a programmer or a team, which ultimately helps convey the ideas better than trying to work in an unnatural convention. I love Ruby primarily because you can usually accomplish tasks multiple ways. You can usually find the most natural way _to you_ and use that, over, say a prescribed "best" way.

Tarean 8y ago
But not all of them are equivalent. Push flows can deal with multiple sinks while pull flows can deal with multiple sources for instance. It's totally reasonable to mix these if you match their flows (or have unlimited memory to buffer stuff). Ideally the compiler could figure out a data flow that runs in constant space from a declarative program. There are some papers into that direction but afair we aren't there ysr.
scj 8y ago
If you are writing an API that others are incorporating, create equivalent pull methods for every push where possible (or alternatives if necessary). The reasoning is simple, sometimes programs get in bad states. When a bad state is detected, a program _should_ be able to go into a recovery mode and return to normal. But I've seen push-only libraries (that I could not modify), where access to the data I'd need could not be guaranteed. This particularly holds true in a client-server relationship. The client should have a method of asking the server for help without needing to reset the session. Ignoring state effects, a pull model will permit recovery by default, while it needs to be planned in a push model.

by Shank 8y ago

Tarean 8y ago

But not all of them are equivalent. Push flows can deal with multiple sinks while pull flows can deal with multiple sources for instance. It's totally reasonable to mix these if you match their flows (or have unlimited memory to buffer stuff). Ideally the compiler could figure out a data flow that runs in constant space from a declarative program. There are some papers into that direction but afair we aren't there ysr.

scj 8y ago

If you are writing an API that others are incorporating, create equivalent pull methods for every push where possible (or alternatives if necessary). The reasoning is simple, sometimes programs get in bad states. When a bad state is detected, a program _should_ be able to go into a recovery mode and return to normal. But I've seen push-only libraries (that I could not modify), where access to the data I'd need could not be guaranteed. This particularly holds true in a client-server relationship. The client should have a method of asking the server for help without needing to reset the session. Ignoring state effects, a pull model will permit recovery by default, while it needs to be planned in a push model.