This is a curious position from Sean McGrath. Unfortunately I see no substance for debate, so all I can say is I think I disagree. What are the implications of the "yin/yang" tilting too far in either direction? What if a machine could read such out of balance XML and do more for the people? How can I evaluate a technical issue based on passion alone?

Compromisiming on standalone readability by *people* is, unfortunately one of the classic premature optimisations in the XML world. The essence of XML is the yin/yang between people and machines. Tilt too far in either direction and the noosphere weeps.

The rss-data proposal tilts too far away from people in favour of machines. There is no point in teeing up a data structure for the agregations in terms of dates, strings and integers and calling it XML. It is XML is syntax only, not in spirit. If you really want to do that, use ASN.1 or something.

What is XML if it is not an aggregation of dates, strings, and integers, etc.? What is the "spirit" of XML? Is there just one "spirit" of XML that should bind us all? I really want to know more about his position.

Skiplist Cookbook

The skiplist is my favorite data structure (PDF). So simple and efficient.

I have implemented it several times in Smalltalk, Java, and Scheme. The linked cookbook is very straightforward, but even without it, the concept is what allows the implementation this quality.

The idea begins with a linked list. But each node may have more than one forwarding pointer. The number of pointers in a node is based on a random number and they form a tree shape. So you end up with easy code to write for searches, adds, and deletes, but you also end up with tree shaped performance, i.e. O(log n).

Moreover since the tree shape is based on a random number instead of the data in the nodes, there is no need to "rebalance" the tree on adds or deletes.

The paper does a good job of illustrating this concept and has all the source, so I won't even try to cover the details.

A Simple (One Hopes) View of Continuation-Based Web Serving

Daniel von Fange wonders about continuation-based web serving. He adds "treating a 'page' as a method of an object makes more sense to me for 97% of things I do.".

Without getting into how continuations work, you can look at it this way: continuations allow a web page to behave just as you prefer, kind of like a method of an object.

What if methods in your favorite language required you to do the following: every time the method itself calls another method, the return value does not go back to the caller. Instead what if you had to name some other method to receive the return value?

In this case you have to "name the continuation", that is, provide an explicit place (method or page) for the computation to "continue" following the call (or the user interation, in the web scenario).

But in a continuation-based web server, just as in most programming languages, the system handles "where to go next" implicitly. That is, in most programming, you do not need to provide an explicit "continuation". The system is happy to return the value right back to the point of the call.

And so just as your method calls another method and the results are returned right there for you to use, your web page "calls the user" and the results are returned right there on the page for you to use. You do not have to name another page to receive the results.

Hope this helps. The mechanics are less important for understanding the benefits.

If you think about it, "continuation-based web servers" should be the expected behavior since they handle continuations for you, just like programming languages. More typical web servers should be considere the odd ball. They make you do explicit "continuation passing". No one likes to program in "continuation passing style". It's just, we've gotten used to the burden with most web servers.

Continuous Curiosity

C. Keith Ray explains the benefits of institutionalizing continuous learning in his software development team...

The effort paid off within weeks as we incorporated the new knowledge back into our product. For example, we used our newly acquired JavaMail knowledge to start sending HTML email.

Statice

Ted Leung writes... about notations for programming, databases, and otherwise...

Languages need a way to assimilate these paradigms in a way that makes them look seamless.

I would point out two of my favorite examples.

• One is Gemstone Smalltalk's OODB "select blocks" (PDF) which use a notation similar to Smalltalk blocks, but actually implements a declarative query language with structural access to graphs of collections of objects. Although it was very useful, the feature was never developed nearly as much as it could have been.
• The other is Symbolics' Statice OODB. Being based on Lisp, the syntax is much richer and fits more seamlessly into the host language. Unfortunately the Lisp market was already heading for the doldrums, and so a lot of the experience from Statice went into the C++ OODB rather than into Lisp. But apparently Statice is still available.

(defun transfer-between-accounts (from-name to-name amount)
  (with-database (db *bank-pathname*)
    (with-transaction ()
      (decf (account-balance (account-named from-name)) amount)
      (incf (account-balance (account-named to-name)) amount)
      (when (minusp (account-balance (account-named from-name)))
        (error "Insufficient funds in ~A's account" from-name)))))