Roughly speaking there are two kinds of programs these days. I will call them hard and soft here. I will grant at the beginning that I like hard programs but also admit that soft programs are necessary for my life style. I may never write a good soft program.

Hard programs adapt some one or a few algorithms which are at the root of the solution of some problem. Soft programs deal in ill-structured data by applying heuristics. Hard programs may come with crisp specifications and criteria for successful answers. Hard programs can often be said to be correct. Soft programs can be clearly wrong, but never clearly right. Soft programs often have GUI’s and are many megabytes in size. More often hard programs are small. Soft programs often have hard components. Google search is a soft program with many hard components. A compiler is a large hard program.

Fuzzy Input

Soft programs take imprecisely formatted data as input. Not only is the input ill-structured, but is without clear semantics. The meaning of XML data seems largely to be conveyed by connotations of the words between the “<” and the “>”. Yes I know about DTDs and they say more. Programs that make sense of XML data usually ascribe some precise semantics to a given XML document, but it may be difficult to learn what this is. The power of XML, I suppose, is that approximate agreement on semantics between producer and consumer often leads to useful behavior of a program. This seems plausible but I wish I saw more concrete successes.

This fuzzy data is the opposite of abstraction, which aims to limit a form of data to a fixed piece of code. I like abstraction as it lets you know for sure, at some low level at least, what the data means.

XML also flies in the face of data base designers who insist on vetting data before it gets into a data base to better ensure that the data’s meaning suits the uses of the data base.