Hrum. I've been using Zope a bit lately for class, and ACS a bit lately to work on getting hired. I'm not really satisfied with either, though.

What a Good Web System Needs

The way I see it, Zope and ACS are coming at the web publishing problem from two different places--and you need parts of both of them to have things work nicely. (And, perhaps, a third thing.) What Zope has that 's pretty fucking awesome is the drop-in products. These are slick. Being able to turn a web application into a simple plugin that somebody can "mount" (or the like) on a URL space is very very very desirable.

On the other side, though, relational database backing is a really really good thing. ACS has done this very nicely, but Zope products tend to use the ZODB for this sort of thing, and I'm not convinced this is sufficient. Zope has RDBMS support, but no consistent data model, and as I said, the products don't tend to use the SQL stuff. ACS is really really lacking in the ability to do work without having to write lots of grungy code, though.

On yet a third side, we have the problem of writing interesting content. This gets into template systems and things like DTML. I've written several such systems for work--and frankly, no matter what I've tried, they all end up sucking in the end. The only solution I see is dividing the building of pages from the formatting of pages. Fortunately, XSL processing should be usable for this.

How use XSL here? The database accessing stuff generates simple XML. (Good! No formatting tags getting in the way, you can tell what the fuck is going on.) Then, this XML is spun through an XSL stylesheet to introduce formatting (this is where things like "color every other line of the table" come into the picture), and then the result is spat out as HTML.

Cocoon is doing some of this stuff--and Cocoon 2 has some especially nice ideas going into it. Guess I'll see what happens there. I'm doing some experiments myself on the theme of "what's the right way to define pipelines on various URL spaces that still allows drop-in modules". We'll see what happens.

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.

findlib

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.

Makefiles

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