Category Archives: programming

Lisp tutorial

In a good cause…

I must admit I haven’t gotten around to reading it yet, but Practical Common Lisp looks really quite good, and is available online for free. Definitely a lisp tutorial worth reading.

This entry was posted in programming and tagged on by .

How to create sealed classes in Java

As far as I can tell, no one else seems to have spotted this trick, so I thought I’d share my latest corruption of the Java language:


public class Sealed
{
private Sealed() { }

public final static class Foo extends Sealed {
public Foo() { }
}
public final static class Bar extends Sealed { }
}

What does this code do? It creates a class Sealed which is *not* final, but only has a finite number of subclasses which you determine at compile time (you can make those subclasses themselves extensible if you want, although I declared them final above). No one else can subclass it because they’re not able to call the super constructor as it’s not visible outside of this class.

This entry was posted in programming and tagged on by .

Tail call optimisation in Scala

This is just a quick note. I couldn’t seem to find any good information on what sorts of tail call optimisations were performed by Scala so I ran a few quick tests. Disappointingly, the answer seems to be not much. A simple tail recursion was turned into a loop, but the following code got no love:


object Main extends Application{
def foo (x : Int){
if (x == Integer.MAX_VALUE) Console.println("Hello world!");
else bar(x + 1);
}

def bar (x : Int){
if (x == Integer.MAX_VALUE) Console.println("Hello world!");
else foo(x + 1);
}
foo(0);
}

This isn’t really surprising, although it’s a bit sad. Eliminating general tail calls seems to be quite hard without just converting everything into CPS and making everything work that way (at least so I’m lead to believe. My expertise on the subject is basically nonexistent), which is probably not a great idea on the JVM.

Curiously, if you enabled optimisations with -XO, foo was inlined into bar but the resulting tail recursion was not eliminated. That’s probably a bug.

Update: It’s been pointed out to me that I’ve gotten myself completely confused on the relationship between continuations and tail call elimination. Please ignore any mumbling to that effect. :-) The issue is apparently that TCO is easy when compiling to assembly and hard when compiling to something like JVM byte code which is higher level and doesn’t already support it.

This entry was posted in programming and tagged , on by .

Good APIs

At least in the Java world[1], good APIs are very rare. The vast majority of the APIs I’ve used in Java are at best mediocre, and I’ve run into some real stinkers (No fingerpointing here, but a lot of them are even in the standard library!).

Part of this is the fault of the language. Java code… tends to be ugly. It’s not a language which lends itself to really flexible syntax, and so you have to work really hard to produce powerful abstractions which are actually nice to use.

The only APIs I’ve encountered so far which have really made me sit up and go “Wow, that’s well designed” are Google Guice and Joda time. They have well thought out class hierarchies, good object oriented style[2], sensible use of fluent interfaces / method chaining and just generally well thought out interfaces and names.

They’re not perfect by any means, but they show promise that it really is possible to write good APIs for Java.

Anyone else know of other similarly well designed libraries?

[1] And, unfortunately, I lack much in the way of non-trivially large development in other languages. The Parsec API is nice, ‘though it gives me a headache sometimes. Haskell libraries in general look rather pretty, though I suspect that’s more a function of the language than the API design. I’m not really experienced enough in it to judge good API design.

[2] I’m not an OO fanatic. It has advantages and disadvantages, and sometimes you just want to use a different approach (I rather like FP for example). But one thing I’ve observed is that if you do it right, OO can have the effect of producing some astonishingly readable code. I don’t know either well/at all really, but this style of design seems much more common in Ruby, smalltalk, etc.

This entry was posted in programming and tagged , , , on by .

Looking through other peoples’ code is fun

I’m playing with the google guice code at the moment. It’s very interesting, and contains some quite neat tricks (although is rather short on documentation so I’m getting very confused). But that’s not what this post is about. I just wanted to share the following fun snippet. :-)


// TODO(kevinb): gee, ya think we might want to remove this?
private static boolean allowNullsBadBadBad() {
return "I'm a bad hack".equals(
System.getProperty("guice.allow.nulls.bad.bad.bad"));
}

This entry was posted in programming and tagged on by .