June 2000

Corba, XML and ODBC Suck

This document is a rant about the monkeys in the computer standards committees. Their unthoughtful designs are just adding to the pile of BS (often proprietary) junk standards.

CORBA SUCKS!

CORBA sucks when connecting any two NEW applications together. Making two incompatible applications in the first place is stupid.

CORBA is only good for connecting to legacy applications. Since everyone I have spoken to does not know what I mean by "legacy", I will explain: The CORBA interface only needs to be made when writing new applications for any application/platform that exists already. If the legacy app exists, and it does not use CORBA, you have to make a CORBA interface for it.

If you use CORBA, despite my warnings, at the very most you have slow communication. CORBA is only supposed to be used at the application level. It is not to be used for making anything used in O(n^2), or greater, amounts.

So is the problem so bad? The committee chimps made yet another inadequate patch to the incompatibility problem. What should have been done is made set of language -> communication programs that read source code and provide you with a CORBA-like communication program. Essentially encapsulating the CORBA spec into conversion applications. You can see this done with the Java->CORBA object interface definition, but it is not part of CORBA, it is a solution to CORBA's problems.

XML SUCKS!

The monkeys responsible for the XML standard have managed to specify a data format without specifying a useful data format. Sure, you can store ints, strings and records in a standard method, but the intent, the meaning, of these structures is not encoded. If I wanted to store a DAG (directed acyclic graph) in XML, the receiving XML parser would not know it is receiving a DAG. If I store colour="yellow", width=4, height=4, am a I storing button info? or a cell in a spreadsheet? The primitive structures stored by XML are a small step in the right direction, but the step is so small we will take forever to get where we are going.

With XML we now have standardized BLOAT. The format for telephony files was very simple to parse. With XML I would not have to parse bytes into strings, or bytes into integers. But now I have to contend with a file size 10 times larger. XML does NOT save me from having to parse the files in context of a telephone call or billing detail. I saved myself a couple hours of work with XML so I could process 10 CDs of call details, instead of 1, every month.

XML should be encapsulated in an application. Very much like the Excel's text->columns interface: Specify the data format and it makes the parsing app. GREAT! Now we have efficiency, backwards compatibility and interopability with less work than those DAMNED DDL scripts!

XML could have been made useful by specifying the format for common data structures and objects. Things like form objects and ADTs. At least the context of those strings and integers will be processed for you.

ODBC SUCKS!

ODBC has got the take the cake. If there was ever a batch of chimps at work, this is what they would produce. ODBC solves NOTHING. First RPC is already done, and the second is subtle: SQL has got to be the worst adhered "standard" in all the universe. Every DB vendor has their own incompatible "optimizations". This is to be expected; embrace and extend is what business do. But the ODBC chimps had to make sure that this incompatibility extended across the ODBC link. They just carry the SQL from the client to the DB backend for parsing. You might as well use a telnet library to a DB session!

ODBC should have encapsulated the concept of a query in a standard data structure. This standard structure would be sent to the DB backend where it is interpreted into any particular proprietary format. ODBC would then be a standard method of communicating with a DB. Instead, unfortunately, you must make separate libraries for each type of DB.

Reformatted for web April 2002

Written long ago