I'm going to XML Europe. This year it's held in London, and I've never been to London before, so I'm really looking forward to this. This conference seems to be for the big companies, so I'm curious what the geek level will be. Any other geeks going? If you are going, be sure to go to the Xopus presentation by Laurens. You'll be impressed!

Dave Winer gets flamed a lot again. In the past I've responded to other seemingly ignorant remarks from Dave too (though I tried to be constructive). But Dave had a very good point each time. As a programmer it's tough to face the truth that technology often fails, but Dave seems to be an exception.

Probably a lot of the flames are about the problems Dave has with CSS. My first reaction was the programmer speaking: that HTML is not valid, it probably confuses Internet Explorer. However, Dave has used this style of HTML for a long time, and without CSS the browser is not confused.

CSS adds a layer of complexity to the browser. Plain HTML, no matter how invalid, is just a chain of commands to the browser, which is easy for the browser to render. CSS requires this HTML to be a nice tree, and each branch has a set of default style rules, which can conflict if your HTML isn't following the spec.

But with valid HTML and CSS everything should be relatively easy. But in practice this is not true either. At Q42 we regularly have problems getting the HTML and CSS to look the way we want, even though we consider ourselves to be intelligent and experienced HTML and CSS coders. Wired and ESPN recently switched to CSS, but they are still considered pioneers among the large sites.

Even if all browsers support CSS level 3, there still will be problems. Mozilla uses CSS to create skins, but they needed to add a big list of extra properties to make it work. Especially -moz-flex is something that I would like to see implemented in browsers. It makes an element take up any remaining space, without reducing the surrounding element to the smallest size possible. In HTML you can do this easily with tables, putting width="100%" on a table cell.

Then there's the problem of the lack of tools. The current HTML editors build on the exprience from WYSIWYG DTP tools. But WYSIWYG isn't enough anymore. New editors have to created that help and educate users to create HTML that expresses the structure of what they want to write. The basics for CSS editing are there, but I'm wondering if new editors can provide good interfaces for the more advanced CSS features, instead of just letting you enter the values of every possible CSS property.

Paul Graham writes about the languages for over a 100 years. I'm deeply tuning in here, because Loell is my ideal language, and as I don't care about its speed, anything that's good for over a 100 years, should also be good for Loell. (Unless it takes too much effort to implement) I'll comment on Pauls article piece by piece.

At any given time, you're probably happiest on the main branches of an evolutionary tree.

I don't think this is true. A language should indeed be close to the main branche. But if it doesn't take some pragmatical sidesteps, the language would probably miss a few practical features.

I think it's important not just that the axioms be well chosen, but that there be few of them. Mathematicians have always felt this way about axioms-- the fewer, the better-- and I think they're onto something.

This is exactly the basic design principle of Loell. It's great that someone like Paul Graham refers to this. It has always annoyed me that language comparisons so often are about the available libraries. Instead, we should identify the axioms of each language, and see which are the most elegant. It is also important that these axioms are directly accessible to the programmer, and not tied to a particular part of the language. Otherwise programmers will still try to access that feature using tricks, which results in unmaintainable code.

The right way to solve that problem, I think, is to separate the meaning of a program from the implementation details. Instead of having both lists and strings, have just lists, with some way to give the compiler optimization advice that will allow it to lay out strings as contiguous bytes if necessary.

I don't even think there's a need to give the compiler advice. The programmer probably won't even know there is a compiler. I think languages will behave more and more like scripting languages. Optimisations will only happen through profiling. Complex mathematics may be an exception, but the slow pieces of code in everyday programming are the ones with many loops and a lot of data. These pieces of code are perfect for profiling.

How far will this flattening of data structures go? I can think of possibilities that shock even me, with my conscientiously broadened mind. Will we get rid of arrays, for example? After all, they're just a subset of hash tables where the keys are vectors of integers.

Get ready for a shock: Javascript already does this. Even worse: the integer keys are first converted to strings!

Unlike physics in a hundred years, which is almost necessarily impossible to predict, I think it may be possible in principle to design a language now that would appeal to users in a hundred years.

I'm not sure. I think one area of expertise is still missing: continuous data transformation. Something like XSL, but in such a way that the result changes automatically when the input changes, as in Excel. This will become more and more important. Historically programs are written to execute with existing data as input. But to be competitive on the internet, results need to be continuously updated while new input comes in. For example, you can sum live data by summing your input every time it changes. But this pseudo code would be much faster:

initial:      sum = 0
on add(v):    sum += v
on remove(v): sum -= v

I'm not even sure if i'd prefer to program this way, or if I'd just program summation for a collection, and let the compiler figure out the above code.

I love the P800. It's loaded with cool features, and it's relatively easy to develop for it, so there's new software available every day! It's the perfect combination of phone, PIM and (internet quality) camera.

I can now post pictures to this weblog. This goes as follows:

• I take a picture with the P800.
• I mail this image as attachment to radio@w3future.com, with the description in the message body, with the P800 using GPRS.
• Radio Userland checks the mail, and an adaption of a script by David Davies in weblogData.callbakcs.weblogCheckMail creates a post with an image. The text from the e-mail body becomes the alt text of the image.
• Finally a script in user.radio.callbacks.postItem puts the alt text from the image in the title of the post.

Posting with my new P800