New job

So this is it, my last week at Viaboxx.

I’ll really miss them, more than any other company I’ve worked for. I had a great time, a great team and learned a whole lot.

If you’re looking for a fine company to work for in the Cologne/Bonn area: they’re hiring to replace me. You can drop me a line if you have any questions.

But all good things must come to an end, and I got an interesting offer from Eyeo, where I’ll mostly be working on Adblock Plus, its various ports and the infrastructure supporting it.

I don’t hate ads – I’m earning some money with ads myself. What I don’t like are overly obtrusive ads, so I’m finding Eyeo’s new acceptable ads concept very promising. I’m excited to work on something that helps millions of people experience a better web and enables website owners to avoid ad-blocking by using non-obtrusive ads at the same time.

Another exciting aspect is that I’ll be working from home full-time, something I’ve been longing to do for a while now. Viaboxx was awesome and allowed me to work from home one day per week, but more than that wouldn’t have worked out. Their core product is software for large, expensive machines – not something you can reasonably work with from home. Anyway, I’m very happy to spend more time with my lovely kids soon – they’ll only grow up this once.

Eclipse Color Theme 0.12

We’ve just released version 0.12 of the Eclipse Color Theme plugin. It’s been a year since the last release, so there are a couple of changes. Most notably, the following new editors are now supported:

  • Erlang (ErlIDE)
  • haXe (eclihx)
  • Clojure (Counterclockwise)
  • Go (GoClipse)

Check out the full change log to see what else changed.

Roger and I haven’t done much work on the plugin or the site in the past year, but we’re both eager to move it forward and are working on some interesting ideas right now, stay tuned.

On a related note, since people ask for this a lot: If you’re using Eclipse Juno and have been desperate to get a nice dark UI theme to go along with our dark editor themes, check out Roger’s Dark Juno.

What’s with all these parentheses?

I’m fairly certain that every programmer will, at some point in his career, say something along the lines of:

I don’t know, what’s with all these parentheses?

And he will be talking about Lisp. I certainly did a few years ago. It’s quite strange when you’re used to other languages, why would anyone want all these parentheses?

Why have something like this:

(filter (lambda (price)
          (< price 10))

When you can have it like this: do |price|
    price < 10

Indeed, there is not much syntactical sugar, as Rubyists say, in most Lisp dialects. If you think about it, there isn’t really much syntax at all: You’re really just writing a syntax tree in Lisp’s list literals. Considering that, the syntax is actually pretty clear. Let’s look at what this might look like written in JavaScript’s array literals:

[filter, [lambda, [price],
           [lt, price, 10]],

Not that much different, eh? That’s what Lisp is. And that’s why Lisp macros are so powerful: You can easily transform these data structures into something else, changing your code. I can’t think of a single other language that lets me do that. Another benefit is that when looking at Lisp code, you normally don’t have to wonder about things like operator precedence and strange literals you didn’t know, the syntax is unambiguous.

So if the parentheses are what’s separating you and Lisp, give it a chance. No one I know who gave Lisp the chance it deserves ever regretted it, whether or not it became their main language.

The Mustache way

Mustache is my favourite template engine.

It’s the only one I know that tries to keep logic out. There is a wee bit of logic, but just the bits without which it wouldn’t make sense to use it.

The traditional approach to templating looks like this:

  1. Have a model of the data relevant for a view
  2. Insert bits of that model into the view

The problem with this is that the second step is quite complicated. In most cases, you’re not rendering the model 1:1 onto the view, you convert data types, format dates, bring some bits of data together and separate others.

There are many powerful template engines that are very good at that. Some allow you to insert code, others have their own expression language. Some have mechanisms for extending the template language so you can add all the features you need.

When people used to that see Mustache, they usually want to add features, or they simply dismiss it as not being powerful enough.

Here’s the thing: This is code. Why do it in the template at all costs? Why not do this in actual code? Why not use your preferred language?

This is my approach to templating with Mustache:

  1. Have a model of the data relevant for a view
  2. Prepare it for the template (I usually copy and adjust the model)
  3. Render the prepared model 1:1 on the view
With this, you have the view logic in your code and your templates stay clean. How it ought to be, if you ask me.

JVM language popularity

I was lately interested in how popular the major JVM languages are in comparison, so I did some quick tests.

I compared Java, Scala, Groovy, Clojure and JRuby. I included both JRuby and Ruby in my queries, because JRuby isn’t really a distinct language.

The tests


Quite obvious, eh? I searched for “x language” where x is one of the languages and wrote down the number of results. I’m fully aware that this isn’t a very good test.

Ruby 97,400,000
Java 46,200,000
Scala 29,200,000
Groovy 17,700,000
Clojure 3,460,000
JRuby 1,770,000

I thought Java would come out on top, surprised me.


The good old programming language popularity index.

Java #1
Ruby #13
Groovy #31
Clojure >#50
Scala >#50
JRuby Not listed

I thought Scala would do way better than Groovy.


The most popular project hosting service.

Ruby #2
Java #5
Scala #18
Clojure #21
Groovy #22
JRuby Not listed

Scala, Clojure and Groovy are pretty close here.


Probably the most important Q/A site for programmers.

Java 218,432
Ruby 41,435
Scala 8,104
Groovy 3,772
Clojure 2,762
JRuby 1,051

Java and Ruby are quite popular, the others less so.


Unsurprisingly, Java is by far the most popular language. So if alternative JVM languages are the future, the future doesn’t seem to be quite here yet.

The second place goes to Ruby. Ruby, not JRuby – it’s hard to figure out what percentage of the Ruby community is using JRuby.

Scala, Groovy and Clojure are similar in popularity. Sometimes Scala is on top, sometimes Groovy. Nonetheless, I’m actually most impressed by Clojure. It did pretty well, considering that it’s radically different to Java/Groovy/Scala and only 5 years old. (Groovy and Scala are both 9 years old, Java and Ruby both 18.)

Bottom line: When considering which JVM language (other than Java) to use, popularity can’t really be a factor. That’s good.

Clostache 1.0 – now spec compliant

I normally merely tweet about new releases of my pet projects, but Clostache, a Mustache parser for Clojure, is hitting 1.0, which I think warrants a blog post.

I changed quite a bit, in order to achieve compliance with the Mustache spec. The spec wasn’t around when I first wrote Clostache, and I learned about it’s existence just a few weeks ago from someone ranting on Twitter. Having a non-compliant Mustache parser didn’t feel right, so I changed that.

I had to fix a few bugs (mostly whitespace issues that don’t matter when producing HTML) and implement two features I never needed and thus ignored: partials and set delimiters. I also had to implement two features I didn’t know about (nor do they seem to be documented anywhere): dotted names and implicit iterators. See the README for examples. I kept the parser core mostly intact because it’s stable and mature by now, but some of the features would have been easier to implement with imperative parsing logic. It would also be faster, but Clostache has no performance issues, so that reason isn’t good enough either.

Anyway, if you’re using Clostache, please update to 1.0 and let me know if you run into any problems.

Make Emacs evaluate Clojure in 5 minutes

Emacs is my editor of choice for Clojure development (as for all Lisps), and according to the State of Clojure 2011 survey, that’s true for 68% of all Clojure developers.

Yet from what I’ve seen, some Emacs using Clojure developers don’t evaluate their code in Emacs, and the survey shows that 20% of all Clojure developers use the command-line REPL. Read on to figure out how to change that in just about 5 minutes.

“But why would I want to evaluate Clojure in Emacs?”, you might ask. Here’s why I can’t live without it: When I was new to Lisp, I missed the step-by-step debugger I knew from imperative languages. That changed when I started to write Emacs Lisp and got used to evaluating code in the editor. In functional programming, you avoid mutable state, especially global mutable state, so you can normally locate and fix bugs by evaluating suspicious parts of your program in isolation. Proper runtime inspection is still useful and necessary in some cases, and there are tools for that, but evaluating code in Emacs has been sufficient for me so far.

While most Clojurians seem to swear by SLIME to achieve this, I’m not particularly comfortable with it. It’s big, annoying to set up and there has been no release or tag to date, you have to get the latest code from CVS. Nothing you’re likely to get up and running in 5 minutes. If you’ve got some free time, do try SLIME, you might like it. If you, like me, would rather avoid it: Read on to learn how to set up inferior-lisp-mode (where inferior-lisp stands for Lisps other than Emacs Lisp) for Clojure.

Setting up inferior-lisp-mode

All you really need to do is set the variable inferior-lisp-program to the command that invokes the Clojure REPL.


If you use Leiningen for all projects, add the following to your init.el:

(add-hook 'clojure-mode-hook
          (lambda ()
            (setq inferior-lisp-program "lein repl")))


For Maven users, it takes a bit more effort. The inferior-lisp command will execute the configured command in the same directory as the file you are currently visiting, which is probably not the directory where your Maven pom.xml resides. Maven, however, wants you to execute most commands in that directory. To circumvent this, I wrote a wrapper script that locates the pom.xml before invoking Maven. Armed with that, you can set up inferior-lisp-program as follows:

(add-hook 'clojure-mode-hook
          (lambda ()
            (setq inferior-lisp-program "smvn clojure:repl")))

Both Leiningen and Maven

When you are working with both Leiningen and Maven projects (like I do), things get a little more complicated. I thought about writing an Emacs Lisp function that automatically discovers whether a project is a Leiningen or a Maven project and invokes the respective command, but decided to shave that yak later. Instead, I use Emacs’ dir local variables to set the inferior-lisp-program for each project. For a Leiningen project, just add a .dir-locals.el file with the following content to your project’s root directory:

((clojure-mode . ((inferior-lisp-program . "lein repl"))))

For Maven projects, do the same with the following content:

((clojure-mode . ((inferior-lisp-program . "smvn clojure:repl"))))

And to eliminate the annoying warning that pops up whenever the dir locals are set, add the following to your init.el:

(add-hook 'clojure-mode-hook
          (lambda ()
            (setq safe-local-variable-values
                  '((inferior-lisp-program . "lein repl")
                    (inferior-lisp-program . "smvn clojure:repl")))))

Using inferior-lisp-mode

Now that you’ve set up inferior-lisp-mode, you can just open a Clojure file and type: M-x inferior-lisp, which starts a Clojure REPL in the current Emacs window. You can then use the REPL conveniently from within Emacs, and evaluate s-expressions in your code by placing the cursor on closing parantheses and pressing C-x C-e.

That’s it, have fun 🙂