Archive for September, 2007

What? No clicks?

September 28th, 2007 No comments

I stumbled upon this really interesting site. It implements a new kind of site navigation that is really cool. It’s actually a research project that tried to create a user interface which requires no clicking.

For me it was a mind-tumbling experience, but I quickly got a hang of it. I even liked it to some extent. I had two major problems with it though: First there were a lot of movement going on. A little too much for my old fashioned taste.

The second and more important problem was that the mouse pointer got in my way while reading. In a normal click-based interface I could just drag it out of sight, but here I needed to have it hovering over the item to keep it enlarged. This was annoying, but they should be able to reduce the problem with more whitespace around the enlarged items.

I haven’t tried the interface enough to come with a deep analysis, but my guess is that it won’t replace the traditional click-based navigation. At least not in the near future.

Categories: GUI, research, software development Tags:

Tools of The Effective Developer: Customer View

September 27th, 2007 4 comments

A post on Jeff Atwood’s excellent blog inspired me to write up the fourth element of my Tools of The Effective Developer series. This time I’ll handle the habit of taking the customer’s view.

Jeff states that the primary responsibility of a software developer is not to write code, it’s to solve the customer’s problem. (Otherwise, using my definitions, he is a programmer and not a developer.) This calls for the habit of taking the customer’s view in every step of the development cycle. Make it a habit to ask yourself the question: In what way does this matter to the customer? This simple question is like a good friend of mine. It’s stopping me from making costly mistakes and helps me focus on what’s important. Like getting the right things done, and not just things done right.

By taking the Customer View you help preventing technology-based decisions. I once read a report that was going to be the basic input for a decision to replace a legacy system. The author’s main reason was to have an object oriented system. Why would this matter to the customer? While there are perfectly good reasons to have an object oriented system, none of them could be found in the report. Nor could any of the really valid reasons, like usability and functionality issues.

The report-writers obviously didn’t take the customer’s point of view, but the decision was made none the less. So what happened you ask? Still not finished, many times the initial budget spent.

Being able to look upon your work from the customer’s point of view takes empathy, the finest characteristics of them all. Exercising it regularly is something all of us should do. That’s why I like the habit of taking the Customer View.

Here are the other posts in my Tools of The Effective Developer series:

  1. Tools of The Effective Developer: Personal Logs
  2. Tools of The Effective Developer: Personal Planning
  3. Tools of The Effective Developer: Programming by Intention
Categories: habits, software development, tools Tags:

Tools of The Effective Developer: Programming By Intention

September 25th, 2007 6 comments

This is the third post in my Tools of The Effective Developer series. The other two discussed the habit of keeping personal logs, and the habit of daily planning. Now the time has come to the habit of programming by intention.

Please note that I’m not speaking of intentional programming, which by the way introduces some interesting concepts. Instead I refer to the simple kind that only requires your brain and the programming language of your choice.

So what is programming by intention? Well, I like to describe it this way: if you are to implement a new set of functionality, and you don’t start with the implementation, nor the programming interface, but you start writing the code that is going to use it – then you are programming by intention.

Why is this way better? The short answer is: Because we are lazy. The long answer is: We humans usually seek the simplest solution. Start with the utilizing code and you should find yourself pushing complex code and decisions right where it should be: behind the programming interface, nicely encapsulated. We also focus more on the task at hand, which decreases the risk of committing the sin of premature generalization.

Programming by Intention is probably the easiest effective developer habit to acquire. It can be done at all levels of abstraction and there is no overhead cost. Therefor it’s my favorite habit.

Categories: habits, programming, tools Tags:

Constant Learning

September 20th, 2007 No comments

One of my favorite quotes comes from Ron Jeffries on his blog Hot Needle of Inquiry:

“the river is moving, and if we don’t keep rowing, we are going to drift back downstream”

The quote reminds me of the importance of self-improvement. If we stop learning we are nothing but dead material in the stream of life. Ron seems to have stopped updating his blog, which is sad because it was one of my favorites.

Today I read a really interesting post on Debasish Ghosh’s blog. He shows how you can get object-orientation in a functional language using closures. I knew it could be done, but I hadn’t seen it in code before. Neat, but I received the real learning opportunity from one of the comments, in which Gabriel C. states “LOVED the Koan”.

I didn’t have a clue of what a Koan was, but Wikipedia came to my rescue:

“A koan is a story, dialog, question, or statement in the history and lore of Chan (Zen) Buddhism, generally containing aspects that are inaccessible to rational understanding, yet that may be accessible to Intuition.”

Thank you Debasish and Gabriel, you made me exercise rowing today too.

Categories: learning, programming Tags:

The Google Example

September 19th, 2007 No comments

I just finished reading The Google Story, by David A. Vise. I can’t say it’s a great book. Some parts are terribly boring, stuffed with uninteresting facts and examples. But there were chapters that made me long for my next visit to the toilet. Here is the list of things that caught my attention:

  1. Larry and Sergey built their product first and raised money later. It’s so much easier to sell your idea if you can back it up with a real and functioning implementation.
  2. The two founders didn’t start with their eyes on the money. In fact, they had no idea how to monetize their search engine in the beginning. Instead they were focusing on providing the best search experience they could. The focus on usefulness is what laid the foundation to their success. People noticed, trust was built.
  3. A Google employee (a Googler) are free to spend one fifth of his time at work on a private project of his own pick. One day each week, free to spend on anything that interest you. You’re not just free to do it; you are supposed to do it. It’s your job.
    To me that sounds just like employee heaven, but the employee is not the only winner. Some of these private projects grow and end up in valuable products for the company. Just look at the wide range of services that Google provides, many of them started out as private projects.
  4. Google takes care of it’s employees. Free healthy food and day care for my children would make my life so much easier. That’s another win – win deal between you and your company.

If I ever get to build my own start-up, I will use Google as my template.


Categories: books, learning, reading Tags:

Quit Debugging!

September 17th, 2007 21 comments

I have a confession to make: I used to be addicted to debugging. Yes, it’s true. When I got hooked – damn you Delphi – I wasn’t able to see the dark side, the demonic side of the debugger. It lured me into the path of quick fixes. Heed my warning: debuggers are bad!

Fortunately I’m one of the lucky few who have been able to recover from this particularly addictive behavior. I’ve been clean – thank you jUnit – for almost 5 years now. And you can do it too, you can let go of the safety zone that these integrated debuggers provide, and break free just like I did.

The first thing to do is to realize that there is a better alternative: test-driven development. To get rid of a bug, the right thing to do is not to fire up your debugger, but to write a unit-test to reveal it. If necessary, keep writing tests and go deeper and deeper into your code. Eventually the tests will tell you what is wrong, and they’ll even point out a solution for you.

I know that using a debugger may seem like a faster way to find and extinguish a bug, but that is just an illusion. Here are the reasons:

  1. TDD improves the design. Being forced to think testability tends to divide your code into small manageable pieces. This will make your code a bad breeding ground for bugs.
  2. Tests remain useful for a long time. They become an addition to your testing harness, which helps protecting your code against future infestations. The work spent in a debugging session can never be reused.
  3. Unit-testing saves time, a lot! While this isn’t immediately obvious, the long term effects are huge. Think of it: all those debugging sessions can be run automatically at your command, whenever you want, how often you want, and in just a matter of seconds. All you have to do to achieve this is to let go of the debugger, and write relevant tests.
  4. Unit-testing gives you courage. There’s nothing like a good harness to make you feel invincible. I still remember the first time I felt the real power of unit-testing. I was working on a huge legacy application and had developed a new set of functionalities, using TDD for the very first time. Several months later I realized I had to do a major rewrite. The rewrite was risky business and took me a couple of days to complete. When finished, I ran the unit-tests which all came out green! I could be confident the program worked just as before the rewrite. And the best part: I drew the conclusion out of just five seconds of testing. Boy, I still get the goose bumps.


Of course debuggers are useful tools. In certain situations they are even invaluable. For someone who’s new to the software they provide a great way of getting to know it. The problem is that a debugger makes you lazy. So be sure to get rid of it as soon as you identify a testing strategy.


Donkey Patching

September 13th, 2007 4 comments

According to this slide show, the team behind D is thinking of incorporating an interesting addition to the language: The interchangability of and foo(a, b).

This makes some interesting uses available. For instance, one could do something that looks a bit like monkey patching, adding functionality to library classes.

real round_to(real n, uint d) {
  real b = 10;
  real k = pow(b, d);
  return round(n*k)/k;

With the proposed change I could use the round_to function like this:

real a = 9.4334566;
real b = a.round_to(2); // => 9.43

I would also be able to do this:

int next(int a) {
  return a + 1;

int b =; // => 4

And while we’re at it:

void times(int n, void delegate() dg) {
  while(n\-\- > 0) {

  writefln("Look at me. I'm Ruby!");

Of course this isn’t really monkey patching. The functions doesn’t actually become a part of the class, and thus cannot use polymorphism or access private members. In all respect this is just syntactic sugar, but I like it. It gives you the illusion of having a dynamic language.

I haven’t seen this particular feature in any other language before. Does it exist elsewhere? Does it have a name? If not, I think Donkey Patching would be a suitable one.

Cheers! 🙂

Categories: D Programming Language, programming Tags:

Should D have real closures?

September 13th, 2007 No comments

It has been a vivid debate following my D doesn’t have real closures post. For most parts it has been a constructive discussion, but what I wanted to see was real examples that would convince me that real closures (those that carry the environment with them) were actually useful for a language that provides other means of object oriented programming.

One reason for my skepticism was an interview with Ruby’s creator Yukihiro Matsumoto, made by Bill Venners. There Mr Matsumoto says this about having the context captured: “it’s not that useful in the daily lives of programmers”. Here is the statement in context:

Bill Venners: OK, but what is the benefit of having the context? The distinction that makes Ruby’s closure a real closure is that it captures the context, the local variables and so on. What benefit do I get from having the context in addition to the code that I don’t get by just being able to pass a chunk of code around as an object?

Yukihiro Matsumoto: Actually, to tell the truth, the first reason is to respect the history of Lisp. Lisp provided real closures, and I wanted to follow that.

Bill Venners: One difference I can see is that data is actually shared between the closure objects and the method. I imagine I could always pass any needed context data into a regular, non-closure, block as parameters, but then the block would just have a copy of the context, not the real thing. It’s not sharing the context. Sharing is what’s going on in a closure that’s different from a plain old function object.

Yukihiro Matsumoto: Yes, and that sharing allows you to do some interesting code demos, but I think it’s not that useful in the daily lives of programmers. It doesn’t matter that much. The plain copy, like it’s done in Java’s inner classes for example, works in most cases. But in Ruby closures, I wanted to respect the Lisp culture.

Today I read a blog post from Julio César who’s arguing for incorporating real closures in D. He’s providing real examples and his case feels strong. Also, he points to an alternative way of implementing it that doesn’t look too complicated.

Categories: D Programming Language, programming Tags:

The Firefox Domination

September 12th, 2007 10 comments

Today, for the first time since I let FeedBurner collect my visitor stats, I examined the numbers more closely. I was quite surprised to find that Firefox so totally dominated the web browser statistics. Almost 7 out of 10 visitors were using Firefox 2.0.

Browser stats aug -07,

The reason I got so surprised was that the figure was something like 10% the last time I heard. (Get off my back will you! I’m not a web developer 😉 ). I realized that those numbers must have been several years old, so I did a little googling and came up with some fresh statistics (which by the way showed that Firefox was at 10% in 2004):

2007 IE7 IE6 IE5 Fx Moz S O
July 20.1% 36.9% 1.5% 34.5% 1.4% 1.5% 1.9%

It seems like Internet Explorer has 58.5% of the market, but only 11% among my visitors. From these numbers and the fact that you (my dear reader) is most likely a developer, I draw the following conclusions:

  1. Firefox rocks among developers, and
  2. Internet Explorer is a bleeding product

It is also interesting to see the relatively big differences in Safari (4% vs 1.5%), Opera (3% vs 1.9%) and Other browsers (9% vs 2.2%). I don’t know what to make of it though.

FeedBurner is awesome by the way. No wonder Google bought them.

Categories: stats, tools Tags:

D doesn’t have real closures

September 11th, 2007 12 comments

Note: This article was written before D got full closure support.

Delegates are something that gives me mixed feelings. While I used to embrace them in Delphi and Object Pascal, I now find them difficult to get used to in C#. I guess that is because they introduce a little of the functional programming paradigm into an otherwise object oriented environment.

Don’t get me wrong, I do find delegates powerful and I use them whenever I see fit. It’s just that they bug me, like a badly-pitched note in an otherwise perfect chord. In that respect I am much more fond of the inner classes of Java.

The D Programming Language, my favorite pet at the moment, has support for both delegates and inner classes, thus providing the best of both worlds. And since D is a multi paradigm language with support for functional programming, its delegates are justified.

The semantics of D delegates are somewhat different from that of C#. For instance, C# delegates may bind to both static and non-static methods, while D may bind to non-static methods only. But on the other hand, D delegates may also bind to inner functions, which makes them look a lot like closures.

bool retry(int times, bool delegate() dg)
  int tries = 0;
  while (tries++ < times) {
      return true;
  return false;

// Example usage
retry(3, {
  writefln("Password: ");
  char[] buf = readln();
  return (buf == "secretn");

In order to be a real closure a delegate is required to keep variables that are bound from the surrounding environment alive, even if the program has left their scope. For example, consider the following program.

int delegate() countdown(int from)
  int current = from;
  int countdown_helper() {
    return current\-\-;

  return &countdown_helper;

int delegate() dg = countdown(10);
dg(); // should return 10;
dg(); // should return 9;
dg(); // should return 8;

The countdown function returns a delegate that refers to the inner function countdown_helper. Counter_helper binds the variable current from it’s parent by returning its value and decreasing it by one.

So, if D’s delegates were real closures the first invocation of the delegate in the above example should return 10, the second 9, followed by 8, 7, and so on. But in reality they produce bogus values like 4202601 or 4202588. The reason is this: D doesn’t implement real closures. The variable current is invalid because the program is no longer executing the countdown function when countdown_helper is invoked via the delegate.

So D doesn’t have real closures, is that a big deal? No! In my opinion real closures are not important for languages that are not pure functional. The creators of D shouldn’t waste their resources on this feature since it brings little value but lots of implementation complexity. The energy is better spent on features like multicast delegates. Those would bring value in the form of convenience, and I hope future versions of D will incorporate them.

Complete versions of the code samples in this post can be found here and here.