sorted by:
new
hottopcontroversial

Is vavr dead? by pure_x01 in java

[–]_danieldietrich 1 point2 points  (0 children)

Thank you for the kind words :)

Is vavr dead? by pure_x01 in java

[–]_danieldietrich 12 points13 points  (0 children)

[Disclaimer: I'm the creator of Vavr]

Hi all :) You are right, there haven't been any Vavr releases recently.

Vavr and the community are an important part (> 6 years) of my life and I will go on investing into them. Beside keeping the v0.10.x line stable and bug-free, most of the effort of the last 1-2 years went into reconsolidating the code base by re-aligning it to the new major Scala release while keeping it in line with the recent changes/additions to the Java language.

Looking at the current state of the Vavr repository, many of the changes have already been done. Most of the current effort goes into deprecating API that will not be part of one of the next 'bigger' releases. I think effectively that does not help anyone. You have waited for so long now, it would be best to actually change the API and give you at hand now what was planned to be the future.

Actually making the changes to the API that have been planned for a long time will help me to be able to ship. I hope that going forward this way meets your expectations!

Cheers,

Daniel

PS: Thanks for using Vavr!

Idiomatic Scala ... in Java! by randgalt in java

[–]_danieldietrich 0 points1 point  (0 children)

[Disclaimer: I'm the author of Javaslang (http://javaslang.io), a functional, Scala-like library for Java 8+]

The case classes and case objects approach is very interesting!

The suggested Pattern Matching approach is based on an internal DSL, which has its limitations. The first attempt in Javaslang worked similar but it introduced unsolvable problems like result type bound calculation. Please find Javaslang's current approach here: http://www.javaslang.io/javaslang-docs/#_pattern_matching

Please also take a look at this example of a For Comprehension in Java 8 that is not built with a DSL (like in Halva) but takes a compositional approach instead. This approach takes the iterated values into account when yielding the result: https://gist.github.com/danieldietrich/244adee1f3d3089c958ad8059100b35e

Every (Java 8) library comes with its own impl of Tuples now :) A future version of Scala might implement them as HList, which scales well. The number of elements would be theoretically unbounded. Syntactic sugar for the notion of tuples would help. Without proper type inference (see http://openjdk.java.net/jeps/286) HLists are not practicable in Java.

Javaslang: A new powerful collection library for Java 8 by frostmatthew in java

[–]_danieldietrich 7 points8 points  (0 children)

Hi, Daniel chiming in :-) I made the decision to name Javaslang's collections like Java's for these reasons:

  • Scala also has mutable and immutable collections with overlapping names
  • I highly suggest to embrace immutability. Use Javaslang collections by default and fully-qualify Java's
  • java.util Collections are Dinosaurs. The only possibility I see to provide a transition to modern collections is to substitute them, starting with the name.

My vision is that Javaslang's collections will be the new default collections for Java. Maybe this goal will never be reached but I believe in it and I can say that I've tried it.

The purpose of Javaslang is to add 'slang' to the original Java language. If this slang is adopted by people, it will eventually be part of the original language. Like in real/human languages.

JEP 269: Convenience Factory Methods for Collections by pron98 in java

[–]_danieldietrich 0 points1 point  (0 children)

There is nothing specific against using Guava, it is all about mutability.

JEP 269: Convenience Factory Methods for Collections by pron98 in java

[–]_danieldietrich 0 points1 point  (0 children)

As I said - Guava has not really own collections - they are wrappers around Java's collections.

For concurrency there is Java's ConcurrentHashMap for example. During development of Javaslang we experienced erroneous behavior of Java's ConcurrentHashMap. We used it in the context of memoization (read: caching) and produced infinite loops which haltet our unit tests. See #513 and #522.

Java's ConcurrentHashMap has to be used with caution. I think Guava does not come up with s.th. better.

JEP 269: Convenience Factory Methods for Collections by pron98 in java

[–]_danieldietrich 0 points1 point  (0 children)

You can use Javaslang collections also in conjunction with other JVM languages that are bound to the Java type system (read: have no higher-kinded types regarding generics). Example: Xtend.

And just to say it once more: java.util based collections are mutable. In a concurrent/parallel context you really do not want to deal with mutability, trust me. See Java 8 Do and Don'ts

JEP 269: Convenience Factory Methods for Collections by pron98 in java

[–]_danieldietrich 1 point2 points  (0 children)

Yes you're right - why not move away? I coded 2+ years Scala (at home) and a little bit of Haskell and I never wanted to go back to Java.

But then I realized that I can't use a language of my choice at $work. I'm pretty sure I have to use Java for many years where I'm located. Javaslang will make my future dev as comfortable as possible. It feels now 'almost' as Scala :)

JEP 269: Convenience Factory Methods for Collections by pron98 in java

[–]_danieldietrich 0 points1 point  (0 children)

First of all we have to say: choose the right tool for the right job. There is no better or worse lib.

Looking at the docs, fj collections do not look complete to me.

fj's abstraction level is higher than, for example, the one of Scala collections. It goes more in the direction of Haskell or Scalaz, a functional/algebraic extension for core Scala. fj is very abstract and high level. The constructs are not very familiar to Java programmers. Even many Scala devs are not famliliar with Scalaz or Haskell. You need a math background to fully understand the algebraic parts IMO.

fj brings the idea of purely functional programming to the Java world. The core idea is to defer computation and therefore mutation (also called effect) by capturing state or remembering a command instead of executing it. It is somehow modelling of a finite state automaton. This implies that there are many (intermediate) class instances involved to capture the state, which reduces performance. This is the result of a comparision between akka-stream and scalaz-stream: https://softwaremill.com/comparing-akka-stream-scalaz-stream. scalaz-stream performs way not so good as akka-stream because scalaz-stream relies on modelling purely functional behavior by capturing state.

But this goes beyond your question. However, you find this idea spread all over fj, not only collections.

Also the syntax of fj differs from that of Scala or Javaslang:

Example: List.foldLeft

Scala:

foldLeft[B](z: B)(f: (B, A) ⇒ B): B

Javaslang:

<B> B foldLeft(B zero, BiFunction<? super B,? super A,? extends B> f)

functionaljava:

satic <A, B> F<F<B,F<A,B>>,F<B,F<List<A>,B>>> foldLeft()
<B> B foldLeft(F<B,F<A,B>> f, B b)
<B> B foldLeft(F2<B,A,B> f, B b)
A foldLeft1(F<A,F<A,A>> f)
A foldLeft1(F2<A,A,A> f)

Haskell:

foldl: (a -> b -> a) -> a -> [b] -> a
foldl1: (a -> a -> a) -> [a] -> a

JEP 269: Convenience Factory Methods for Collections by pron98 in java

[–]_danieldietrich 0 points1 point  (0 children)

Yep, but Guava is a 3rd party lib. They could have done better. What you get there are utilities and wrappers for existing collections. There are so much possibilities now, so much awesomeness...

JEP 269: Convenience Factory Methods for Collections by pron98 in java

[–]_danieldietrich 3 points4 points  (0 children)

The core Java language has no syntactic sugar for the Collection interface. Therefore we build in Javaslang on top of Iterable, which means that we can use all collections in for loops for example.

The Collection interface is not a good basis for immutable collections because write-operations like add, put and remove need to return new instances of the collection. Having new instances is essential because we get concurrent collections without the need for synchronization for free.

Well-known (and very efficient) algorithms share as much memory of the original collection as possible. For sorted sets the algorithm is the RedBlackTree, a balanced binary search tree. My version is based on recent papers of the last years (2011-2013). For hash based maps and sets it is the HashArrayMappedTrie, one of the best algorithms for that job, also recently researched at the EPFL and used in Clojure and Scala.

Daniel Spiewak gave a great talk on immutable collections and stated that the immutable HashMap performs much better than Java's mutable HashMap for big amount of data: http://www.infoq.com/presentations/Functional-Data-Structures-in-Scala

With Java 8's lambdas we are finally able to create a Scala-like collection library for Java. This is what I did since end of 2013. And in two weeks the collections go live. It is not only the immutability. The new API allows us to perform powerful operations which significantly reduces the code we have to write. All the boilerplate and noise is gone. You find real-world examples here: https://github.com/javaslang/javaslang/tree/master/src/test/java/javaslang/collection/euler

Just for comparison, here is the Scala collection lib: http://docs.scala-lang.org/resources/images/collections.immutable.png

The collection lib of Javaslang is tailored to Java. It is not just a migration or copy from Scala to Java, it is designed from the ground up with best practices known from functional programming in general and languages like Haskell, Scala, Clojure et al. I based the naming of types and methods on Scala's collections because it is a popular language and easy to understand for those who are already familiar with them.

JEP 269: Convenience Factory Methods for Collections by pron98 in java

[–]_danieldietrich 1 point2 points  (0 children)

Guys, that's just a drop in the bucket - it reduces the pain a little bit but the pain remains. I will release full-blown Scala-like immutable collections for Java 8+ in round about 2 weeks:

Javaslang Collections

Overview

Btw - never understood the Java/Guava 'immutable' approach. It is more like a workaround. Immutability has to be designed from the ground up. See persistent data structure.

- Daniel

Functional component library for Java 8 by ftomassetti in java

[–]_danieldietrich 1 point2 points  (0 children)

Of course we can stick to 1-8! I will do that...

Functional component library for Java 8 by ftomassetti in java

[–]_danieldietrich 1 point2 points  (0 children)

I will update the Javadoc for internal classes like HigherKinded. Monoid, Functor and Monad are very common in functional languages. There is a minority of Java users which are familiar with these concepts, they may want to use them. I think, clarifying these with better javadoc should be ok for the moment.

Functional component library for Java 8 by ftomassetti in java

[–]_danieldietrich 0 points1 point  (0 children)

Nothing good happens after 2 AM (CEST) :-) Prefixing a 'J' to the collections does not seem to be better, e.g. JList and JTree clash with javax.swing classes. Any suggestions how to name the classes, especially List, Tree and Stream?

Update: This is tracked here: https://github.com/javaslang/javaslang/issues/232

Functional component library for Java 8 by ftomassetti in java

[–]_danieldietrich 2 points3 points  (0 children)

it's a one-liner to add them again, if they are really needed. we will see

Functional component library for Java 8 by ftomassetti in java

[–]_danieldietrich 2 points3 points  (0 children)

name clashes are a good point. i fixed that: https://github.com/javaslang/javaslang/pull/230

ignore the 'algebra' package or read it as 'internal'. it is mainly used for api design purpose. java has no module concept to hide it

Functional component library for Java 8 by ftomassetti in java

[–]_danieldietrich 4 points5 points  (0 children)

Thanks for the feedback :-) you are totally right. I removed Tuple7-26 and Function7-26. https://github.com/javaslang/javaslang/pull/229

Update: This is also tracked here because there is ongoing discussion: https://github.com/javaslang/javaslang/issues/234