Awesomely awesome in its awesomeness

Sometimes some things are just so good that you have to shout about the fact that it’s good even though it does no-one any good.

Emacs is such a thing. It occurred to me today that I’d dearly love to write more for this blog, and one way that I might be able to do that would be if I could edit my posts in Emacs. One web-search later I’m reading about how trivial it is using weblogger and xml-rpc.

60 seconds after that I’m up and running, and writing this post. I didn’t even have to restart Emacs. That’s how awesome it is.

And to think that I used to berate people who used Emacs because I only used vi.

So now I’m praying to the saviour for redemption.

Mersenne Twister in Clojure

The Mersenne Twiser is a random number generator that has a lot of applications, particularly in finance. After discovering that there was no Clojure implementation at Wikipedia I decided to give it a try as my first attempt at something useful in Clojure. As it turns out it’s problably not a good candidate to be implemented in a functional language because the whole thing requires modifying a mutable array for every call to (genrand).

I’m not very excited by the solution because it doesn’t seem very lispy. It much more resembles the reference implementation, and gives the same results as it for all the tests I tried.

I’m sure it could be better though.

If it’s of any use to anyone you can find it here.

REPL to the rescue!

Yesterday I watched Dan Weinreb talking about ITA, Lisp, and well, really, really complex stuff 😉

The kind-of conclusion that he drew on the future of Lisp is that Clojure is the next Common Lisp. I’ve been dodging Clojure for about a year now. I bought the book from The Pragmatic Programmers when the book was in beta and eagerly followed the examples and decided it had promise. But, I figured that if I needed to really learn it (and by that I mean use it, not just talk about using it) it would have to come to me. It would do this, I reasoned, by being hard-to-ignore.

Well there seem to be more than enough smart-folks on-board now (like: Eric Normand, Bill Clementson to name only two) so I guess I better not miss the party. Not because I’m smart but because if I don’t make too much noise I can blend in and no one will notice I’m there.

So I came to the conclusion that I should try and use it for ad-hoc things that might cross-my-dome and are hard(er) to solve in non-functional languages.

For instance, this very afternoon I wanted to know how many possible hand distributions by suit there are in the card game Bridge. So four possible distributions might be:

  • All 13 hearts
  • 12 hearts, one diamond
  • 11 hearts, one diamond, one club
  • 10 hearts, one diamond, one club, one spade

The question is how many total distributions are possible?

I banged my head on the table-hard trying to figure out the answer to this. At first it seemed like a simple counting problem, but if it is I’m too simple to see it. Then I wondered if it could be an additive patitioning problem, but ordering is important so I don’t think it is. It didn’t feel NP complete. I know one thing though, at this late hour it might as well be.

1:57 bridge=> (count (for [spades (range 0 14) 
                                hearts (range 0 14) 
                                diamonds (range 0 14) 
                                clubs (range 0 14) 
                                :when (= 13 (+ spades hearts diamonds clubs))] 
                                [spades hearts diamonds clubs]))

Functional programming rocks.

Virtually pure, in a way only C++ can be


C++ was a boon for technical interviewers. There was a time when C++ was about the only viable object-oriented programming language in a business environment. In those days you pretty much had to know C/C++ to be an OO programmer. So you could test someone’s depth of C++ knowledge (and thus their overall suitability) by just asking about all the messed up edge cases that make C++ really tricky to use.

Today we’ll be observing a hypothetical candidate Phil. Phil has been a C++ programmer for 5 years (2 of which were at University) and has rated himself 9/10 on the C++ confidence scale that I asked him about at the beginning. I’ve been talking to Phil about the various ‘overloaded’ meanings of the keyword virtual in C++. Phil has correctly answered what a virtual method was, but couldn’t get the one about the virtual base class.

Even so, Phil is now into his stride and feeling pretty good about himself, so then I lay it on him:

Phil, is it possible to ever call a pure virtual method?

To which Phil (and about 95% of other candidates) would heartily reply “No”. And of course Phil would be wrong. But that’s ok. First I want Phil to tell me why a pure virtual method can not be called usually. This demonstrates a basic understanding, and then I would try and probe to see if Phil can guess the correct answer as to how a pure virtual method can be called and then the reason it’s possible.

So, what?

If Phil didn’t get the answer straight away then Phil probably won’t get it at all. This is not terribly surprising I suppose, and it’s not a reason to reject Phil. The sad truth about being a C++ programmer is that you really need to know how C++ works, at some level, to be able to use it effectively. I’m here to find out what Phil’s level really is. The more oppurtunities I give him to tell me about those edge cases the better I can assess how good a (C++) programmer he is.


So here is a code sample that under a couple of compilers (VC++ 2005 – Express, and GCC 3.4.4) produces the (un?)desired behaviour. I wanted to try it under some more recent C++ compiler invocations but don’t have them available on the machine that I’m writing this. Anyway, these two compilers seem fairly representative of what a lot of people are currently using.


class A {
	virtual void Reset() = 0;
	void Init()	{
	A()	{

class B : A {
	void Reset() 	{ 
	B() { 

int main(int argc, char** argv)
	B b;

And here is the result:

$ g++ pvirt.cpp 
$ ./a.out
pure virtual method called
      9 [sig] a.out 180 _cygtls::handle_exceptions: Error while dumping state (p
robably corrupted stack)
Segmentation fault (core dumped)

So for those, like Phil, not fully aware of the vaguaries of calling pure virtual methods here is the explanation.

Pure virtual methods can be called from base-class constructors that attempt to indirectly call pure virtual methods.

The reason it's a problem is that C++ constructs objects inside-out, so base classes get built before derived classes. If you then try and call a virtual method on a partially constructed object you will end up calling the base class copy of the virtual method. This is because at the time you are in the base-class constructor the object is of type base-class and not of type derived-class. Calling pure virtual methods from constructors sounds like a really bad idea then, and it is. But there might be legitimate reasons to want to do it, which I'll come to in a minute.

Note that if you try and call the virtual method directly from the constructor, like so:

class A
	virtual void Reset() = 0;
	A()	{

You will probably get a linker error because Reset() is pure and has no implementation, as you'd expect.


So why might you want to do this at all then? Well say you have a class hierarchy of objects that connect to a database for example.

So you dutifully create a Database base class with MySQLDatabase and OracleDatabase derived classes. Now when you disconnect an already established connection you need to reset all the structures as if they had just been created. The object is then ready to be reconnected. So you create a virtual Reset() method in the base class that does this. At the base level though this class should do nothing and you decide that your derived classes must define such a method so you very cleverly make it pure. You could then (but you probably wouldn't) write code like this:

void Database::Disconnect() {

And have the derived class handle the gorey details of the reset. You want the same behaviour when you create a new object so you simply add the Reset() function to the Init() function that you created to deal with the fact that you had to write so many different types of copy constructor in C++! Hey presto pure virtual method called.

Note that if you had decided not to make the method pure and just put in an empty stub then this empty stub would be called instead (and not the derived version). In some ways this is a harder error to track because there is no error just a silent refusal by the object system to call the derived version because it can't, because it doesn't exist yet.

The correct way to deal with this, unsurprisingly, is to not call Reset() from the base-class Init() function but from the derived constructor directly.


Thanks for coming Phil, we'll be in touch.

The First Casualty

I had to read this paragraph from the BBC about the recent Iranian elections twice to make sure I understood it correctly:

The official said the state department contacted Twitter over the weekend to urge it to delay a planned upgrade that could have cut daytime service to Iranians.

So, let me get this straight. The US state department monitors Twitter traffic and is reviewing what Iranians are commenting on the topic of their government. The department wanted to prevent an upgrade to Twitter that might stop the flow of revolutionist propaganda getting back out on the street and starting a larger movement.

Don’t get me wrong, it’s a good call. It just caught me a little by surprise.

I guess I shouldn’t actually be surprised by this but it marks a very definite transition (to me at least) for Twitter. Folks at Twitter have probably been feeling it for years though. The point is though that it’s no longer a fun toy.

Twitter is now, amongst other things, a marketing place for the public, politicians, and companies. But for government departments it’s also a socio-political barometer.

Innocence lost.