TSSJS 2009: No More Loops with LambdaJ
Speaker: Mario Fusco, LambdaJ creator
What makes me think this talk is going to have something do to with the lambda calculus, a subject I recall enjoying greatly during my Comp-Sci degree?
So… the heavily accented Mario describes the motivation for creating LambdaJ: To create a way to select beans of particular properties without all the hassle of loops i.e. iterating.
The result: A DSL to manipulate collections in pseudo-functional, statically-typed way.
LambdaJ comprises 2 main features: forEach and sort. Each of these methods are importable via static import.
forEach(personsInFamily.setLastName(„Fusco“);
sort(persons, on(Person.class).getAge());
The result is a compact was to express collections-based operations as a single line of code as opposed to using a sometimes complex loop, locally declared variables etc.
Mario shows several examples, which make this compactness quite clear.
However, he goes on to points out that LabmdaJ five times slower (average) than pure Java with his examples. Performance takes a because of all the reflection that goes on. However, he performance hit thinks this is unlikely to prove to be the bottleneck in practice.
Some other limitations:
• Cannot infer type to be returned because collection class parameter is not reified at runtime.
• Cannot use with final classes because cannot create dynamic proxy for final class.
The LambdaJ project is open-source and is hosted at Google Code.
Question raised: Why not use hibernate criteria query API? Mario: Yes, can use this.
LambdaJ is typically used in business layer after data has been fetched from DB (e.g. via hibernate.)
Presumably, then – for LambdaJ to be worth while to use in practice – you need to have a situation where multiple evaluations are performed against a previously fetched result set. This would then (potentially) save multiple fetches against the DB, depending on the queries involved.
Mario’s slides, which show plenty of code-samples, are available here.
Summary: I sense a slight buzz of skepticism emanating from the audience and my feeling is reenforced when very few questions are posed. Whilst LambdaJ code is significantly less verbose than its Java equivalent, I suspect the situations in which it could be used are relatively few in number.
Oh: And I was totally off about LambdaJ being in someway related to the Lambda Calculus. Neither have loops, that’s true, but the commonality ends there.
