www.hans-eric.com

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.

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.

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):

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.

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) {
    if(dg())
      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.

In the first post of this series I stated that the best tools, the ones that make developers efficient, are the habits that they possess. The habit I referred to in that post was the habit of keeping personal logs. In this post I will tell you about another habit that helps me in my daily work: The habit of personal planning.

When I come to work, the first thing I do after catching up on the e-mails, is grabbing a pen and notebook and start listing today’s tasks. When I’m done listing the ones that are in my head, I turn to my work log and my calendar in search for more things to be done. At this point I usually have a big unordered list of tasks with various degree of importance. It’s always more than enough for one days work so I start prioritizing.

In order to prioritize I rip out the page of my notebook to start a new list. Then I bring the tasks back to the notebook in order of importance. This time I draw a small square in front of every item, turning them into a proper todo-list. When finished I can start the real work, taking on the tasks one by one.

The planning usually takes around ten minutes to do and is worth every second. There are three main reasons for me to do it, listed here in order of importance:

1. It helps me do the right things in the right order, making me better focused and more effective.
2. Because of the importance of closure. When I finish a task, the ceremony of checking the square makes me feel good and brings me energy to take on the next task.
3. It helps me remember what I’ve done during the day. This comes in handy when it’s time to update my work log.

I have tried several applications to help me in my planning, applications like Notepad, Microsoft Outlook and iGoogle’s todo-list. None of them could, in my opinion, compete with the good old pen and paper, so that is what I recommend using. But remember: it’s not the tool that matters, it’s the habit.

Cheers

A comment on a recent post of mine made me think more about the distinction between a Software Programmer and a Software Developer. To me there is a subtle, but important difference. Let me give you my definition:

A Software Programmer is someone who really knows the environment he is programming. He knows everything there is to know about the language, the API and the Framework he’s using. He can do low level optimizations because he knows in detail what the compiler does behind the scenes. He is indeed a Wizard and a Guru of his domain. A Software Programmer usually starts with the implementation (probably because that’s what he is doing best) and work his way outwards.

A Software Developer on the other hand is a specialist at giving the customer (user) what he wants and what he needs. He doesn’t waste time on premature optimizations; he prioritize maintainability over performance, unless the performance is proved to be unacceptable; he has great testing skills, designing skills and communication skills; He is empathic, knows his HCI, and cares more about the user than he cares about his code. He cares so much that he usually becomes an expert himself of the users domains. A Software Developer starts with the interface (probably because that’s what he does best) and work his way inwards.

A person can be both, or more of one or the other. In a team you want both kinds but they are rarely found within the same individual. I, for instance, consider myself a great developer but an intermediate programmer. One simple way to test what type you are is to ask yourself this question: Do I care more for the interface (GUI or Programming Interface) than I do for the implementation? If you think the implementation is unimportant as long as it does what you want, and is reasonably maintainable, then you’re probably a Software Developer. If you find the previous sentence a blasphemy, you could be a Software Programmer. Which one is it?

C# entered the field of battle some seven years ago as a better version of Java. The one feature that many people referred to when claiming C# superior, was custom attributes. Now Java has them too, but they go under the name of annotations.

The ability to attach meta data to various parts of your program is a powerful way to integrate with frameworks or configure external utilities. Mike Kaufman, for example, used annotations beautifully to configure an Obfuscator. He has posted the details on his blog.

It’s not without sadness I see that what used to be my favorite language has taken a big dive in popularity recent years. Now Borland Delphi is only the 14th most popular programming language according to TIOBE Programming Community Index as per august 2007. That is five ranks lower than one year ago, and far from it’s golden days in the mid 1990’s.

Delphi was really a great language to work with. In the early days it was a strong, even leading power in the programming community. It gave us one of the first RAD environments, which sure as hell was more visual than Visual C++ and Visual Basic, its competitors at the time.

But the popularity decline didn’t come as a surprise. It started with Microsoft snatching Anders Hejlsberg, the compiler genius who created Delphi’s predecessor Turbo Pascal. Following that, the increasingly lower quality releases and the name changing mess. For some unintelligible reason Borland changed its name to Inprise, only to change it back a couple of years later, most likely due to an internal revolt. Slowly but steadily even the most devoted started to leave for other, obviously better, alternatives.

Last year Borland announced that they were selling all of its development tools, including Delphi. It long looked as if Delphi would be brought back under the name of Turbo Delphi, but the sale was canceled. Instead the development tools were spun off into a new company, owned by Borland. Since then Delphi 2007 for Win32 has been released, the best release in many many many years. They really did shape up, but I’m afraid it’s too late. The magic is gone and I have moved on.

Farewell my friend.

When people talk about tools in the context of software development, they usually refer to stuff like Integrated Development Editors, Automatic Build Systems, Testing Frameworks, Documentation Extractors, or other useful applications that makes their lives as developers easier. Those are all great and productive tools, but they are not the most valuable ones. What really makes an effective developer is the habits he or she possesses.

One such habit, that helps me tremendously in my work, is keeping personal logs. I keep all kinds of logs: a work diary, a solutions log, books I’ve read, ideas I’ve had, a success journal. Well, to be honest, the last one doesn’t have much content; probably because of my Swedish background. For us “modesty is a virtue” and that’s what’s holding me back. At least that’s what I tell myself. 😉

When I keep a journal I prefer a simple format. Usually word documents are sufficient, sometimes with a special header format that visually separates the notes. There are times when I use a Wiki, but since I prefer a chronological order I tend to go with simple documents. They are easier to move around, and with tools like Google Desktop Search there’s no need for firing up a database to hold my straggling thoughts.

I like to think of the solutions log as the bare minimum, something that every developer should have. Of all my journals that I keep, I value the solutions log most. This is because it’s the most useful one, but also the easiest one to update. Whenever I run into a problem that doesn’t have an obvious solution, I follow the same pattern:

1. Search the Internet for a solution. Nine times out of ten this puts me right back on track within minutes.
2. If I can’t find a solution on the Internet I ask a colleague.
3. If a colleague can’t help me (this is also a nine out of ten-er), then I have to find the solution on my own. This is a tedious task. Good thing it doesn’t happen very often.
4. I document the solution in my solutions log.

My solutions log have the form of Q&A. But instead of questions it has problems, and the answers are called solutions. My P&S (as I call it) have helped me many times, because problems have a tendency to resurface. When they do – often years later – I know where to look for a quick solution.

I’m also very fond of my book log. I read a lot of books and to keep a track of them I make short notes. I don’t write fully fledged reviews but small notes on how I found the book and what I learned from reading it. Whenever I come across a topic I know I’ve read about, I consult my book journal. The notes there work like triggers that bring back the memories of the subject.

This was the first post in my new series: Tools of The Effective Developer. If you have an idea you want to share of an invaluable tool, send me a comment and maybe I’ll add it to my Blog Post Ideas Log.

Cheers! 🙂

This is totally off topic, but I can’t help myself, I have to pass this one on. If you, as I did, grew up with role-playing games like AD&D, then you’ll find this comic book version of The Lord of The Rings hilarious. The creator really nailed it with this one.

In my previous post I mentioned that I wasn’t sure of how the D Contract Programming feature works in an override scenario. Wekempf inspired me to delve deeper into the matter. Here is what I found.

Contract Programming states that preconditions may be weakened by a deriving class, but never hardened. For postconditions the reverse is true: they may be hardened but never weakened.

The D Programming Language specification states:

“If a function in a derived class overrides a function in its super class, then only one of the in contracts of the function and its base functions must be satisfied.”

In my experience this isn’t the case. Consider the following code:

class A {
  void f(int a)
  in { assert(a > 0); }
  out {}
  body {}
}

class B: A {
  void f(int a)
  in { assert(a > 1); }
  out {}
  body {}
}

Method B.f overrides the corresponding method in A. If B.f is invoked with an argument of 1, the in-clause of B.f should fail and A.f succeed. According to the specification only one of the two needs to be satisfied. Let’s see if that’s true.

A o = new B;
o.f(1);

The program halts with a contract failure in B.f. The preconditions of the base class is never even checked.

What happens if I add a call to the base class method?

class B: A {
  void f(int a)
  in { assert(a > 1); }
  out {}
  body { super.f(a);}
}

It turns out that the super-call triggers the in-clause of the base class A (and only that one). It seems like the semantics differs from the statement in the specification. The current behavior opens up for abuse of the general principles of Contract Programming by allowing preconditions to be hardened and postconditions to be loosened.

I don’t care all that much though. To me it seems difficult to have the language enforce those rules anyway, at least while keeping the contracts flexible. And, the current behavior is what I’d expect if I wasn’t aware of the Design by Contract principles.

Update: It turned out that this feature is currently not implemented in the DMD compiler.