The Problem

You have a sequence, and you want to find the first (or any) element that matches some criteria. Of course your first thought should be find. However, often it is the case that the predicate passed to find would be pretty complex — perhaps too complex to render meaningful code. Often in these cases it would yield much more readable, understandable code to break the predicate in to two parts: the first portion is a mapping, and the second is a predicate test on the mapped value.

For example, you have a list of file names, and you want the first name that references a directory that contains at least one JPG image file. Using just find, you get a pretty hairy predicate function:

Code block

val fileNames: Seq[String] = ...
 
val dirWithJPGs = fileNames find { name =>
 val file = new java.io.File(name)
 if(file.isDirectory) {
  (
   file.list.map { fn => new java.io.File(file, fn) }
     map { f => f.isFile && fn.endsWith("jpg") }
  ) reduceLeft (_ || _)
 } else { false }
}

Its pretty hard to see what’s going on there without staring at it for a bit. But the English description is pretty clear: Each name in the fileNames list is being mapped to a boolean value indicating whether or not the File is a directory AND contains at least one file ending in “jpg”.

Using maps and filters, we can get something a lot easier to understand in code:

Code block

val fileNames: Seq[String] = ...
val dirWithJPGs = fileNames map { new java.io.File(_) } find { dir =>
    dir.isDirectory &&
        (for(file <- dir.list.map { n => new java.io.File(n) })
             yield file.getName.endsWith("jpg")
        ) reduceLeft (_ || _)
    }
  }

I find that a bit easier to read. An additional filter call is going to make it even easier to read:

Code block

val fileNames: Seq[String] = ...
val dirWithJPGs = fileNames map { new java.io.File(_) } filter {_.isDirectory} find { dir =>
  (for(file <- dir.list.map { n => new java.io.File(n) })
       yield file.getName.endsWith("jpg")
  ) reduceLeft (_ || _)
  }

First the map call translates the initial String values in to something suitable for testing (java.io.File instances). Then any complicated test is cracked in to a series of one or more filters, with the final predicate applied with a find.

The final trick, which is really necessary to make this work, is to use a non-strict view of the original sequence, not the original sequence itself. If you map the original (strict) sequence, you end up mapping all elements before testing any of them. And if you’ve cracked your predicate in to intermediate filters, then each filter would also need to be applied to all members. But if you map a view, then each element in the view is mapped, filtered, and finally tested individually before moving on to the next.

So, say your looking for the first item in a 100,000-element sequence that solves some predicate function — you’re going to want to map and test the items individually. Making a view of a sequence is as easy as using the sequence’s view method.

Code block

val fileNames: Seq[String] = ...
val dirWithJPGs = (fileNames.view) map { new java.io.File(_) } filter {_.isDirectory} find { dir =>
  (for(file <- dir.list.map { n => new java.io.File(n) })
       yield file.getName.endsWith("jpg")
  ) reduceLeft (_ || _)
  }

The Dunning–Kruger effect is a cognitive bias in which unskilled people make poor decisions and reach erroneous conclusions, but their incompetence denies them the metacognitive ability to appreciate their mistakes.^[1] The unskilled therefore suffer from illusory superiority, rating their ability as above average, much higher than it actually is, while the highly skilled underrate their own abilities, suffering from illusory inferiority. This leads to the situation in which less competent people rate their own ability higher than more competent people. It also explains why actual competence may weaken self-confidence. Competent individuals falsely assume that others have an equivalent understanding. As Kruger and Dunning (1999) conclude, “Thus, the miscalibration of the incompetent stems from an error about the self, whereas the miscalibration of the highly competent stems from an error about others”

I’m ruminating on how I’ve been on both sides of that effect before. Being considered competent in one sphere of life (programming), I’ve made both mistakes described above:

1. Over-estimating my ability to reason and come to good conclusions about subjects I’m really not very studied in. I’m been very guilty of spouting off about politics, economics, all sorts of things I’m not qualified to have an opinion on.
2. Under-estimating what I have to offer. See how many posts I have in this blog? Not nearly as many as I should. I am prone to self-editing, assuming that if I find something cool or valuable in programming, it would already be really obvious to others, so much so as to make my post seem dumb.

Now that I have a name for the effect that’s in play I’m going to try to try to do less of the former, and more of the latter!

Just read “Programming and fallacies” on Michael Galpin’s blog.

Made me think of the very (very, very) old “Love is a Fallacy” humor writing by Dobie Gillis (book) author Max Shulman (– please read that some time, its such a riot). And when I say “old” I mean the original story was old when the old black-and-white Dobie Gillis TV show was on. In case you aren’t familiar, that was the show that launched the career of “Gilligan’s Island”‘s Gilligan star Bob Denver before Gilligan.

But my segue-adled mind doesn’t stop there, because Dobie Gillis is no doubt the best example of modern humor a logical mind can ever read. And who defined modern humor? No shit: Freud. You probably didn’t know he wasn’t famous in his early career not for his mommy-mangled psycho-sexual theories — his PhD thesis in fact was the seminal text on laughter and humor.

That I know all those bizarrely ancient pop cultural references, and you don’t,  means that

1. I am cooler than you;
2. I need more focused entertainment on Friday nights; and
3. you don’t need to worry about competing with me because my brain is constantly routed down these fruitless tracts.

In addition to normal GWT, here’s the super cool topics we’ll be covering:

• Code splitting — dynamically download different parts of the GWT app for efficiency
• GWT integration with poplar toolkits (e.g., jQuery, ExtJS, etc.) through JSNI
• Code generators and resource generators
• Mashups and cool service integrations
• Lots more!

This course is especially good for J2EE developers who don’t feel completely (or even at all) comfortable in JavaScript or the browser environment — you will end your time with us with some amazing “Browser Fu“!

1. Abstract Type Members. Prior to reading the paper, I figured abstract type members are just another way of expressing type parameters — that is, generic type params in Java. Not so! Abstract type members turn out to be an incredibly important  way of promoting code re-use through subtype parameters.
2. Traits. “Module mix-in components” is the term used in the paper, but in Scala this means traits. The paper explains how traits promote code re-use through much more flexible composition than Java’s interfaces+single base class.
3. Explicit Selftypes. Not so mind expanding as abstract type members and traits, but definitely a concept that needs anchoring for someone coming from Java or similar OO languages.