So much for science...

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.

The war in... is but a symptom of a far deeper malady within the American spirit

...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.

OO Contracts

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.

Riding Giants

"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.

On the Health of "Offshoring"

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.

GarageBand and the Garage Band Method

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.

Toysight, Eye Toy

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.

An Object Lession: XPathDocument2, Is the 2 Noise or Information?

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!

Blitz is an open source JavaSpaces implementation

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.

Python and groupby

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']

RDBMS: Inherently Loosely Coupled?

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.

AI Never Really Worked At All?

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.

Test Driven Development

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.

Can you learn YAML in five minutes?

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.

Register Allocation

Michael Lucas-Smith calculates the methods that can use register allocation effectively...

I put in italics the methods that would require a spill object. Only 0.37% of methods in the system will spill!. Clearly this indicates that the technique will work even on a system with 8 registers like an x86.

I think that is to some degree optimistic since no registers will be left on the x86 for intermediates.

Data+Algorithms

Keith Ray responds to my recent item on coordination via databases...

As long as databases only store data, and don't store whole objects (data+algorithms), they will always risk disassociating meaning and values.

I understand there is this risk. But the scenario we're comparing to is the distributed messaging paradigm where messages have no algorithms associated and the various end points use different languages. People have decided they don't want the "whole objects" scenario.

I think there is a tremendous benfit to whole objects in either scenario, if good choices are made about the language. The majority has not gone along with that. Ever. Back in the days when CORBA and OODBs were hot topics at OOPSLA, there was a clear message being presented from an aggregated look at the experience reports. Namely, distributed Smalltalk and the Gemstone Smalltalk OODB were relatively easy wins, while distributed CORBA and other OODBs would work OK but were a pain in the ass.

Coordination via Databases

Jay Han responds to my item on using databases for coordination...

We know that databases provide concurrency control and transaction management. These features let applications share data -- you can call this coordination at low level. But what about coordination at high level? How can they exchange semantics of data? e.g. "9999-12-31 in date field means now? never? forever in the future?" or "20 point means 20 basis point." (Schemas and constraints can check syntax of data but not the "validity" of data.) Because I don't see how databases provide meaningful (hence ad-hoc) coordination, I don't quite understand Patrick's last sentence above especially the second half.

Databases have no advantage nor disadvantage in this respect (the "meaning" of data) to any other coordination mechanism.

Edd Dumbill on XML and Databases

Edd Dumbill makes an interesting observation about XML and databases based on submissions to XML Europe 2004...

Databases. Though there's a reasonable amount of interest in the W3C XML Query language, there's not much to say about XML and databases. It doesn't seem to me that the integration of XML with relational databases has taken off in the way we once thought it might. Is this just a temporary lull in the convergence activity? Probably.

BigCo Dynamics

Jon delivers a great sermon on dynamic languages and wraps it up with an observation...

Somebody asked me yesterday why platform vendors like Microsoft and Sun are never at the forefront of dynamic-language innovation. I don't know why that's so, but it does seem to be true.

Sun has been at the forefront in the labs, e.g. the Self language was partially a Sun effort. The Java HotSpot VM is essentially a productization of many dynamic language implementation innovations.

I think an answer to the question above has more to do with the psychology and sociology of programming than it does with anything else. The big companies are almost by definition the ones whose value chain ends with giving the majority what they want. What they want is not always what works good in laboratories, nor is it necessarily what is "best for them".

Looking at language evolution in the long run, especially as plotted against a graph of Moore's Law, clearly the trend is to become more dynamic. A good indicator is a major industry journalist writing about such things.

I don't know what the name will be for the ultimate dynamic language, but it is almost certain to have {curly braces} in the syntax and come from Microsoft. Well, sociology may determine the syntax to have <angle brackets>, but it almost certainly will come from Microsoft. 8^)

We *Have* Magic

Tim Bray on the tripod of objects, messages, and tables...

...for me, this essay brought into focus the fact that anyone who isn’t comfortable with object-oriented design, and with relational data modeling, and with wrangling XML messages; anyone not comfortable with all three, I say, just isn’t fully trained.

Well said, for developing today. But what about tomorrow? When he writes...

Lots of architects have learned, painfully, that you usually can’t magick relational rows away behind object/class abstractions. The right way to think about a database is as a set of normalized tables that are designed to be addressed with SQL strings.

...I can only suggest that we need to upgrade our languages to provide more magic.

Lisp, Smalltalk, and Python come to mind. These are the magic we have for now, but there's more to come if we stay the course. Our databases are still based on early 1980's implementation ideas. Let's keep the good concepts and upgrade the rest. Our messages are struggling with nascent infrastructure and representation issues.

Our languages (i.e. "objects"), our databases, and our messaging are all struggling to become more dynamic. As they do, they will also become more unified, or at least "unify-able".