All this brouhaha about the state Texas and it's proposed textbook standards doesn't concern me much because I think textbooks and universities for that matter are soon to be things of the past. The internet is making the need to go somewhere to learn something nonexistent. More and more people will be learning more and more things informally and for free. The level of literacy of the world population is rising and will continue to rise more rapidly.

One need, however, that universities fulfill that is not so obviously provided by the internet as it is today is the certification of education. The letters you get to put after your name after you put in your years, take your tests, write your theses. There's a lot of infrastructure behind those letters, including state textbook standards. However that infrastructure is going to have to change as education migrates to the internet. The internet is making education much more accessible and fluid and cheap and I suspect much of the certification infrastructure is based on the costliness of education. Ultimately it comes down to "who do you trust", and the trust structures of the internet are still being developed.

Test post

This is a test post to see how following works.

Technology is continuing to come up with things that are impossible to make money at. Scarcity is slowly being abolished. It seems one of the core aspects of the singularity is the general dismantling of the money-based economy we've become so used to.

First there was the internet, now there's this.

In the aggregation of all the code I write, some of it HAS to be correct and some of it, not so much so. Actually it's more of a spectrum from super mission critical to meh, who cares. Given the degree to which computers are working their way into everything we do, I'm sure that there is code out there now, the correctness of which has life or death consequences.

That's why I consider strongly typed compiled languages to be important. I want to be able to guarantee correctness at compile time, as much as is possible, for these types of applications. Yes, of course there's unit testing, or coverage testing, the idea being to cover as much of the use cases as possible, and there are strong arguments for testing before you write anything, but I consider that to be a back up to compiler verification. Unit testing can't possibly cover every scenario.

Suppose you, as a programmer, were held liable for what your software did. Could you possibly find a way to write any more code? Would your calling in life be at an end? If tomorrow, congress passed legislation making programmers liable, I believe we would find a way and that way would be through strong compilers, unit tests, and digital signatures, all of which we would be prepared to take to court.

Another thought about compiler null checking: A method signature is a contract between the method provider and the method consumer, but it doesn't say anything about nulls. If the method provider and method consumer have no other means of communication, they both have to check for nulls. The consumer should make sure the method arguments are not null before calling the method and the provider has to check for nulls before using them since neither of them can trust the other. Of course the provider can just say that a NullPointerException is going to be thrown should the consumer be so stupid as to pass a null, and that's what is often done. But that is a run-time bug just waiting to hide in the bushes, avoiding unit tests and the QA tests and the UA tests, and spring out years down the road, when the software is in production and the development staff is long gone. No, I think what's really needed is for the Java language to add the NOTNULL qualifier to method arguments and enforce it. The compiler can know whether an argument could be null.

An interface in java is a contract, but it's a rather shallow contract. All it guarantees is that certain methods with certain signatures will be available. What these methods do when you call them is not covered by the contract.

It would be possible to have a protocol that provides a richer contract. One that can guarantee behavior. To do this one would need to employ digital signatures. You'd have a signature that is applied to a certain method implementation, which is perhaps open source, but at least trusted to behave in a certain way. When you instantiate the implementing class, you pass a set of signatures which are checked against the various method implementations. The class will only instantiate if all the signatures match. Furthermore, this check can be made at compile-time.

Signatures could apply to methods of other interfaces as well, not just the one being instantiated. This would mean that if method m of interface i were called during the course of executing any method of the instance, the signature would be checked. This has a couple of drawbacks. 1) it has to be a run-time check, and 2) there's no guarantee the method would be called. The only guarantee is that IF the method is called it will behave in a certain way.

Guaranteeing behavior on a deep level gets to be more complicated. It gets to the heart of the problem of fulfilling human expectations, which is fraught with difficulties.

AMI's data structure

Although AMI internally uses postgresql to store its data, the way it organizes its data is much more similar to Amazon S3. Simply stated, it's a data space consisting of nodes. Each node has a unique ID and can have any number of named attributes. Attribute names are universally defined, so if you have an attribute named "foo" attached to node 123, it will have the same characteristics as another attribute named "foo" attached to node 456.

Associated with each attribute name is a type. Attribute types are defined in AMI by java classes that implement a common interface. The interface defines a mechanism for serializing and deserializing the attribute data so it can be stored and retrieved. It also defines mechanisms for searching for attribute values.

AMI defines the usual collection of primitive types such as string, boolean integer. It also defines some more specialized types such as timestamp, and some collection types such as SetOfTimestamp, and a reference type that allows one node to refer to another. This last type provides a lot of power and flexibility to the data structure.

Let's take the RSS reader daemon as an example. This daemon is defined by a node that has the "handler" attribute that contains the name of a java class that implements the Daemon interface. AMI automatically starts a thread for the daemon which periodically checks an RSS feed. The details of how and when the daemon is started, which URL to check, etc. are contained in the nodes attributes. AMI users are also defined by nodes. Any given user can subscribe to the RSS feed by creating a subscription node that links the user node to the RSS daemon node via a couple of reference type attributes. This provides a many-to-many linkage between daemons and users.

As the RSS daemon reads the feed and finds new items, it creates nodes to contain them. Many of the XML attributes associated with an item translate directly into node attributes in AMI. If any kind of error occurs during the process, AMI creates a log node and links it to the daemon node.

In summary, this data structure provides a great deal of power and flexibility and can be used for just about any kind of application. It does require more processing at run-time than a traditional SQL database, but it is more dynamic, more alive, more suited to collaborative applications and artificial intelligence.