25 September 2004

romanian topcoders

Here is a list of "division 1" romanian topcoders that have unlocked their cards, have photos, and have participated in the last three months: Note that the locations are approximative (i.e. what I remember from various conversations). Also, the order is arbitrary.

24 September 2004

code size

As you know I'm experimenting with OCaml lately. A few days ago (yesterday?) I've solved a simple problem from TopCoder. Very roughly the statement was: you are given a suface and some recatangle masks cover it. Return an ordered set of areas of the remaning "holes". The solution is not interesting. What is interesting is that I've implemented it in both C++ and OCaml. By byte count the OCaml solution was roughly 45% the size of the C++ one. After compression (with bzip2) it was about 67% of the C++ solution. Sounds cool. Anyway, I still spend much more time starring at the monitor when writting in OCaml. The automatisms are not there yet. Also, my knowdgedge of the library is, to say at least, shaky.

Simplicity

I have submitted (together with a collegue) an article to a conference. It was rejected. The reasons invoked (by the three reviewers) were:
  1. bad English
  2. presents a straightforward exercise
  3. the tool is not clearly better than another one already on the market
The first reason is a very good one. It is unpolite to make the job of your readers harder because you don't use well such a basic tool as language. For the second one I'd like to tell you what another collegue told me about part of the "exercise": ah.. this is very simple. And then procedeed to give an incorrect solution. So I gave a counter-example. Then he corrected the solution. Or so he says. I was too tired to search for another counter-example. Hmm.. Did I forgot to mention that we proved in the article that that very part is impossible to solve without slightly relaxing the conditions? I bet he still doesn't know that his solution is wrong. The third one is a good observation. However, the tool in itself was not the main subject of the paper, but rather the algorithms used in it. Furthermore, I feel that the most important characteristic of those algorithms is high confidence that they are correct. I'm probably a mean ego-centrist but I must tell you what reminded me of this rejection: this part of an EWD: "Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better. The computing industry is not the only one that has discovered that sore truth: so has the academic world. If you deliver a lecture that is crystal clear from the beginning to end, your audience feels cheated and mutters while leaving the lecture hall "That was all rather trivial, wasn't it?". One of our learned journals has rejected a beautiful paper of mine because the solution it presented was too simple to be of academic interest and I am waiting for the rejection of a paper on the grounds that it is too short.

Also our academic reward system works against us. One can get credit for some complicated concepts one has introduced, it is hard to get credit for the discovery how some established but complicated concepts had better be avoided: those unaware of these concepts won't notice your discovery and those with vested interests in them will hate you for it. Hence my urgent advice to all of you to reject the morals of the bestseller society and to find, to start with, your reward in your own fun. This is quite feasible, for the challenge of simplification is so fascinating that, if we do our job properly, we shall have the greatest fun in the world."

So, I'll get back to my fun job :)

23 September 2004

Software metrics

Is it a good idea to measure the code you produce? Persoally, I like to look at statisics such as number of lines produced per day by a programmer. You should always be aware that it is easy to lie with statistics. So try to avoid to show them to people who don't understand them. But do try to use them for your own improvement.