General
- Why should I code Java in such an unfamiliar way?
- But we are planning to upgrade to Java 8! Shouldn't I just wait until I get native lambdas instead of littering these pseudo-functions all over my code?
- I am already using Java 8, and it has support for lambdas. Can Motif provide anything useful in an Java 8 environment?
- Why should I use Motif instead of Guava/LambdaJ/other library?
- My project already uses Guava. Should I stick with Guava or should I refactor my code to use Motif instead?
- I want to help out! How can I contribute?
General
- Why should I code Java in such an unfamiliar way?
-
Writing code by composing functions together, will arguably produce more robust and correct code. Both because your code will be closer to how you would actually verbally express the original problem you are solving, instead of thinking about looping, conditional checks, and many corner cases are handled automatically. It requires less testing to cover all the branches, simply because there are often only one branch of program flow. The branches are internal to the various API methods, and they are already thoroughly tested. So if the semantics of the expressed code makes sense, and the compiler approves the function composition, then you can be very sure that the code will work as intended, already the first time you run it.
If you write unit tests (and you should!), you will often feel that the test actually more or less repeats what you have already "declared" in the production code. In these cases it is often appropriate to move the tests to a higher level of abstraction; a bit closer to the actual problem or feature you are solving. Use a code coverage tool to verify that the different parts are executed with a higher level test. Since you don't have all these paths your code may exectute for different cases, the need for very low level unit testing diminishes, and tests can focus on higher level behavior.
It is not about being able to write lots of one-liners. You will be able to express more behavior in less code, but you should still use lines as a way of grouping your program logic into "chunks" you can reason about, and making your code readable.
- But we are planning to upgrade to Java 8! Shouldn't I just wait until I get native lambdas instead of littering these pseudo-functions all over my code?
-
For code you are writing today on Java 7, there is really no reason to wait until you eventually will be able to upgrade to Java 8 instead of starting to use Motif already now. You will get a head start to thinking in a more functional way, so you will be ready to exploit the new language features in Java 8, when you are able to upgrade. In addition, if you worry about refactoring your code to use Java 8 features later, this will actually be an easier task if the code already is done in a functional manner. The API of Motif is actually not that far from the new
Stream API of Java 8. And importantly, in code you write today, methods which accepts any of the functional interfaces of Motif, will be ready for use with Java 8 lambdas out-of-the-box. You can pass lambdas to methods which accepts Motif's functional interfaces, and the Java 8 compiler will translate the lambdas to actual implementations of
Predicate,
Fn, etc.
- I am already using Java 8, and it has support for lambdas. Can Motif provide anything useful in an Java 8 environment?
-
Indeed! Because of the way lambdas in Java 8 are translated to actual classes, you can supply lambdas directly to the Motif API. Now, you can say that the new
Stream API and Java's own
Optional type replaces Motif's
Elements and
Optional, though they have some subtle differences. In addition, Motif contains lots of constructs for composing more complex functions from simpler ones, which also can be based on Java 8 lambdas. All suggestions to make Motif more usable with Java 8, while still being Java 7 compatible, are most welcome!
- Why should I use Motif instead of Guava/LambdaJ/other library?
-
All these libraries are great ways to learn how to program in a more functional manner. You can read an (admittedly opinionated) comparison between Motif and some other librarys
here.
- My project already uses Guava. Should I stick with Guava or should I refactor my code to use Motif instead?
-
Guava, or any other library which offers implementations of various Collections, will work fine together with Motif. You don't need to actually choose one or the other. In fact, Motif focuses on being conveniently usable with existing collections instead of providing its own, so Guava's collections will work just as well with Motif as the collections in the JDK. In addition, Guava offers a much broader scope of functionality and utilities than Motif, which is more focused on functional composition.
If you already use Guava's functional interfaces, then there is a matter of which API you prefer to use with such pseudo-functions. You should probably stick with only one set of functional interfaces, as implementations of different libraries' functional interfaces will not be compatible with each other.
Should you choose to use Motif's functional interfaces and the compositions offered by the library, you have a small refactoring task to do with existing code that uses Guava's functional interfaces. For your existing function implementations, it will be a simple matter of implementing another interface, and change the name of the implemented method. Most of Guava's API which accepts functions has corresponding concept in the Motif API.
- I want to help out! How can I contribute?
- That's awesome! I can sure use some help! Anything you think are missing in Motif, do not hesitate to register it as issues. Also, this document gives some examples on specific tasks you can help out with.