Older blog entries for prevostjm (starting at number 2)

Whoa--I didn't know only the most recent diary shows up in the recent entries section. Please see my previous entry for what I'm hacking about in O'Caml right now.

What O'Caml Is

Just so people have some reference, O'Caml's a strongly typed functional programming language. It has a really zippy bytecode interpreter, as well as an excellent optimizing compiler. The language uses a technology called type inference so that you only need to write types when defining an interface or when you want better diagnostics.

The good thing about this is that all the type errors happen at compile time, not runtime. And since polymorphic types (sort of like C++ templates, but less insane) make things easy, you can specifically ask for a type with null (option) or which you can change (ref) instead of being bound to have those features even when you don't want them (like in Java.)

O'Caml seems to be pretty popular in Europe, and it seems to be catching on at least a little in the US, though its following is minimal compared to Python or Perl.

It's a different way to look at the world, but, I think, a valuable one. I recommend checking it out.

(Oh, and as for the "O'" part, it has object oriented features--very different from what you may be used to, but pretty cool. The feature I like best is that I can build a dynamically loading system and compile the parts I always use to native code, then have the bytecode parts load on demand. Something I've always wanted from Emacs.)

O'Caml Hacking

Well, O'Caml 3.00 came out the other day, and it's made me think a bit about doing some more hacking. There's been a lot of discussion on the caml-list lately about the problem of interacting with other peoples' code. In a way, it's the same sort of problem that C has, exacerbated by the fact that you can't easily do things like:

#include <packagename/header.h>

in caml. Instead, the module namespace of a given package is either entirely at the same level as the standard libraries, or is manipulated purely by adding -I library-path to the compile flags.

Needless to say, this makes things kind of messy. The second problem is that there's a wide variety of compilation models used by different people. C has won here by the increasingly common use of autoconf and automake.

What I really want is something akin to the namespace management of Perl. Perl is a mess sometimes, but it's terrifically easy to grab somebody else's package, install it, and try it out. I think that if a language's publicly available libraries are to grow, something like this has to be available.


Gerd Stolpmann has developed a pretty slick tool called findlib to handle some of this--it will install individual packages with "META" files which describe which libraries need to be linked against in what environments (bytecode, native, threaded, non-threaded) and what other packages are dependencies. You can then write:

ocamlfind ocamlc -package netstring foo.ml bar.ml baz.cma

instead of

ocamlc str.cma -I /usr/lib/ocaml/site-lib/netstring netstring.cma foo.ml bar.ml baz.cma

This is a big win--but not so much until everybody uses it. I've suggested this functionality be folded into the standard O'Caml distribution, but I don't know whether it'll happen.


As for the variety of makefile variants out there, I'm not sure what the right thing to do is--but I'd like to do something. Some people have mentioned that stuff is difficult on Windows and MacOS, and also that on Unix, you often want to build O'Caml and C and various other things. For this latter, makefiles are the only real option.

I've been wondering if a make replacement written in O'Caml might be a good thing. ant from the Jakarta project has provided a pretty cool XML-based make replacement for Java which does nice things. This is definitely preferable to other Java-building solutions. The biggest win is that it's cross-platform.

So, I think I might start work on an O'Caml build tool to help with at the very least pure O'Caml projects.

Thoughts on the certification thing:

Mailing everyone would probably be bad. :) But I suspect you could do pretty well by taking a statistical sample--and at that level, it's sort of interesting.

But, in general, I'm not sure it's a great idea at all. As dria said, you don't need the machine to tell you who you know about.

A thought, though. It's in some ways interesting to think less in terms of the people who everybody recognizes, and more in terms of the people who you don't recognize. Brin's book EARTH had a system in which people had a reliability rating which appeared next to their posts--and that's important when everybody can say things.

I think there's little value to a system in which people are rated based on how well known they are, but much more when you can find out how respected their opinions on a certain subject are. I mean--you don't know me from Adam, but if you shopped around a bit, you might find out I've got some good knowledge of Emacs, Perl, Java, and good specific (non-normal) knowledge of scary XSL tricks, scary SQL tricks, and functional programming languages. And, more importantly, that I started but didn't finish writing nnimap for Gnus. (Which cuts me both ways. :)

Knowing these things makes it much more easier to figure out what things I say are reasonable, and what's bunk.

I think the main thing is that none of this stuff should be in any way mandatory--and it's only necessary for those faces you haven't seen before, when there are a *lot* of faces.

Now that I understand the diaries are the main important advogato feature, I see why it's even a question. And I'd say that what you really want is a way to rate somebody's "reliability" or whatnot any time you read something from them--assuming that you only do so when you know it's good stuff or bunk.

And once you have that, the averages ought to work out reasonably. Which only leaves the problems of "how do you convince people to do this, and do it right?" and "how do you do it without getting in the way?"

Which turns out to be really hard, of course. :)


New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!