OK, the Javascript version of Y needs apply too. Patrick explains.

I think it is fantastic that relatively new, yet widely popular, languages like Python, Ruby, and JavaScript have adopted such useful Lisp features as closures, apply, etc. (Now if only they'd adopt the syntax!) [Patrick Logan's Radio Weblog]

What I like about the Lisp syntax is how it shows the simple model of Lisp so clearly. But I think that syntactic shortcuts makes the code easier to read, although everyone seems to like different shortcuts. Everybody should have his own editor that let's you edit the code in your prefered syntax, but saves it in standard syntax. F.e. I prefer f(a,b) or a.f(b) over f a b and {|x| ...} over (lambda (x) ...). So the Y combinator should look like this in my editor:

define(Y, {|gen| {|f| f(f)}({|f| gen({|x| f(f).apply(x)})})})

OK, the Javascript version of Y needs apply too. Patrick explains.

Here's a famous and amazing lambda trick. [Patrick Logan's Radio Weblog]

And the same famous trick in Javascript. May I say I like the Javascript function more than the Lisp or Python version? Because there's no apply needed.

I've been trying to recreate the layout of w3future.com without tables. I couldn't even get close. Just the main layout was a problem: a header at the top; a footer at the bottom; two blocks, one with a fixed width and the other taking up the rest of the width, both filling the space between header and footer. This while I think I know CSS fairly well and I have been paying attention to all CSS discussions lately. So I challenge anyone to recreate w3future.com without tables, with the least caveats. If you want to give it a try, don't just use any page from w3future.com, but use this special simplified self-contained page.

Orange Delight is a palette that someone created with the w3future.com color editor. I had chosen it as my prefered pallete a while ago. Today I've decided I like it so much it should be the default w3future.com palette. To the person who created this palette: Thanks!

I had a Google search page that used the xml form of the Google results. It had stopped working a while ago, because Google does no longer permit accessing results in xml. But I had not yet changed the page. Today I received an e-mail from Ray Sidney of Google to "remove the indication" that it would still work. Pretty cool to receive e-mail from Google (no matter what the message is).

RDF Model Theory Working Draft Published. 14 February 2002: The RDF Core Working Group has released an updated Working Draft of RDF Model Theory. The document provides a precise semantic theory for RDF and RDFS, and sharpens the notions of consequence and inference in RDF. Learn more on the RDF home page, and read about the W3C Semantic Web Activity. (News archive) [The World Wide Web Consortium]

At first glance, this looks very promising.

Before more people get confused, let me say a few things. 1. Using tables doesn't mean your page can't validate. 2. Validating your HTML is important. 3. Validating your HTML isn't complicated or a lot of work. For Radio Userland this means: 1. The built-in macros should produce valid HTML. 2. The default theme should validate. Now check out this page. There are no big problems there. A good start would be to change radio.images.imageRef so that it produces alt="" when the alt parameter is empty. But actually providing alt texts will make some blind users and images.google.com happy.

Now, how does this compare to my comments yesterday. Valid HTML does not mean you're using the HTML in a valid way. Why? Each HTML tag has some kind of meaning. When you use a <blockquote> tag, it means you're quoting a block of text from someone else. But tables don't actually mean very much. To 'blockquote' the HTML spec:

The HTML table model allows authors to arrange data -- text, preformatted text, images, links, forms, form fields, other tables, etc. -- into rows and columns of cells.

However, the HTML specs warns you:

Tables should not be used purely as a means to layout document content as this may present problems when rendering to non-visual media. Additionally, when used with graphics, these tables may force users to scroll horizontally to view a table designed on a system with a larger display. To minimize these problems, authors should use style sheets to control layout rather than tables.

So, can you use tables or not? It depends. I don't think it's wrong to use a table to put a sidebar next to the body. Certainly as long as it is complicated to do with CSS. But if you wrap each post inside a table, together with a number of spacer images, you should look at CSS. The good news is: in the first case tables are the easiest way to it, and in the second case CSS is the easiest solution. So you not only have nice HTML, but you have it faster.

Maybe a nice rule of thumb is to think about what would happen if a voice-browser would read your page. A table-based site layout would then sound like this: "w3future.com. Below that on the left 'a sidebar' and on the right 'the body'." etc. This gives a clear translation of you site, and helps the person that hears your page to have some feel of the structure of your site. But using tables to layout a post wouldn't sound as nice: "'A spacer image' next to 'the title'. Below that 'a spacer image' next to 'the text of this post' next to 'a spacer image'." You just want to hear: "'the title'. 'the text of this post'".

Yet each of us "know" apples in a slightly different way. Most of the time, the way we each know something is so much alike, that we communicate well enough to accomplish our goal. Every now and then we have a communication breakdown, and so we try to fall back to a less powerful, but more common level of understanding. Then we build from there.

The challenge with a "semantic web" is to build powerful *and* common levels of "understanding". In this case, "understanding" means "same set of definitions for the symbols being exchanged". Each system's symbols have to be grounded in the same definitions. (And any of the systems may be human or non-human.)

Even more challenging is for a system to recognize a "communication breakdown" (i.e. the "symbol grounding problem") and then to repair the problem well enough to accomplish the goal.

[Patrick Logan's Radio Weblog]

Interesting comments. However I don't think it's a really big challenge to have this common level of "understanding". That is because the symbols (or the "things" I talked about) of the semantic web are URI's. This means that anyone can introduce symbols. What I think what will happen is that companies and individuals will introduce task specific symbols. Simply because it makes work much easier.

Then this company or individual, or maybe someone else, can provide a grounding (transformation) into a set of symbols that is in common use within the appropriate community. And a smart person within that community may provide a transformation to symbols from another community.

But just like spoken languages, there's not reason to have a basic level. Whenever there's a transformation from one symbol to another, or several others, someone will provide it. And when there is no transformation of symbol A into language B, there's no reason to use symbol A in language B. Spoken languages regularly borrow words from other languages too.

I see more challenge in building the global system that takes care of all those tranformations. The most logic systems I've seen assume total knowledge. There has to be infrastructure to acquire required knowledge. Anyone has some docs?

Don Box writes a reply to Dave Winer's complaints, though he doesn't specifically say so. Instead, it is written as a general appeal to the scripting community at large. It will be interesting to see the replies since Don also takes the opportunity to bash script programming a bit (or more than a bit). [Dan Shappir]