Back to politics: the Bush administration wishes to replace this time-tested, widely respected process of evaluating scientific research and proposals for funding of research, with a process that places control in the hands, not of experts in the field in which the research is pursued, but of the White House and the OMB...

The administration says that policy should be based on scientific truths so well-established as to be beyond question. But there is no scientific truth beyond question; that is the very nature of science. This is not about basing policy on better science; this is about interfering with the decision of what constitutes good science... to the financial advantage of various industries that contribute to Bush's campaign, and to the political advantage of the Bush administration as they throw a bone to their religious "conservative" (read: radical fundamentalist) supporters.  ¶ 12:27 PM

...communism is a judgment against our failure to make democracy real and follow through on the revolutions that we initiated

Ian Bicking has a commemoration of MLK, Jr. and he chose to quote from one of his last speeches.

What a beautiful choice. The mainstream media tends to choose quotes and clips from many years earlier when his focus was still primarily civil rights for African Americans.

King was beginning to shine the Light on society's even greater ills. These are neither as obvious nor as easy to resolve as were civil rights. And so they're still with us and he was assassinated not long after this speech.

"Why are you speaking about the war, Dr. King? Why are you joining the voices of dissent?" "Peace and civil rights don't mix," they say. "Aren't you hurting the cause of your people?" they ask. And when I hear them, though I often understand the source of their concern, I am nevertheless greatly saddened, for such questions mean that the inquirers have not really known me, my commitment, or my calling. Indeed, their questions suggest that they do not know the world in which they live. In the light of such tragic misunderstanding, I deem it of signal importance to try to state clearly, and I trust concisely, why I believe that the path from Dexter Avenue Baptist Church -- the church in Montgomery, Alabama, where I began my pastorate -- leads clearly to this sanctuary tonight.

  ¶ 7:17 AM

This financial contracts specification would make an interesting Smalltalk library. The original claim was that a functional language should be used because combinators, unlike objects, can be easily composed.

But combinators are as easy to build with objects as they are with functions.   ¶ 6:48 AM

"Dogtown" was such a good documentary, I'm a definite for "Riding Giants" when it arrives in a theater near me.

I was skateboarding in the same era as the Z-Boys. Unfortunately I was in Ohio. Our biggest stunt was to make it down a long hill on a sidewalk that ended in small gravel, or grass if you could steer well enough to get to the grass.

More than a few times we'd recover from rides by plucking out very small rocks deeply embedded in the calluses of the palms of our hands. These were the bonding moments for young adolescents, and so I guess that's why they're the things I remember.  ¶ 12:21 AM

Google is opening a Bangalore engineering office...

The office will operate in an identical manner to our other engineering groups, with the same scope of work, hiring standards and unique Google culture.

I wonder if they'll offer the same health and insurance benefits.   ¶ 11:17 PM

GarageBand from Apple gets a references from Jon Udell on turning "consumers" into producers.... this might be a good time to plug "The Garage Band Method". Unfortunately the book appears to be unavailable from Amazon as well as Powells.

I'll have to cherish my copy even more. The Garage Band Method is a no nonsense approach to making *interesting* music quickly while learning piano, guitar, or sax. (Moreover, all three are covered in the one book.) The method is not "learn on your own". You're expected to have a teacher, but the book tells you what to look for in a teacher and how to work with one. The other key point is to get with other people who want to play and may also be beginners in their instrument.   ¶ 10:32 PM

The Toysight for iSight for the Mac seems kind of like the PS2 Eye Toy, but I don't know the details for either. My 11 year old got the Eye Toy for Christmas.

It's a lot of fun and even more potential than realized so far.   ¶ 10:17 PM

Objects are for communication. A key to good design is to choose good names. This Longhorn class should be renamed now: System.Xml.XPathDocument2 to set an example.

What does the name XPathDocument2 tell me, the reader? Well, it basically tells me there is an XPathDocument (or maybe an XPathDocument1 and perhaps an XPathDocument3).

It also suggest that the 2 class was developed some time *after* the first one. It might tell me not to use the first one. I don't know. The 2 is noise that wants to be information.

A better name would tell me that XPathDocument2 can be disconnected from the source, not tied to a DOM, and used for read/write, and provides change notifications. The numeral 2 cannot tell me that. Neither does it tell me that the original DOM-bound XPathDocument still may be a good choice in some scenarios.

I don't know exactly what the better name is, but it is out there in the conversations that led to its creation, and (unfortunately) in the conversations that will take place among its consumers. Maybe ReadWriteXPathDocument is a good choice, but only real conversations (as opposed to the ones going on in my head right now) will tell.

This post has nothing to do with XML and XPath or Longhorn. It has everything to do with why objects are important and will remain useful for their original purpose: code organization. Good names are a key to good organization.

Well, this post *does* have something to do with Longhorn... the developers at Microsoft are creating now the language many developers will use for probably a decade. Please take the time to provide meaningful names. Two years before the release date is *not* the time to affix numerals to the end of classes for relatives that provide alternate functionality!   ¶ 9:57 AM

Freshmeat...

Blitz is an open source JavaSpaces implementation designed to ease development and deployment of JavaSpaces technology. It is Jini 2.0 enabled, and uses established VM principles. It also implements smart indexing, tuneable persistence, and active/passive lease cleanup. It is designed with experimentation and expansion in mind.   ¶ 11:20 PM

For Python's list comprehensions comes groupby...

Guido inspired SQL-like GROUPBY class that also encapsulates the logic in a Unix-like "sort | uniq".

class groupby(dict):
    def __init__(self, seq, key=lambda x:x):
        for value in seq:
            k = key(value)
            self.setdefault(k, []).append(value)
    __iter__ = dict.iteritems

# -------------------------- Examples -----------------------------------

>>> letters = 'abracadabra'
>>> [g for k, g in groupby(letters)]                # grouped
[['a', 'a', 'a', 'a', 'a'], ['r', 'r'], ['b', 'b'], ['c'], ['d']]
>>> [k for k, g in groupby(letters)]                # uniq
['a', 'r', 'b', 'c', 'd']
>>> [(k, len(g)) for k, g in groupby(letters)]      # uniq -c
[('a', 5), ('r', 2), ('b', 2), ('c', 1), ('d', 1)]
>>> [k for k, g in groupby(letters) if len(g) > 1]  # uniq -d
['a', 'r', 'b']

Carlos Perez writes...

In general, a relational database provides a fixed, queried, self-describing, lazy evaluated system that is inherently loosely coupled. It's surprising that its perceived to be more tightly coupled than a component based system.

I agree 100 percent with this statement. I think the current popular SQL databases are archaic for a number of reasons, yet they are a mechanism for loose coupling. What's more, they are widely understood by developers. An unfortunate aspect of relational databases is there is typically so much ceremony involved in putting one into production. There is a time and place for ceremony, and likewise for agility. We should be practicing agility with databases, and vendors should be listening for ways to improve them.   ¶ 12:07 PM

AI never really worked at all, says Tim Bray in his latest installment in an interesting technology winners and losers assessment. I'm enjoying this series so far, but the AI line item struck me funny.

First of all, looking at this list, some of these technologies are very specific, such as Unix/C and SQL/RDBMS. But "AI" is a broad, 40-year-and-continuing, label for several families of hard computational problems. How can these be compared in terms of "hard to build"?

Digging into various AI categories, clearly some have been very successful, such as expert systems, and various forms of search and planning. Other categories of AI research have been "successful" in terms of learning exactly what the problems are in that category. Not all successful research results in working products.  ¶ 6:52 AM

Jarno Virtanen writes...

My personal gripe about test-driven development is the complete lack of the so-called white box testing methods. In white box testing, you use the source code in order to create test cases that cover the whole functionality of the testable unit. I would go so far as to claim that the trickiest bugs are in the edge- and corner-cases of the code which you can reveal with white box testing. But, of course, tests in advance of coding are better than no tests at all. (I am too often guilty of writing no tests at all.)

I think it is important to emphasize that test-driven design does not imply that the tests you write toward a design are not necessarily the only tests you should write to get to a production quality release. The TDD tests should be just enough to get to a satisfactory design. Depending on the system being constructed, you should still consider acceptance tests, including performance tests and more complete suites for functional coverage than were needed just for the design process.   ¶ 10:35 PM

Can you learn YAML in five minutes? I did.

Then I read through a lot of the YAML articles, web, and spec this weekend. I was kind of aware of YAML some time ago, but this was my first in-depth look.

YAML appears to be just popular enough to have a future, but of course XML is a juggernaut.

I like that YAML maps to simple data structures found in essentially all modern languages. There is no separate "DOM". YAML also appears to have a good set of base data types with extensibility. On top of all this, the syntax is significantly simpler and more human readable, which also means it can be hand edited more readily.

YAML might make a good syntax for a build system, as opposed to ANT. It would also be a good candidate for "preference" files and other text documents that people read and write by hand, but also process with applications.

There is a simple mapping between YAML and a subset of XML. YAML is a good deal more compact than XML, although I wonder of that would significantly reduce the benefits of HTTP compression on large files. Depends on the markup to content ratio I guess.  ¶ 10:28 PM