Hacker News Reader

Comment by joebob42 | Hacker News Reader

I've never liked the streams API. We have a little tool at work that will suggest ways to replace things with stream-api equivalents, and every once in a while I'll get code review suggestions to do it, but it always reads worse to me compared to just using some for loops and if statements. and maybe a helper function if something gets really complex.

This does seem a bit better, would be curious to see in practice if it tends towards the same hard-to-readness or if it holds up.

View on HN

Streams API (or functional programming in general) is an abstraction over explicit loops. If you don't find that inherently useful, then you'll not have the motivation to get used to the different syntax. I've had my beginnings in functional programming, so explicit loops felt unjustifiably icky, brittle and verbose for a long time.

Bu the Java streams syntax is frankly poor. Compare the same operations in Clojure, or Kotlin, or Elixir..... it looks to me like "C++ - the bad parts" and it is annoying to write.

Sure is. I'd go as far as to say that Java syntax is poor. Then again, the question with functional interfaces is whether or not functional programming is useful to you, or how useful.

The creators of Java have always been influenced by the ML family of languages, for instance the Hotspot compiler and generational GC came out of efforts to develop very fast runtimes for the ML family.

Also the lambda syntax in Java is as concise as can be, how can you beat

   x -> x*x

? Sometimes passing a lambda (or other function) as an argument is a simpler approach to specialization than defining a subclass. That I think is mainstream and accepted in Java today. More recently Java is also incorporating other ideas from the ML family such as switch expressions and algebraic types (records and sealed interfaces.)

There is a lot more to "functional programming" than that, such as the use of persistent collections. In some cases (such as managing the symbol table in a compiler) those methods lead to good efficiency and great simplification, in other cases they are ways to make easy problems punishingly hard.

pidove builds on top of ordinary Java Collections and doesn't push more exotic approaches as does

http://www.functionaljava.org/

The pidove API is closely modeled after similar functionality in Python (the map, filter and similar operators that are built-in functions and itertools package) and also after the seq package in Objective CAML.

One thing that always struck me as awkward about the Streams API was the need to create Streams and Collectors for every operation, say you want to do

   var x = someList.stream().map(x->x*x).collect(Collectors.toList());

pidove simplifies that to

   var x = asList(map(x->x*x,someList));

Part of the simplification is that pidove operators take any Iterable as an input so there is no need to convert to a stream. This has some add-on effects in that operators like flatMap aren't creating so many heavyweight objects.

Along the way I discovered that I really liked the Collectors in the Stream API in that

   * Collectors have some quality engineering to improve numeric accuracy for sums
   * Collectors can be used inside grouping and windowing operators
   * another approach I tried took required fancy footwork w/ generics

so I decided to use them in pidove rather than write my own. I decided the main thing needed was some syntactic sugar and the Java maintainers agreed because they added this in JDK 16

https://docs.oracle.com/en/java/javase/18/docs/api/java.base...()

I like Java but I agree - whenever I write code with streams I need to reach for the documentation to figure out how to do anything.

Groovy on the other hand has very nice ways of doing the same thing that become second nature before too long.

Reply on news.ycombinator.com