Making it stick.
Saturday, October 11, 2003
  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. 

Wednesday, October 08, 2003
  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. 

Tuesday, October 07, 2003
  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. 

Monday, October 06, 2003
  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.



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.

(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)))))
Patrick Logan's weblog.

March 02, 2003 / March 09, 2003 / March 16, 2003 / March 23, 2003 / March 30, 2003 / April 06, 2003 / April 13, 2003 / April 20, 2003 / April 27, 2003 / May 04, 2003 / May 11, 2003 / May 18, 2003 / June 01, 2003 / June 08, 2003 / June 15, 2003 / June 22, 2003 / June 29, 2003 / July 06, 2003 / July 13, 2003 / July 20, 2003 / July 27, 2003 / August 03, 2003 / August 10, 2003 / August 17, 2003 / August 24, 2003 / August 31, 2003 / September 07, 2003 / September 14, 2003 / September 21, 2003 / September 28, 2003 / October 05, 2003 / October 12, 2003 / October 19, 2003 / October 26, 2003 / November 09, 2003 / November 16, 2003 / November 23, 2003 / November 30, 2003 / December 14, 2003 / December 21, 2003 / December 28, 2003 / January 04, 2004 / January 11, 2004 / January 18, 2004 / January 25, 2004 / February 01, 2004 / February 08, 2004 / February 15, 2004 / February 22, 2004 / February 29, 2004 / March 07, 2004 / March 14, 2004 / March 21, 2004 / March 28, 2004 / April 11, 2004 / April 18, 2004 / April 25, 2004 / May 02, 2004 / May 09, 2004 /

Powered by Blogger