Micro DSL list finder versus Jedi

Toby "blog-a-lot" Weston wrote about a micro DSL style list finder that he is playing around with. His list finder looks like this:

Employee candidate = find(interviewee).in(applicants).using(superStrictCriteria);

where the list finder uses a custom comparator interface (in this case the superStrictCriteria) to determine if a target (interviewee) matches any of the list elements (applicants). I think this DSL is quite nice-but there is another library that does this for you already in a similar fashion-Jedi. Jedi is a functional programming library that allows you to express your ideas in a very computer-sciencey way. Impress your collegues and try it today!

The above example, using Jedi can be done as follows:

Employee candidate = first(select(applicants, superStrictCriteria));

where superStrictCriteria is a Filter interface which essentially boils down to:

public interface Filter <T> {
  boolean execute(T value);
}

so in this case could be:

new Filter<employee>() {
  public Boolean execute(Employee employee) {
      return superStrictCriteria.canBeAnsweredBy(employee);
  }
}

(Note: in the actual Jedi code the Filter interface extends Functor-but I left that bit out for brevity)

An advantage that you get with Jedi is that there are already a lot of functional ways to handle lists. Have a look in the jedi.functional.FunctionalPrimitives class. You can mix and match pretty much any of these functional primitives to attain quite complex list handling and criteria selection. And if this is not enough, Jedi gives you Coercions (eg. converting lists and arrays), Comparables (eg. equal, lessThan, min), FirstOrderLogic (eg. exists, all, not) and much much more!

So, although I'm not one for reinventing the wheel (I would normally use Jedi for what Toby describes), I do like to explore new styles of coding-just so long as the substance is there.

Substance Over Style

I find that too much effort and emphasis is put on coding style. We blindly follow the guidelines and styles that we've always done, without questioning why.

In an Agile process, one of the goals that we strive for is continual improvement, continual quality process review. With every line of code that we write, we should do the same. Question why we are writing that code, or why we are writing it that way.

A good example of this is the if statement in Java. One of the commonly followed guidelines is that you should alway enclose the block of an if statement in brackets-even if it only one line of code. For example:

if(toast.isBurnt()){
  eat(somethingElse);
}

instead of:

if(toast.isBurnt()) eat(somethingElse);

A traditional argument for this is that a developer may come along and add more code into the if block, but forget to add the brackets. Thus following a coding style convention will avoid these problems.

What is wrong with this statement? In a proper Agile environment, where tests are written first, surely this 'problem' will be caught the very next time you run your unit tests? You know, testing the substance of your code?

For my money, I'd prefer the developer to be writing test first code. As long as the substance can be proven, I'm not too bothered with the style of the code (within reason, of course!).

So, put your effort into the substance, and worry about the style later.