4 ms·

Why does any code start failing? That’s not the point they were making. The point is that when you start chaining together so many calls, it can become difficu

Why does any code start failing? That’s not the point they were making. The point is that when you start chaining together so many calls, it can become difficult to debug. Prettier to write, but more difficult to debug. But that’s okay, you need to find the balance that’s appropriate for the particular project.

throwaway4good 5y ago
First. If getPrice fails, the stack trace will start there. If it returns null (which it should not) and trigger a npe, then the line: map(e -> e.getKey().getPrice().multiply(new BigDecimal(e.getValue()))). Is just as dense as the original: sum = sum.add(entry.getKey().getPrice().multiply(new BigInteger(entry.getValue()) And the stack trace would be just as confusing. Second. The key thing with streams is to borrow from the functional programming paradigm: Split data and functions, avoid or isolate side-effects. Do this correctly and there is a quite real plus in productivity.
- budlightvirus 5y ago
  Could I trouble you for an example or a reference on what this would look like refactored with "Split data and functions, avoid or isolate side-effects"? I would like to understand better but I don't know enough about functional programming to grasp your meaning just from the comment.
  - throwaway4good 5y ago
    I don't know any good resource. And not all functional programmers are good programmers; but try to understand what they are trying to do. There as a bit of zen to it, less is more, in sense that a language gets more powerful if it is more constrained. For example if you know (by the type system or just coding conventions) that p.getPrice() nevers returns null, it is easier to reason about (proof, test, read) the code. Like wise if you know that if p1 == p2 then p1.getPrice() == p2.getPrice() (that would be no side effects). If you as some one suggested, need to support some crazy localization, then don't put it into p.getPrice(). If you must, change the name to something telling and make its input explicit: p.calculateLocalizedPrice(locale). Or better make it an explicit function (static method, or maybe something sitting in a service) calculateLocalizedPrice(product, locale) and again have it be without side effects.
    - labawi 5y ago
      I think definitions vary slightly, but the quality you mentioned (a == b => f(a) == f(b)) would be called a deterministic function [1] - very useful, often applicable or even type check enforced in functional programming languages. Having no side effects is a different very useful quality - function doing exactly as specified and no more (I/O, setting variables ..). I'm not sure if it means not accessing global state, though it is usually better if both inputs and outputs are explicit. All in, it is usually easier to reason about functions that are explicit, deterministic and side-effect free, yet I find it profoundly more valuable if it can actually be relied on (a known subset of) functions having those qualities. [1] https://maksimivanov.com/posts/pure-functions-and-side-effects/ https://maksimivanov.com/posts/pure-functions-and-side-effec...
  - imoverclocked 5y ago
    You might read up on pure functions [1] which are unable to produce side-effects when run. Imagine you have two methods in Java: int add(int a, int b) { log.info("Adding two numbers {} {}", a, b); return a + b; } void doStuff() { add(1, 2); add(2, 3); add(3, 4); } The result of add in doStuff is unused. However, add has a log statement which someone might be relying on elsewhere. The log line makes understanding the usefulness of this code much harder. ie: Can you delete this call? It's impossible to know without understanding everything that might consume the log line. The log-line is a side-effect in these methods. In languages that understand "pure functions" there are optimizations that can be done by the toolchain (think automatic memoization, deferred computation, and much more) when only pure functions are called. [1] https://en.wikipedia.org/wiki/Pure_function https://en.wikipedia.org/wiki/Pure_function
shagie 5y ago
> but more difficult to debug. I've found the stream debugger in IntelliJ to be very useful when looking at debugging streams. https://www.jetbrains.com/help/idea/analyze-java-stream-operations.html https://www.jetbrains.com/help/idea/analyze-java-stream-oper... The old plugin version of it has the same functionality (and better pictures) - https://plugins.jetbrains.com/plugin/9696-java-stream-debugger https://plugins.jetbrains.com/plugin/9696-java-stream-debugg... (click the 'more' link) Selecting a piece of data within the stream shows you how it moved through the stream. The other part of streams, for me, is that with the additional "each line does one, and only one thing" and you're not putting too much complexity in a single map, I feel that it forces you to write simpler code that doesn't need much debugging. The question of "how did that data get into the stream is where most of the debugging comes from.

throwaway4good 5y ago

First. If getPrice fails, the stack trace will start there. If it returns null (which it should not) and trigger a npe, then the line: map(e -> e.getKey().getPrice().multiply(new BigDecimal(e.getValue()))). Is just as dense as the original: sum = sum.add(entry.getKey().getPrice().multiply(new BigInteger(entry.getValue()) And the stack trace would be just as confusing. Second. The key thing with streams is to borrow from the functional programming paradigm: Split data and functions, avoid or isolate side-effects. Do this correctly and there is a quite real plus in productivity.

budlightvirus 5y ago
Could I trouble you for an example or a reference on what this would look like refactored with "Split data and functions, avoid or isolate side-effects"? I would like to understand better but I don't know enough about functional programming to grasp your meaning just from the comment.
- throwaway4good 5y ago
  I don't know any good resource. And not all functional programmers are good programmers; but try to understand what they are trying to do. There as a bit of zen to it, less is more, in sense that a language gets more powerful if it is more constrained. For example if you know (by the type system or just coding conventions) that p.getPrice() nevers returns null, it is easier to reason about (proof, test, read) the code. Like wise if you know that if p1 == p2 then p1.getPrice() == p2.getPrice() (that would be no side effects). If you as some one suggested, need to support some crazy localization, then don't put it into p.getPrice(). If you must, change the name to something telling and make its input explicit: p.calculateLocalizedPrice(locale). Or better make it an explicit function (static method, or maybe something sitting in a service) calculateLocalizedPrice(product, locale) and again have it be without side effects.
  - labawi 5y ago
    I think definitions vary slightly, but the quality you mentioned (a == b => f(a) == f(b)) would be called a deterministic function [1] - very useful, often applicable or even type check enforced in functional programming languages. Having no side effects is a different very useful quality - function doing exactly as specified and no more (I/O, setting variables ..). I'm not sure if it means not accessing global state, though it is usually better if both inputs and outputs are explicit. All in, it is usually easier to reason about functions that are explicit, deterministic and side-effect free, yet I find it profoundly more valuable if it can actually be relied on (a known subset of) functions having those qualities. [1] https://maksimivanov.com/posts/pure-functions-and-side-effects/ https://maksimivanov.com/posts/pure-functions-and-side-effec...
- imoverclocked 5y ago
  You might read up on pure functions [1] which are unable to produce side-effects when run. Imagine you have two methods in Java: int add(int a, int b) { log.info("Adding two numbers {} {}", a, b); return a + b; } void doStuff() { add(1, 2); add(2, 3); add(3, 4); } The result of add in doStuff is unused. However, add has a log statement which someone might be relying on elsewhere. The log line makes understanding the usefulness of this code much harder. ie: Can you delete this call? It's impossible to know without understanding everything that might consume the log line. The log-line is a side-effect in these methods. In languages that understand "pure functions" there are optimizations that can be done by the toolchain (think automatic memoization, deferred computation, and much more) when only pure functions are called. [1] https://en.wikipedia.org/wiki/Pure_function https://en.wikipedia.org/wiki/Pure_function

shagie 5y ago

> but more difficult to debug. I've found the stream debugger in IntelliJ to be very useful when looking at debugging streams. https://www.jetbrains.com/help/idea/analyze-java-stream-operations.html https://www.jetbrains.com/help/idea/analyze-java-stream-oper... The old plugin version of it has the same functionality (and better pictures) - https://plugins.jetbrains.com/plugin/9696-java-stream-debugger https://plugins.jetbrains.com/plugin/9696-java-stream-debugg... (click the 'more' link) Selecting a piece of data within the stream shows you how it moved through the stream. The other part of streams, for me, is that with the additional "each line does one, and only one thing" and you're not putting too much complexity in a single map, I feel that it forces you to write simpler code that doesn't need much debugging. The question of "how did that data get into the stream is where most of the debugging comes from.