Fire Trucks and Databases

The Hawaii state fire department is having trouble figuring out how to automate their building inspection database. They have now spent a half million dollars on contractors for two failed systems in a row, and so far the most promising solution is an internally-developed hack job that at least tracks the right information, even if it's not centralized.

I've got this funny feeling there's a market for turn-key centralized database systems which develop as if they were MS Access or something. The trade-off I see with big-iron databases is that you have to create your interfaces from first principles: C++ or PHP or the like.

PC database systems were a big hit largely because they made forms-based applications simple. Nobody wants to type a bunch of SQL to manage their vinyl album collection or recipe book. Instead, you created your database and its CRUD screens in a simple interface.

There are now plenty of frameworks (such as RAILS) that take care of lots of the work involved in delivering database applications on the web. However, they still require command-line voodoo to operate, and they still are only as safe as the guy writing the code underneath. They can't make your schema for you, and most times they won't even try to help with that part. Instead, you get to use some other tool to construct the underlying database, and then wrap that with the interface builder of choice.

The paradigm was right twenty years ago. Database systems should be developed at the level of use. If you need a list of checkboxes, then that's what you need. It should be the development tool's responsibility to turn that requirement into a database schema, and also to generate and manage suitable query screens that stay correct and operational regardless of what happens to the schema.

To make this work, the development tool needs to understand the semantic connections between different features and facets of the end user system. A really smart group of people would have to study successful database-driven applications to figure out what really binds such tools together. Then, they would have to wrap that whole bundle of knowledge into an automatic intelligent tool.

The real value, though, is in the uber-tool that automates the creation of intelligent development tools such as the one described above.

A little about Haskell, including why it is so weird:

Haskell tries to be object oriented and functional at the same time. In a sense, it succeeds. Haskell functions are inherently generic, so that you can, for instance, sum a list of anything that you can add two of.

Haskell lets you define vocabularies, but it calls those vocabularies "Classes", if I recall correctly. The idea is that a subclass responds to all the same operations as its superclass, and then some. Using an operation constrains its operand to the classes for which that operation has meaning.

To put it another way, the nouns of Haskell are the data type definitions and their corresponding constructors. The verbs are the functions that apply to those nouns, and the semantics are the interplay of function, domain, and range.

I personally believe that Haskell suffers greatly from (at least) two major flaws.

First of all, the terms Haskell uses to describe different parts of its language are kind of strange in comparison to other languages. What Haskell calls a class most closely resembles an interface in Java, an abstract base in C++, or an abstract data type in computer-science-speak. There is a mainstream idea of what a class is, embodied in C++, Java, Smalltalk, and even some variants of Pascal: a member of a forest (or, in C++, DAG) of record types annotated with polymorphic methods. Haskell's classes are dramatically different from that norm.

Second, Haskell's monads are just too hard to explain. In theory, the monad is a wonderful idea. Unfortunately, monads are like a golden hammer for the woes of pure lazy functional programming. Monads are how anything gets done in Haskell, because they structure interactions with the world into sequential computations. Without them, it would be impossible to write a Haskell program that did anything observable. However, they represent a significant conceptual hurdle for the newcomer, and one that other languages don't have. Much more ink has been spent ranting and raving about how great monads are than explaining how and when to use them.