Bolts 1.0 functional programming library for java released

Discussions

News: Bolts 1.0 functional programming library for java released

  1. Bolts is a functional programming library for Java, it also contains easier to use collections. Bolts addresses JDK collections weakness. Unlike related projects, bolts collection interfaces extend JDK collections, and collection operations are collection methods. Examples: CollectionsF.list("1","2","4").map(IntegerF.parseF()) yields list of integers 1, 2, 4. CollectionsF.list(0, 1, -3, 2, 0).filter(IntegerF.naturalComparator().gtF(0)) yields 1, 2 CollectionsF.list("a,b", "c", "d,e,f").flatMap(StringF.splitF(",")) produces list of letters: "a", "b", "c", "d", "e", "f" Bolts contains extended collection interfaces, strongly typed function objects as well as common funcitonal abstractions — Option, Tuple*, Either. Please visit bolts home page for the source code, documentation and more examples.

    Threaded Messages (18)

  2. What is the license?[ Go to top ]

    I could not find what the license is on the web site.
  3. Licence is MIT[ Go to top ]

    License is MIT.
  4. Bolts addresses JDK collections weakness.
    Could you please outline some example of such weakness? Performance or functional?
  5. JDK collection weakness[ Go to top ]

    Bolts addresses JDK collections weakness.


    Could you please outline some example of such weakness? Performance or functional?
    JDK collections arhorithms are fast enough, I blame collections API. Some examples of what is missed in JDK collections. * JDK collections has no static factory to create set of elements: CollectionsF.set(1, 2, 3) * JDK List has no plus method to concatenate lists, union or intersect two sets in the new instance in a single line. * List miss take/drop operations, that are easier to use then subList. * It is often nice to have sort() method of Collection that returns sorted list of elements. * There is no easy way to convert List to int[] * Map miss such trivial and frequently used methods like getOrElse, getOrThrow, and getOrElseUpdate. * Collection miss mkString(sep) method that joins elements using any specified separator (not hardcoded comma). And * bolts implement must have Option and Tuple2 classes, and JDK collections lacks all Option and Tuple2 related methods, like ListF.firstO or ListF.zip. * JDK collections do not provide functional operations (map, filter). Bolts provides interface to collections, bolts does not reimplement JDK collection algorithms.
  6. Re: JDK collection weakness[ Go to top ]

    Thanks for the clarification. Unfortunately it is not for me, I'm happy to use java.util.concurrent.* and java.util.* for such tasks, the few missings seem to be easy to have anyway (e.g. copy paste a few class is not always evil if it reduces one extra dependency).
  7. Google Collections vs Bolt[ Go to top ]

    Google Collections has lots of builder methods to build collections. How would you compare Bolt to Google Collections?
  8. Re: Google Collections vs Bolt[ Go to top ]

    Google Collections has lots of builder methods to build collections. How would you compare Bolt to Google Collections?
    You are right that collection construction operations are similar between Google collections and bolts. Bolts and Gc focus on different things. Gc introduce several new collection types (like multiset, bimap). Bolts focus on making existing collections (list, set, map) easier to use. The common thing of Gc and bolts is a presence of functional utilities (map, filter, etc.) The unique feature of bolts is an extension of JDK collection interfaces. Gc implement additional collection operations as static methods of utility classes, while bolts collection operations are instance methods of extended collections.
  9. car,cdr,cons?[ Go to top ]

    Hi, what about car,cdr, and cons? You have first, but no counterpart for cdr. Just an idea. Think would be nice to have. /Oliver
  10. car, cdr, and cons[ Go to top ]

    Hi,

    what about car,cdr, and cons? You have first, but no counterpart for cdr. Just an idea. Think would be nice to have.
    Oliver, I'm not sure these methods fit in OOP style, that is enforced by the Java language. I don't know how to implement these method to make them useful (which method names and signatures of which classes?) But if you have concrete proposal, please share.
  11. Re: car, cdr, and cons[ Go to top ]

    Oliver, I'm not sure these methods fit in OOP style, that is enforced by the Java language. I don't know how to implement these method to make them useful (which method names and signatures of which classes?) But if you have concrete proposal, please share.
    car returns the first element in a collection and cdr the remaining objects (all objects but the first). In what way is this contradictiory to OOP? Here are the examples you made in your post written in Smalltalk: #('1', '2', '4') collect: [ :each | each asInteger ] ==> #( 1, 2, 4 ) #( 0, 1, -3, 2 ) select: [ :each | each > 0 ] ==> #( 1, 2 ) I don't think any Smalltalk developer would get the idea that these simple closure evaluations had anything to do with functional programming. Wonder why you call your framework 'functional programming library'. What you did there is some attempt to mimic closures in Java. If I need my custom comparator, because your library does not provide it, then I have to add some filter method to my custom class. This way I have code that is a little less verbose than inner classes, but still lacks conciseness and expressiveness of closures.
    I'm not sure these methods fit in OOP style, that is enforced by the Java language.
    Oh boy ...
  12. Why 'functional programming library'[ Go to top ]

    I don't think any Smalltalk developer would get the idea that these simple closure evaluations had anything to do with functional programming. Wonder why you call your framework 'functional programming library'.
    Functional programming emphasizes, among other things, higher-order functions and pure functions. Bolts provides some support for composing functions (FunctionXXX.andThen) and simple currying (FunctionXXX.bindYYY). And it provides a collection library that makes it easier to write pure, effect-free code that processes maps/lists/tuples/objects-with-mapper-methods based data structures. Of course, it doesn't get rid of all Java verbosity, and other important functional stuff like lazy evaluation still has to be emulated by Function-s -- but it helps to write cleaner code. As for cons/cdr -- well, technically cdr may be written as myList.drop(1), and cons as Cf.list(headElement).plus(tailList) (or tailList.plus1(newLastElement), but it adds element at the end). However, these wouldn't perform as well as the "real" cdr/cons because bolts' collections are kept persistent by creating new copies, not by sharing common parts with the previous versions. For this reason it might be a good idea to keep longer list-related names so that the developer wouldn't inadvertently use these operations in performance-critical parts of the code.
  13. What's the difference between CollectionsF.list() and Arrays.asList()?
  14. What's the difference between CollectionsF.list() and Arrays.asList()?
    CollectionsF returns ListF, Arrays.asList returns List. CollectionsF has also set() method that returns set, arrayList that returns ListF that behaves like ArrayList, and other handy methods.
  15. If the goal is to get all code into one line, why not just use Perl? :-)
  16. bolts vs. perl[ Go to top ]

    If the goal is to get all code into one line, why not just use Perl? :-)
    Perl does not help to write readable code. Actually, bolts is inspired by the Scala language/standard library.
  17. Functional and OOP => Scala[ Go to top ]

    Just use Scala if functional style is something you need (which I recommend for sure). Regards, Nikita Ivanov. GridGain - Cloud Development Platform
  18. Re: Functional and OOP => Scala[ Go to top ]

    Just use Scala if functional style is something you need (which I recommend for sure).
    Yes, bolts is highly inspired by Scala. The problem is that Scala is not yet ready for big projects.
  19. late reaction but, Nice lib. Build one too long ago to remember to address these shorts in the collections. But creating new classes etc is making it too complex for it's usage.