The Case of Types versus Generics
One of the most compassionate discussions between computer geeks is about the controversy between type-safe languages and generic languages. The type safe advocates demand lots of extra information so that the tools can check the validity of the program. The generic guys want the code to be as simple and small as possible so that it is easy to understand.
Now my position is chicken: it depends.
I love the generic languages like Smalltalk, Ruby, Javascript, Python, and others for their flexibility, readability, and productivity. I regularly detest Java when I am forced to use (or read) An inner-class where the type cruft effectively camouflages the real code. For me, the generic languages are the wild and young girls, while the type safe languages are the old and stuffy bookkeepers. However, working with Eclipse for some time now, I must admit that bookkeepers speed up the development significantly (just wish they could detect Null Pointer Exceptions during compile!).
All this is moot for me because Java is my language (And after enduring many years of C++ teaching Java was actually heaven once). However, also in Java there are cases where you would like to work generically. A point in case is the control of a vehicle. A vehicle consists of hundreds of actuators and sensors connected over several networks. Interacting with such a network can be done in many different ways.
On one side of the spectrum there is the fanatical type-safe approach where each entity on the network is modeled as a specific class. A screen wiper will get a ScreenWiper class and the left front dim light will get a LeftFrontDimLight class. The disadvantages of the model are obvious: you get thousands of classes. Managing, or using, those classes is a maintenance nightmare; think of versioning this. It can be done (I once saw a system that had 3000 such classes). Worse, the clients of these classes will be overwhelmed with all these classes. Due to the type safety, they usually have to write similar, but slightly different, code. This redundancy tempts the programmer to creating the mother of all bad software: copy-paste-paste-paste-paste-paste-paste software.
The other side of the spectrum is the use of meta-information to guide the programmer. The meta-information allows the programmer to navigate through the myriad of devices without requiring that the navigation knowledge is embedded in the program. This enables small, generic applications. Dedicated applications are also enabled by assuming the navigational structure in the software. Applications could even be code-generated from the meta information.
The OSGi Specifications play it both ways. The OSGi service model is clearly going the type safe route using Java interfaces. However, the Dmt Admin service, based on OMA DM concepts, provides a way to look at the system that takes the generic route. Dmt Admin models the world in a tree, where the leaf nodes hold simple values like integers, dates, times, floats, strings, xmls, or binaries. Nodes are addressed with a URI like: ./OSGi/bundles/101/Location. Client code only sees the tree, it never is confronted with Configuration, Monitorable, Bundle, or other objects. The tree defines a containment hierarchy. Each node is associated with a meta node that provides additional information about the usage. Can such nodes be added, deleted, replaced, gotten? What are the possible value ranges? This meta information is extremely useful in building GUIs that are flexible and adaptive, thereby having the potential to significantly reduce application specific code.
There is obviously a trade off. Using a problem specific class is easier to use than a generic tree. However, when the number of classes become very high, the less-programmer friendly version of generic access becomes more suitable. The choice is up to you!
I have been struggling with this dichotomy for ages. If you have something to teach me, let me know.
posted by Peter @ Thursday, November 24, 2005
