Radio Silence

I am turning Radio off and moving to Memory Hierarchy with new RSS feed.

9:10:19 PM  #  

Can't argue with BDFL, can we? main() in python

how to write main() in python

http://www.artima.com/weblogs/viewpost.jsp?thread=4829

11:32:49 PM  #  

Spring cleaning

deleting lots of scraps -- see Google cache instead. Sorry.

(one week later: still deleting more)

11:06:56 PM  #  

Reading source code

Ted Leung laments he cannot think of any source code good enough to read like literature. Well, I wouldn't claim I grok them but I certainly have enjoyed reading them:

• vsta
• rc scripts
• cii - only so called 'Literate Program' I could bear to read.
• calc (from emacs) - a CAS sadly few appreciate.
• two papers in gopher (hugs?) by Jeroen Fokker.
• programs in Icon and Smalltalk tend to be neat and tidy.

Of course, the above list is not complete.  I'll add a few later if I remember.  Funny I cannot think of any Java source I like reading.

9:14:01 PM  #  

Back to the future

Finally I caught up with Alan Kay's presentation at recent Emerging Technologies Conference thanks to Lisa Rein's video recording.  It was awesome to see historical footages of  Ivan Sutherland's Sketchpad and Doug Englebart's NLS hypertext from the 1960s, all demonstrated under Kay's Squeak (or Croquet 3D immersive virtual reality system).  Yes, it's quite something to see the future in the past.
10:41:58 PM  #  

A few qualities of web services

Asymmetrical Benefits.. Glenn Fleishman--who created the book-finding site, isbn.nu -- writes that "Web services fed by companies that don't offer two-way contracts -- contracts that promise continuity, uptime, consistency, and persistence -- will make application developers nervous about relying on them."

This is a critical and non-obvious issue. First of all, sites like Glenn's, which depend on aggregating multiple web services, must be resilient. If the Amazon service doesn't respond, isbn.nu still shows data from the remaining booksellers. In this sense, isbn.nu is loosely coupled.

Amazon.com won't even notice is isb.nu goes off line, so there's a substantial asymmetry in their relationship. Glenn's point is that more business-critical applications, the less significant partner will hesitate to depend on such a relationship unless service-level commitments are offered. (Glenn was one of those people I wish I'd been able to spend more time with at the O'Reilly conference.) [Doug Kaye: Web Services Strategies]

A few comments: One I wish http://isbn.nu becomes more widely known and used. It's rather unfortunate (okay make it very unfortunate) that so few people use ISBN.  Isbn.nu is a great resource if you want to hyperlink a book, not a bookseller like Amazon. (Yes I understand people link to Amazon because of its market dominance and large inventory and by sheer force of habit.)

Now on Fleishman's comment about desirability of web services "contracts that promise continuity, uptime, consistency, and persistence".  I think we'd be better off if we think about these desired qualities in terms of business process, abstract user interface, requirements definition rather than in terms of current web services technology.  (The latter is about mechanics or at best low level procedures.)

For a starter, how do we agree on "continuity"?  Is it analogous to "Cool URIs don't Change"?   Is continuity same as idempotent?  Or how about referential transparency?  What kind of services and resources can have continuity as quality?  Looking up a book has simple continuity (ISBN is permanant) but what about finding weather information? 

How can we square continuity with persistence?  One handy notion of persistence is the ability to retrieve past records - but this notion leaves a good deal unsaid about possible ephemeral side effects from CRUD operations on those records.   (Reconstucting trails of these side effects can be fun fun fun.)  Another notion for persistence is about data retention, removal, segregation, etc.  Thinking about data retention alone would make you seek expert legal counsel - think subpoena - and insurance brokers.

My take on consistency is another simplistic notion of "quality of service" as understood by laymen like "I've been drinking Peet's coffee for 20 years because of their excellent taste."  As Wily E Coyote would say, "I trust Acme Company's products with my life."   I wonder if you can legimitely complain about consistency of service when you hit jackpot using the lottery numbers from a web service?

As Doug Kaye says all this is "non-obvious" (which I'll translate for myself as "bloddy difficult").

[A side note to myself:  equating URIs to addressibility doesn't help.  A sheet of paper is exchangeable with another.  Think Bose statistics.]

[Another note: qualities are in general not orthogonal to each other.  If they were life would be so easy yet so boring.   But then orthogonality is something many smart people believe in, worship and love.]

[Yet another random tangent: "Contract" has been a buzzword for IT industry for a while (How much is it due to Design by Contract?)  but has anyone developed real enforcement mechanisms?  In real life contracts are drawn and broken willingly and unwilllingly all the time.  Unlike binary software arbitration, determining how a contract is "honored" or "broken" is a fairly complicated and nuanced process.]

11:15:53 PM  #  

Scripting Java

AOP and Scripting Languages.

Rickard writes about a recent implemenation that combines Javascript and his Aspect Oriented Programming (AOP) system.

One interesting thing here is that while all the objects are AOP objects, implemented with dynamic proxies that have a bunch of interfaces, the weak typing of JavaScript comes in handy since there's no need for casting in the above script. Typically you'd have to have a cast for the result of portlets.get(i), and for the "node" object, and for the result of getContentLayout(), but not here. This makes it very easy to script AOP objects.

I've been playing around with this idea, wondering what the extreme benefits would be.  Javascript's weak typing is a great convenience, however could there be more?  There are two approaches that I can think of. The first, is to use Javascript at the outer layer of a system, just as described above.  The second, is to use Javascript as the core object model.  The advantage of which is that all objects are dynamic, dynamic in the sense of the Adaptive Object Model (AOM) style.  Now, the AOP feature may be that you may dynamically add aspects on the fly, possibly in a manner that is completely oblivious to the programmer.

I mean, there were discussion earlier about weather or not aspect definitions should be described in XML or Java.  Well how about describing it in Javascript, its perfectly acceptable behavior, after all doesn't mozilla use Javascript to describe preferences?  Its interesting to think of the different possibilities!

[::Manageability::]

Javascript gets no respect. Maybe soon it will change? In some ways it's unfortunate that the word "scripting" is used for Javascript and others like Perl, Python, etc. Unlike the others, Javascript knows and deals with Java natively. Perl and Python have to stand on their own with their own libraries.

As for AOP, Javascript based one will be my choice over XML based ones.

7:56:31 AM  #