The hidden mechanics of humor?

Humor is the embodiment of a latent method that discovers false inference in the brain. What an intriguing thought! Does this imply that a logician and a comedian never mix up? I simply couldn't resist to re-quote the Slashdot post [1]:

"The sense of humor is a ubiquitous human trait, yet rare or non-existent in the rest of the animal kingdom. But why do humans have a sense of humor in the first place? Cognitive scientist (and former programmer) Matthew Hurley says humor (or mirth, in research-speak) is intimately linked to thinking and is a critical task in human cognition because a sense of humor keeps our brains alert for the gaps between our quick-fire assumptions and reality. 'We think the pleasure of humor, the emotion of mirth, is the brain's reward for discovering its mistaken inferences,' says Hurley, co-author of Inside Jokes: Using Humor to Reverse-Engineer the Mind. With humor, the brain doesn't just discover a false inference - it almost simultaneously recovers and corrects itself. For example, read the gag that's been voted the funniest joke in the world by American men. So why is this joke funny? Because it is misleading, containing a small, faulty assumption that opens the door to a costly mistake. Humor is 'when you catch yourself in an error, like looking for the glasses that happen to be on the top of your head. You've made an assumption about the state of the world, and you're behaving based on that assumption, but that assumption doesn't hold at all, and you get a little chuckle.'"

[1] http://science.slashdot.org/story/11/11/27/037237/the-science-of-humor

Get a taste of Stanford: Online lectures 2012

These days I'm having too many irons in the fire. To give you some hints, there's more coming which sheds lights on turning non-negative matrix factorization into an embarrassingly parallel problem (plus avoiding the painful hadoop overhead [1]) and something new which hopefully combines machine learning methods with agile development methodologies to solve a well-known ancient problem in software engineering.

Anyhow, to keep this blog alive, here's the latest from Stanford. Anyone who has listened to the initial three courses (Database System, Machine Learning and Artificial Intelligence) surely has enjoyed their quality and will enlist again. They are back with an incredible list of free interactive video lectures on machine-learning:

• Machine Learning http://jan2012.ml-class.org/
• Human-Computer Interaction http://www.hci-class.org/
• Natural Language Processing http://www.nlp-class.org/
• Game Theory http://www.game-theory-class.org/
• Probabilistic Graphical Models http://www.pgm-class.org/

There is also a set of basic introductions to CS, SaaS and Entrepreneurship. The lectures are splitted into weekly video sessions and optional quizzes or programming exercises.

The offerings will start this January, so don't miss your spot and sign up now!

[1] https://mpi-inf.mpg.de/~rgemulla/publications/rj10481.pdf

A giggly polymorphic view on stereotypes

Did you ever wonder why developers are so slow? How project managers can spend a day doing nothing? Or, why designer is a job title?

I guess most of you have a specific stereotyp in mind. But does this generalize to a broader crowd? Are stereotypes typical singleton objects by definition? Or should we introduce "conditional" stereotyps depending on the point of view ...

Let's put this literally into perspective:

I hope you did not expect something deep here ... :)

In a sense, this reminds me of Brave New World ... "I'm really awfully glad I'm a Beta, because I don't work so hard. And then we are much better than the Gammas and Deltas. Gammas are stupid."

How to avoid try/catch blocks

As I'm running low on time these days, but want to keep the steady flow of Scala buzz alive, here's another simple trick. Dealing with Java I/O you probably know the unavoidable burden of exception handling:

import java.io.*;

public final class CatchMeIfYouCan {
  public static void main(String ... args) {
     BufferedReader reader = null;
     try {
        reader = new BufferedReader(new FileReader(...));
        String line = null;
        while((line = reader.readLine()) != null) {
             ...
        }
     } catch(IOException e) {
             ...
     } finally {
        try {
            if(reader != null) reader.close();
        } catch(IOException e) {
             ...
        }
     }
  }
}

Ouch! It takes 16 lines of code to read some lines from a file. In an ideal world we would be able to factor out this reoccuring pattern of nested try/catch blocks.
What we could do in Java is to simply put the logic which operates on the "line" string into another class and pass it to a factorized version of the code above:

public final class StillNotThere {
 interface Read { void line(String str); }

 private static void read(Read read) {
    BufferedReader reader = null;
    try {
       reader = new BufferedReader(new FileReader(...));
       String line = null;
       while((line = reader.readLine()) != null) {
            read.line(line);
       }
    } catch(IOException e) {
            ...
    } finally {
       try {
           if(reader != null) reader.close();
       } catch(IOException e) {
            ...
       }
    }
 } 

 public static void main() {
   read(new Read() { public void line(String str) { ... } });
 }
}

Looks better! But still feels clumsy to define an anonymous class and ... nah. In Java 7 the try / catch syntax was enhanced to support the java.lang.AutoClosable interface. This effectively removes most of the boiler plate code, but at the same time reflects how limited the expressive power of Java is. We don't want to touch the syntax of a language just to get some minor things right.

So, let's see what we can do about it in Scala! We introduce a function named "using" which takes an I/O handle (using duck-typing to ensure the type defines a close() method) and in turn passes it to a given function f.

object IO {
  def using[R, S <: { def close() }](s: S)(f: S => R): R = {
    try {
      f(s)
    } finally {
      if (null != s) {
        try {
          s.close()
        } catch {
          case _ => {}
        }
      }
    }
  }
}

Equivalent to the Java code above:

object Better {
  def main(args:Array[String]) = using(new Reader(...)) {
    reader => reader.getLines.foreach(line => ...)
  }
}

I hope your brain screams "DAMN!". Doesn't "using" almost look like a first-class citizen?

Calling a set of n-ary functions ... in a weird way

Here's another brain teaser. It just happened that I needed a weird construct for my tiny graph-rewriting framework.

What I'm looking for is something similar to this:

val r1 = Rule(
   left = Graph(Node("a")),
   right = Graph(Node("a") ~> Node("b")),
   bind = ( (Node("a"), Node("b")),
      { (a:Node, b:Node) => b.foo = a.foo } ) )

To put it in words, the left-hand side of rule r1 looks for an arbitrary node (here "a" is just an symbolic id within the scope of the rule). If the graph contains such a node (or: it is not empty), the right-hand side extends the graph by a new node "b". Finally, the binding step assigns free variables of "b". The tricky part here is the signature of the "bind" argument. The first argument is a n-ary tuple identifying a set of nodes which are in turn passed to the second argument (a function).

Now lets put on the glasses of "abstraction and genius" and have a second look. Actually what we really want is to call a n-ary function given a n-ary tuple of arguments. Of course these arguments can be transformed prior to passing them to the function, but our glasses hide these details from us ...

Okay then lets get into the specifics here. This is what our magical method which calls a set of n-ary functions should look like:

val f = { (a:Int, b:Int) => println(a+b) }
val e = { (a:Int, b:Int, c:Int) => println(a+b+c) }

call( ( f, (1, 2)), (e, (1, 2, 3) ) ) // prints 3, 6

The function 'call' simply takes an arbitraty set of 2-tuples (function, args). But how the heck can we express this in Scala?

Well, it turns out Scala provides the means implement this without much hassle:

• Tuples: Yes! Tuples as first-class citizen in Scala e.g. ("a", "b", "c")
• Kleene closure T*: Not so sure the term really fits, basically it's the n-ary cartesian product or var-args of type T
• Implicit conversions: If a type conversion A -> B is required to e.g. match a function signature, Scala tries to call a user-defined f : A -> B (known from C++)

It still requires some more backgrounds to put this together. Tuples are represented by TupleN types where N denotes the number of arguments the tuple holds. Product is the base trait of TupleN.
Accordingly functions are represented by FunctionsN types. Note that the function tupled() turns Function2[A,A,R] into Function1[Tuple2[A,A],R] where Tuple2 <: Product.

What we end up with is:

def call(p: Tuple2[Function1[Product,Unit], Product]*) = 
{ p.foreach(f => f._1(f._2)) }

implicit def func2tupled2[T](f:(T,T) => Unit) = 
{ f.tupled.asInstanceOf[Function1[Product,Unit]] }
implicit def func2tupled3[T](f:(T,T,T) => Unit) =
{ f.tupled.asInstanceOf[Function1[Product,Unit]] }
      
val f = { (a:Int, b:Int) => println(a+b) }
val e = { (a:Int, b:Int, c:Int) => println(a+b+c) }

call( ( f, (1, 2) ), (e, (1, 2, 3)) ) // prints 3, 6

I hope your brain screams "WOOT!". Read it from the bottom up. The function 'call' takes e,f which signatures are converted from Function2[Int,Int,Unit] and Function3[Int,Int,Int,Unit] to Function1[Product,Unit] by func2tupledN. At last, 'call' invokes each function f and passes a tuple holding the arguments.

Scala the next Java: What is the Buzz All About?

Have you ever wondered what the entire Scala buzz is all about? What you may already know:

"Scala is a general purpose programming language designed to express common programming patterns in a concise, elegant, and type-safe way. It smoothly integrates features of object-oriented and functional languages, enabling Java and other programmers to be more productive. Code sizes are typically reduced by a factor of two to three when compared to an equivalent Java application." [scala-lang]

To put it short: Scala is a hybrid object-oriented and functional programming language, runs on top of the JVM and is equipped with an expressive static type system.

So, Scala is the next Java, you say ... are you nuts? Probably yes, there's a disturbing "Scala is too complex for the average programmer" conspiracy. I'm not eager to trigger a war of the worlds, but if you are one of these folks, don't panic and try to give it a different perspective:

• Scala is a superset of Java: It does not force you to use fancy syntax, but rather gives you the freedom to expand your arsenal gradually
• Progress requires change: You want a statically typed language with improved expressiveness and powerful idioms, but by no means touch complexity! Oh boy ...

If you are willing to learn and want to advance, then Scala is your best bet for a long term replacement of Java. Probably, the most obvious question is: How does Scala compare to its (other) direct competitors?

Why would I choose Scala over Java?

1. Expressiveness improves readability and reduces code size (see features below)
2. Sophisticated type system and type inference leads to robust and compact code
3. Extensive support for internal/external DSLs

Why would I choose Scala over Python?

1. Static typing system catches most of your typos at compile-time
2. Superior performance due to JVM byte-code (yes, there's PyPy, but ...)
3. Large collection of third-party libs / Java interop (although there are countless Python bindings)

Why would I choose Scala over Haskell?

1. Haskell's learning curve is steep (but worth it)
2. Sometimes Haskell's purity-by-default is a PITA (io monads, no "real" imperative code)
3. Lack of third party libraries

Now you are thinking, that's all he's got in his little arsenal? Nah!

• Groovy:  "I can honestly say if someone had shown me the Programming Scala book by Martin Odersky, [...] back in 2003 I'd probably have never created Groovy." [James Strachan creator of Groovy]
• Clojure: Lisp, urgh. I never liked it (yes, a very scientific statement)
• F#: We don't want .net / mono ... do we? Although the language is nice ...
• C++: boost gives you unlimited freedom ... and unmatched error complexity, compile times (even with pre-compiled headers), ...

Open for discussion!

To back this up with something concrete, let me give you an (incomplete) overview of some very basic syntactic features of Scala:

• containers, tuples, ...
• companions
• type (alias) definitions
• implicit type conversions
• operator overloading
• lambda: higher-order functions, currying, binding
• duck typing ("When I see a bird that walks like a duck...")
• multiple inheritance with order (mixin traits to avoid diamond issue)
• pattern matching (a la haskell)

Here we go:

import scala.collection.mutable.HashMap

// io
println("Hello World!")      
    
// containers
var l1 = List(1,2,3) ++ List(4,5)
var l2 = (1 to 5 toList)
var l3 = List(1,2,3).filter(_ > 2)
var l4 = 1 :: 2 :: 3 :: Nil    
    
// tuples
val pair = (99, "balloons")
println(pair._1)
println(pair._2)
    
// traversal
val s = for ((k, v) <- HashMap(1 -> "a", 2 -> "b")) yield (k + v)
println(s)    
    
// factory companion
class Pojo(greeting: String, count: Int)
object Pojo { def apply(greeting: String) = new Pojo(greeting, 1) }
var p = Pojo("ops")    
    
// type (alias) definition
type T = HashMap[String, Int]
val m = new T    

// implicit conversion
class RichString(str: String) {
   def shrink = str.toCharArray.foldLeft("") { (t, c) =>
     t + (if (c.isUpperCase) c.toString else "")
   }
}
implicit def str2RichString(str: String) = new RichString(str)
println("HyperText Transfer Protocol".shrink) // HTTP
    
// operator overloading
val treasure = HashMap(1 -> "Go to island.")
treasure += 2 -> "Find big X on ground."    
    
// lambda
l1.foreach(i => println(i))
l1.foreach(println(_))    
    
// higher order functions
// def foldLeft[B](z: B)(f: (B, A) => B): B
var str = (1 to 3 toList).foldLeft("X")((str,num) => str+num)
println(str) // X123    
    
// currying
@inline def plus(a:Int) = (b:Int) => a+b
var 3 = plus(1)(2)
    
@inline def plus2(a:Int, b:Int) = a+b
val plus2Curried = Function.curried(plus2 _)
var 3 = plus2Curried(1)(2)    
    
// binding
val plus5 = plus(5)(_)
var 6 = plus5(1)
    
// multiple inheritance with order
trait Friendly { def greet() = "Hi" }
trait Dog extends Friendly { override def greet() = "Woof" }
trait Cat extends Friendly { override def greet() = "Meow" }
val dogCat = new Dog with Cat
println(dogCat.greet()) // "Meow"
    
// duck typing (upper type bound on "greet()")
def f[G <: { def greet() : String }](g:G) = println(g.greet())
f(dogCat)    
    
// pattern matching (conditional down-cast)
abstract class A
case class B(i: Int) extends A
case class C(s: String) extends A
 
val c = new C("C") match {
 case b : B => b.i
 case c : C => c.s
}
println(c) 

Builder Pattern revisited ... in Scala

So, you are a Senior Developer with solid experience in java, c#, or c++? You know the famous GoF Builder pattern by heart, applying it is a matter of seconds and there's nothing more to learn?

In this case Rafael's article "Type-safe Builder Pattern in Scala" will probably shake your world.

To put it in simple terms, let's say we have a constructor signature for type Foo:

case class Foo(val a:A, val b:Option[B])

And the corresponding builder which emulates a Java-ish implementation:

class FooBuilder  {
  var a:Option[A] = None
  var b:Option[B] = None

  def withA(a:A) = {this.a = Some(a); this}
  def withB(b:B) = {this.b = Some(b); this}

  def build() = new Foo(a.get, b)
}

This is self-explanatory. A careful reader might wonder what happens when the mandatory variable 'a' remains unbound?

scala> new FooBuilder() withB(B) build
java.util.NoSuchElementException: None.get

Simple answer, for non-optional parameters (here: a:Option[A]) the Option[A].get method throws an exception at run-time if a is unassigned (or more precisely: is assigned to an instance of None).
Okay, but where's the magic, you say? Good, imagine we could statically ensure that non-optional parameters are bound at compile-time. Got it? Then let's take a shortcut - we transform the builder code into a functional-inspired form and use phantom types as a constraint for instantiation:

object BuilderPattern {
  case class A
  case class B
  case class Foo(val a:A, val b:Option[B])

  abstract class TRUE
  abstract class FALSE

  class FooBuilder[HasA, HasB](val a:Option[A], val b:Option[B]) {
     def withA(a:A) = new FooBuilder[TRUE, HasB](Some(a),b)
     def withB(b:B) = new FooBuilder[HasA, TRUE](a,Some(b))
  }

  implicit def enableBuild(builder:FooBuilder[TRUE,FALSE]) = new { 
     def build() = new Foo(builder.a.get, builder.b) }

  def builder = new FooBuilder[FALSE,FALSE](None, None)
}

Let's give it a try:

scala> import BuilderPattern._
scala> builder withA(A()) build
scala> builder withB(B()) build
:12: error: value build is not a member of BuilderPattern.FooBuilder[BuilderPattern.FALSE,BuilderPattern.TRUE]

I hope your brain screams "SWEET!". Didn't get it? Then enjoy Rafael's lengthy version "Type-safe Builder Pattern in Scala".

Color your Code?

Took me a while to figure out that blogger.com does not come with syntax highlighting - duh! Obviously, there's a way to beautify your code:

trait Friendly { def greet() = ":)" }
trait Dog extends Friendly { override def greet() = "Woof" }
trait Cat extends Friendly { override def greet() = "Meow" }
def f[G <: { def greet() : String }](g:G) = println(g.greet())
f(new Dog with Cat)

The twist is to enhance your blog template by a client-side javascript library:

1. Reference Google's prettify library:
   

   <link href="http://google-code-prettify.googlecode.com/svn/trunk/src/prettify.css" type="text/css" rel="stylesheet" />
   <script type="text/javascript" src="http://google-code-prettify.googlecode.com/svn/trunk/src/prettify.js"></script>
   

2. Initialize it:
   

   ...
   <body onload='prettyPrint()'>
   ...
   

3. Escape your code with a regular <pre> tag:
   

   <pre class="prettyprint">
   ... # Put your code here
   </pre>
   

One last thing, if escaping html code (&lt; &gt;) drives you crazy, this might come handy:

$ echo '<html>' | sed s/\</\\\<\;/g | sed s/\>/\\\>\;/g