London Lambdas Hackday: Developer Practices

[Richard Warburton]

Comments about how developers were using lambdas in our hack session.
In no particular order:

1. addAll vs into

A developer had an interable that he wanted to put all the values from
into a collection.  He tried to use addAll, but it works over a
collection, not an iterable.  He could have used into and flipped
dispatch object with the argument, but it wasn't obvious to do that.
This might be just a case of 'old habits die hard' but it might also
be

2. TDD

Only 1/5 of the developers at our hackday were using TDD.  I’m unsure
as to whether this reflects preferred practices or whether they just
considered spiking is the best thing for experiments.    We will be
running a JSR-310 hackday next week and many of the activities will be
Test driven, so it'll be interesting to see what happens there.
Martijn, "I think this is indicative of the % of developers who
actually practice TDD voluntarily"

3.  Some feedback from Martijn:

I noticed that I happily started using a chaining idiom in my code, e.g.

return students.filter(student -> student.getAge() > 18).into(new
ArrayList<>());

Given my lack of recent functional programming expertise, I think this
is a good thing. But I'm a little concerned that the chaining idiom
becomes hard to read for non-functional programmers, some education
might be required.  Perhaps in the educational material, samples are
laid out like so (each 'chained' method is lined up with the method
before it):

return students.filter(student -> student.getAge() > 18)
                   .into(new ArrayList<>());

You might also find Java developers wanting to pull everything back
into a local variable, e.g.:

List<Student> filteredStudents = new ArrayList<>()
return students.filter(student -> student.getAge() > 18).into(filteredStudents);

Another example pulling the Predicate in locally:

Predicate<Student> isLegal = (Student student) -> student.getAge() > 18;
return students.filter(isLegal).into(new ArrayList<Student>());

One other (unecessary?) idiom they might use is assigning back to a
collection that is the result of the filter/reduce/map/whatever, e.g.:

List<Student> legalStudents = new ArrayList<>();
Predicate<Student> isLegal = (Student student) -> student.getAge() > 18;
legalStudents = students.filter(isLegal).into(legalStudents);
return legalStudents;
// as opposed to
// return students.filter(isLegal).into(legalStudents);

4. Type inference

IDE or compiler support might be needed to teach developers that Java
is smarter than they think with regards to Type inference.  For
example a refactor to do the following:

// Predicate<Student> isAdult = (Student student) -> student.getAge() > 18;
// Can be written as:
Predicate<Student> isAdult = student -> student.getAge() > 18;

Perhaps a -lint option on javac for this kind of thing would be
useful?  I guess it ultimately depends on how the expected idiom for
writing this code works.

5. Function Composition

There was a genuine desire from people to have function composition.
This was somewhat driven by people with experience of functional
programming in other languages, but there were still scenarios where
it seemed like the cleanest idiom.  The lack of function types seems
to make it hard to introduce function composition in the general case,
but is there an expectation that composition methods will be provided
for all the functional core library interfaces?