3 ms·

Your advice is OK for when you are doing a one-off, simple thing. In general, though, streaming abstractions leave that paradigm in the dust once things get be

Your advice is OK for when you are doing a one-off, simple thing. In general, though, streaming abstractions leave that paradigm in the dust once things get become just a tad more complicated. Using streaming abstractions, you can reason about the flow of your data at a much higher level and create abstractions which would require 100s or 1000s of lines of code to duplicate. For example, if he decides he needs to buffer the stream, then perform processing on it, then send it out into to the world, he can do all of this super easily by using a few streaming combinators while everything is super clear and type-safe.

watwut 5y ago
All of that is good when you need it. None of that is good when you don't actually need higher level reasoning about data.
- shock 5y ago
  Why do you need to program at a higher level than assembly?
  - watwut 5y ago
    Too much abstraction harms as much as too little abstraction. And java is exactly environment that made "too much abstraction to the point of hurting maintainability" in the past. If you need higher level abstraction, you should use it. If you dont need it, you absolutely should not use it.
    - le-mark 5y ago
      This x1000, we are not writing code for ourselves, we write code for our employers, and it behooves us all to keep it as simple and maintainable as possible. Will you be there in 10 years to explain it, will you want to if you are? If this is your open source project or whatever do as you please, otherwise follow the principal of least abstraction.
skohan 5y ago
> create abstractions which would require 100s or 1000s of lines of code to duplicate. I would like to see an example of this, I just don't think streaming libraries, or abstractions in general, can get rid of that much complexity. In most cases, abstractions can't really get rid of complexity, they just move it around. The issue I have with streaming abstractions is that the implementation tends to be overly complex. For instance, Rx libraries tend to be thousands of lines of code, and they're often written in ways that make it impossible to trace code or understand a call-stack. It makes some things easier, but when you run into a problem it becomes a nightmare to debug. I'm just not sure it's warranted a majority of the time. Those libraries tend to be huge because they have to cover every single use-case, and they work at a very high level of abstraction. When you're working with stream-like domains, it's often possible to implement the subset of what you would need of that streaming abstraction with normal code, and in a way which is much easier to understand and debug.
- chii 5y ago
  > you run into a problem it becomes a nightmare to debug. this happens sometimes due to both java being a PITA to do functional programming with, and also partly due to the initial programmer of the streaming logic not breaking down into composable functions. And with most people being more familiar with imperative style, it makes the functional style harder to maintain _for them_.
  - skohan 5y ago
    I'm not just talking about Java - I've also seen this in mobile projects in Swift for example. > And with most people being more familiar with imperative style, it makes the functional style harder to maintain for them. It has nothing to do with functional style. It's perfectly feasible to write functional code with minimal abstraction which is easy to trace and understand. The problem is in handing over your flow of control to an overly complex black box of an abstraction layer.
- whateveracct 5y ago
  > In most cases, abstractions can't really get rid of complexity, they just move it around. People say this pithy truism all the time, and it's just not true. You're probably just talking about indirection and encapsulation. Real abstractions by their very nature reduce complexity. You could say "No true Scotsman" but I deal with actual abstractions in Haskell all the time and it only simplifies code. So maybe Java is just deficient in its abstraction capability, but parametric polymorphism and pure streams sound like a good start to me. If a steam makes you uncomfy because it's doing O(n) things "under the hood" and you "like to know what the computer is doing" that's probably just a personal comprehension issue.

watwut 5y ago

All of that is good when you need it. None of that is good when you don't actually need higher level reasoning about data.

shock 5y ago
Why do you need to program at a higher level than assembly?
- watwut 5y ago
  Too much abstraction harms as much as too little abstraction. And java is exactly environment that made "too much abstraction to the point of hurting maintainability" in the past. If you need higher level abstraction, you should use it. If you dont need it, you absolutely should not use it.
  - le-mark 5y ago
    This x1000, we are not writing code for ourselves, we write code for our employers, and it behooves us all to keep it as simple and maintainable as possible. Will you be there in 10 years to explain it, will you want to if you are? If this is your open source project or whatever do as you please, otherwise follow the principal of least abstraction.

skohan 5y ago

> create abstractions which would require 100s or 1000s of lines of code to duplicate. I would like to see an example of this, I just don't think streaming libraries, or abstractions in general, can get rid of that much complexity. In most cases, abstractions can't really get rid of complexity, they just move it around. The issue I have with streaming abstractions is that the implementation tends to be overly complex. For instance, Rx libraries tend to be thousands of lines of code, and they're often written in ways that make it impossible to trace code or understand a call-stack. It makes some things easier, but when you run into a problem it becomes a nightmare to debug. I'm just not sure it's warranted a majority of the time. Those libraries tend to be huge because they have to cover every single use-case, and they work at a very high level of abstraction. When you're working with stream-like domains, it's often possible to implement the subset of what you would need of that streaming abstraction with normal code, and in a way which is much easier to understand and debug.

chii 5y ago
> you run into a problem it becomes a nightmare to debug. this happens sometimes due to both java being a PITA to do functional programming with, and also partly due to the initial programmer of the streaming logic not breaking down into composable functions. And with most people being more familiar with imperative style, it makes the functional style harder to maintain _for them_.
- skohan 5y ago
  I'm not just talking about Java - I've also seen this in mobile projects in Swift for example. > And with most people being more familiar with imperative style, it makes the functional style harder to maintain for them. It has nothing to do with functional style. It's perfectly feasible to write functional code with minimal abstraction which is easy to trace and understand. The problem is in handing over your flow of control to an overly complex black box of an abstraction layer.
whateveracct 5y ago
> In most cases, abstractions can't really get rid of complexity, they just move it around. People say this pithy truism all the time, and it's just not true. You're probably just talking about indirection and encapsulation. Real abstractions by their very nature reduce complexity. You could say "No true Scotsman" but I deal with actual abstractions in Haskell all the time and it only simplifies code. So maybe Java is just deficient in its abstraction capability, but parametric polymorphism and pure streams sound like a good start to me. If a steam makes you uncomfy because it's doing O(n) things "under the hood" and you "like to know what the computer is doing" that's probably just a personal comprehension issue.