3 ms·

You can write either imperative for-loops or a set of connected stream-processors. An arbitrary set of connected "streamers" can always be converted to imperati

You can write either imperative for-loops or a set of connected stream-processors. An arbitrary set of connected "streamers" can always be converted to imperative code and I assume that is what is happening under the covers. But the reverse is not true, an arbitrary set of for-loops can not be translated into a set of streamers. Right? That means that the structure of your program is much more constrained when you compose it out of streams, than if you compose it out of arbitrary for-loops. And if you know that your program obeys a set of constraints imposed on it by the connected streams, the program becomes easier to understand, because you can RE-use your knowledge of how those streams always work to understand every component of the system, meaning every stream-component of it.

rdsubhas 6y ago
Multiple leaps of faith. "More constraints mean more easier to understand" is a little too reductive. Replace streams with "operator". All your program code can be written as operators like dot or plus, and since those operators gave constraints, then the whole program will be simpler, right? If that were true, we'll still be writing code in assembly, managing registers by hand. Because hey, just 256 registers means that you can reuse your knowledge of registers everywhere, which means programs will be easier to understand again, right? There are examples in threads which show real examples where plain code is better.
- galaxyLogic 6y ago
  All streams work very similarly. Much more similarly than if you mix and match all kinds of operators together. Think Unix pipes they are easy to understand because they all behave similarly. Yes sometimes plain code is better sure but in cases where streams fit the job they are better. I guess the main point is that streams operate on multiple elements and they operate the same on every element. Therefore you don't need to reason what happens to every element that goes through the pipe. It is a bit like adding and multiplying matrices, you can understand the calculation without having to mentally follow how each matrix element is processed.

rdsubhas 6y ago

Multiple leaps of faith. "More constraints mean more easier to understand" is a little too reductive. Replace streams with "operator". All your program code can be written as operators like dot or plus, and since those operators gave constraints, then the whole program will be simpler, right? If that were true, we'll still be writing code in assembly, managing registers by hand. Because hey, just 256 registers means that you can reuse your knowledge of registers everywhere, which means programs will be easier to understand again, right? There are examples in threads which show real examples where plain code is better.

galaxyLogic 6y ago
All streams work very similarly. Much more similarly than if you mix and match all kinds of operators together. Think Unix pipes they are easy to understand because they all behave similarly. Yes sometimes plain code is better sure but in cases where streams fit the job they are better. I guess the main point is that streams operate on multiple elements and they operate the same on every element. Therefore you don't need to reason what happens to every element that goes through the pipe. It is a bit like adding and multiplying matrices, you can understand the calculation without having to mentally follow how each matrix element is processed.