Older blog entries for welisc (starting at number 25)

The O'Reilly book (in French) about O'Caml is online. I skimmed through it and was surprised to find I could follow it pretty well. This seems likes an interesting, if slightly unusual, way to brush up on my technical French. A volunteer project to translate it into English has completed about 70 % of the text.

The results of the Fourth ICFP programming contest are out. First place went to Haskell Carrots. The Dylan Hackers came second, with most of the team using Gwyddion Dylan, which would indicate that the current version is in a very usable state. Dylan is interesting for the reason outlined in the contest write-up:

A major design goal of Dylan is to produce a language in which complex programs can be rapidly prototyped in the same way as with dynamically-typed languages such as Smalltalk or Lisp or "scripting" languages, while at the same time enabling performance comparable to statically typed languages such as C or ML.

Having problems building DrScheme and Bigloo from source using gcc 3.0. Luckily, I still had the (very) old installation of gcc 2.91.66, which compiles them without a problem.

Spent half the afternoon tracking down a mysterious segfault caused by one little line:

static char *sort_phen1 = NULL,*sort_phen2 = NULL;
static int initialised = FALSE;

/* lots of code */

static int sort_comp_phen(Ind *s1, Ind *s2)
{

char *sort_phen1,*sort_phen2;
if (!initialised){

sort_phen1 = chrom_string();
sort_phen2 = chrom_string();
initialised = TRUE;

}

strcpy(sort_phen1,chrom_phenotype(s1->chrom)); strcpy(sort_phen2,chrom_phenotype(s2->chrom));
return strcmp(sort_phen1,sort_phen2);

}

Strange how you can never see something that's staring you in the face. Compiling with the -Wshadow flag would've caught it.

Bruce Eckel isn't impressed by Ruby. I've tinkered with Ruby and I like the pure OO design but there are two reasons why I don't see myself doing much with it. First, it's not as concise as Perl for writing small scripts (neither is Python). Second, and more significantly, there are no Ruby libraries that make it worth my while learning it. By contrast, there are at least two Python molecular modelling projects, Pmv and MMTK, each of which is fairly mature and featureful. Even if I didn't care about Python having a cleaner design than Perl, these two libraries would be a compelling reason to learn it.

New Scientist has an interview with Stephen Wolfram about his new book. He may or may not be "the Isaac Newton of the 21st century" but the book sounds interesting. This kind of simulation is going to be hugely important in bioinformatics.

I'm not well prepared for this kind of stuff; looking at Mark De Pristo's notes on bioinformatics programming in Scheme reminds me just how little I know.

Paul Graham's article Beating the Averages is interesting. Lisp programmers (and functional programming advocates in general) have been saying this kind of thing for years. I suspect they're right but at this stage in my career, my job prospects depend on knowing the usual suspects (C/C++/Java/Perl). It's a pity because the idea of trying something different, especially something that would give me an advantage over the competition, appeals to me.

Working through the exercises in Accelerated C++. Eiffel may not be as concise as C++ but at least you can't make stupid mistakes like:

line = string('*',cols);

instead of

line = string(cols,'*');

Took me a while to spot that one.

I've come to the conclusion that I like languages to be concise; that's why I haven't given up Perl for Python or Ruby. Lately my Perl scripts have become exercises in using the least possible number of variables. I never loop over a list where map will do the job. If this continues, I'll end up coding in Haskell.

One thing I've thought would be useful is a way to interface Eiffel objects with a scripting language. Victor Putz has done it with epolyglot, a library that supports mixed-language programming in Eiffel, Python and Haskell.

Hodges Figgis are having a sale at the moment; Core C++: A Software Engineering Approach looked like a bargain at £10.99 but having read the ACCU review, I'm glad I didn't buy it: "Not Recommended" is pretty damning.

Installed GCC 3.0 to try out gcj. It looks like native code runs 2-3 x faster than byte codes on the JVM 1.3. If this is really the case then the performance gap between C and Java is small enough to make Java a feasible alternative.

Now if it only had generics and operator overloading...

Not sure I'm clever enough to be a Scheme programmer. Doing quite well with Teach Yourself Scheme in Fixnum Days but the implementation of the amb operator is baffling.