Modern Dinosaur

Dinosaur in the sense of being terribly outdated, having been tried in the past and having failed. Unfortunately, a vast majority of people are unwilling to know anything about the past, so they keep reinventing squared wheels. So here we have the ModernDinosaurs plenty of them.

Associated with the NotInventedHere syndrome.

The most obvious examples:

HierarchicalDatabases and NetworkDatabases (XML, Object Oriented databases)
UnifiedModelingLanguage ( for those who still have doubts see Klaus-Dieter Schewe: UML: A Modern Dinosaur? - A Critical Analysis of the Unified Modelling Language, http://citeseer.ist.psu.edu/386839.html ) {Does anybody have a reference to an HTML version of this document? PDF and some of the other format choices are rendering poorly for me.}

I would like to point out that Schewe (and, obviously, the author of this page) adheres to a plainly wrong image of dinosaurs as "mentally retarded, mighty rulers oppressing for a long time the development of higher developed forms of life such as birds and mammals". That old prejudice isn't supported by paleontologists any more. There is no reason to think that they where "retarded". The very fact that they dominated their environment for so many million years shows that they were as intelligent and effective as necessary, and if they were able to "oppress" (a meaningless term when referring to biological evolution) mammals it is exactly because mammals where not intelligent and efficient enough to beat them. I recommend StephenJayGould, of course.

Thinkest thou that we should merge this with yon ZombieTechnologies list?

Well, not quite. First of all that somebody wrongly put relational databases on the ZombieTechnologies. If I add object databases in there we're left without any database at all that justifies its existence.Putting relational databases on the list of zombie technologies is only justified by the fact that they have been in use for a long time (or have they ? ), but with this kind of argument we can also put Euclidean Geometry on the list of zombies, and it's just not right. We have to admit that some human knowledge is fundamentally good and consistent and will stay with us even for centuries.

Second,the motivation given for Zombies is that they have been continuing to exist, despite advances in technologies for various reasons. Dinosaur are things that have been forgotten and re-invented in another shape, hence what I call the reinvention of a squared wheel as opposed to the reinvention of a wheel - which is not good but not bad either.

XML is a new and cool thing. In fact it is a resurected dinosaur (hierarchical data model).UML is also new and cool, and it's also a reinvented square wheel.

At least that's the sense I wanted to give to ModernDinosaur, maybe the syntagm is not the best one, but at least it is used by somebody else before me with the same meaning.

This list is bogus. Both of the things on this list work. They don't work all the time, everywhere, but then nothing does. Instead of just insulting them, perhaps you should describe the weaknesses in them, and then perhaps we could figure out when we should use them and when we should not use them. But just making lists like this is a waste of time.

By the way, just because something is a recycled idea that failed in the past doesn't make it a dinosaur. Generally it takes many attempts to make an idea work. Also, the time might not have been right for it the first time, but perhaps it will be this time. The question is whether it works now, not whether it failed in the past.

The automobile was an early 19th century invention that didn't really start to work until the late 19th century, mostly because of problems with the road systems of the early 19th century.

It is ironic that OODBMS are a lot like hierarchical databases, and are trying to supplant RDBMSs, which supplanted hierarchical databases. But this does not tell us much about which is better.

-RalphJohnson

Well, this list is a point of view. The fact that a thing works doesn't give it a title of glory over other things. IMS did work and still does, COBOL programs did work and some still do. Still new development efforts with either COBOL or IMS are almost non-existent. Is this for a good reason, or just because of industry fads ?

If you still have doubts which model (hierarchical or relational) is better, and more important, based on what criteria, I think that AnIntroductionToDatabaseSystems will do. So the question is whether it works now. But what did fundamentally change from the past ? What were the weaknesses from the past that are covered now by the revamped products (alas we don't have a revamped theoretical foundation behind the products).

Lots of old ramblings moved to ModernDinosaurDiscussion.

UML is a special thing in the list at least because not a database. It is supposed to be on a higher level, a modeling language, even an unified one. Unfortunately it looks like it doesn't have a model behind it, at least not a theoretical one, and not even a simpe one that you can read in the UML specification. I think the paper that I linked to is pretty concludent, I could add some links on this site, and the opinion of others . But I could also quote directly from UML:

The Unified Modeling Language (UML) is a language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems. The UML represents a collection of the best engineering practices that have proven successful in the modeling of large and complex systems. [UML 1.3 specification available at www.omg.org]

So, why is it called modeling language then, where is the model ? Where's the unification ? I'm sure you know that what is being unified is three separate pre-existing methodologies - those of Booch, Jacobson, and Rumbaugh. It has much less to do with OOPL commonalities. What are the commonalities from the object models of Java, Smalltalk, C++, Ada, Delphi, Visual Basic (to name but a few of OO languages in relevant use today and in use long before 1999 when the actual), how they were unified in a single model ? These questions are only rhetoric, unfortunately. By the way, why is it called UML instead of Object UML, since function is not a first class concept , relation is not a concept at all. It's just marketing chaff starting from the name.

But just making lists like this is a waste of time.

That's a valid point. The list was just a set of examples. People might disagree with the presence of various items on the list. However one can hardly argue with the validity of the term itself (I first saw it in the cited paper on UML and I said to myself: Wow, that's a very good one). ModernDinosaurs are among us whether we like it or not, whether we might sympathize with some of the dinosaurs or not.

What would qualify a technology as a ModernDinosaur?

First it would have to be something reinvented. It has to be a reinvention of something that failed in the past.
Second, the ModernDinosaur will not address the issues that made the previous thing fail. If it did, it will no longer be a dinosaur.
(Optional ) Most often is a reinvention without any aknowledgement. Sometimes the ingratitude to its ancestors comes from ignorance, the new inventors simply did not know that somebody thought of the same issues before them. Other times they do know, but they don't want to acknowledge the past, because of marketing reasons. The previous thing that failed just ruined its name. Hierarchical model's failure in term of public image is much larger than in terms of technical issues, so nobody is likely to come forward and say: I have a new idea based on the hierarchical model. The divorce with the past of ModernDinosaurs usually makes matter worse, they are likely to repeat the errors of the past and they are likely to at least double the effort in reinventing what the previous product had good.

The things from the list arguably qualify under the first and second clause.

Where is the value in putting them on such a list ?

Well, most of the people in SoftwareDevelopment are not aware of the previous dinosaur. It's just a simple matter of knowledge: it shall be known that this thing has been previously tried and failed. We should then investigate what the new invention brings new, how does it deal with the flaws from the past, and make informed decisions on whether and how to use each of them.

For example I was aware of many things that were wrong with UML. I always thought that UML would ventually become a dinosaur. The fact that I now know that UML is in fact a ModernDinosaur (and what was the previous dinosaur) did help me in understanding UML better.

I know of two specific criticisms leveled against "network databases" (NDBMS). First, the query languages for them have been hard to learn and seemingly long-winded compared to relational query languages (such as SQL, which is not the best possible relational language IMO). OODB query languages have suffered similar criticisms (http://www.byte.com/art/9710/sec6/art6.htm).

GemStone allows SQL access to its persistent objects in both its Smalltalk and Java product lines. Next?

{Are you suggesting that GemStone allows the same information to be simultaneously and efficiently accessed from a relational, networked, and hierarchical perspective? Quite a feat if true.}

The second criticism is that relationships have to be explicitly planned for in advance. In relational the relationships tend to be virtual (physical indexes are for speed purposes and in theory do not affect the interface to data), while in NDBMS you pretty much had to specify links or indexes in advanced of using them. IOW, it is harder to have "calculated links".

So, how are foreign keys different? Somehow you don't have to plan for them in advance?

{The user of the info does not have to worry about how the foreign key got populated. Besides you can still create CalculatedRelations that are not based on explicit foreign keys. For example, cross-reference a search result set based on a sub-string search in a title field to something else to research possible name connections.}

The very name "hierarchical database" suggests similar criticism for them also: They are hard-wired to a "tree" relationship. Relational philosophy would tend view a tree simply as *one of many* possible (simultaneous) relationships. IOW, a "tree" is a view, and not a physical structure nor a database in itself.

I see. So the "tree" view in Oracle doesn't start from ALL_TABLES? Why not? In GemStone the analog to ALL_TABLES is a persistent JNDI node. There's nothing to stop you from binding separate Maps per persistent class, keyed by primary identifier, holding all instances of that persistent class, and letting the instances refer to each other not by object pointer but by foreign key. That would make it pretty analogous to relational tables. But in practice what makes the most sense is to only bind registries of those objects that need to be independently findable. All other objects are reached by object pointer navigation from aggregate roots. Yes that means you need an initial understanding of anticipated access patterns, but that hardly represents a "failure". It never caused any of my projects to fail.

{The "out of style" database paradigms of the 1960's also did not cause outright failure. They just had more complex query languages and lacked CalculatedRelations. Lack of these is not a show-stopper, just like writing your app in COBOL is not a show-stopper. From your discription, it seems that the application developer has to manually arrange stuff that a RelationalDatabase would normally take care of out-of-the-box, or at least remove or reduce from the concern of the app developer. Relational query languages tend to ask for what you want, and not how to get it. (Imperitive-vs-Declarative link anyone?)}

On another note, it is understandable to experiment with new manifestations of old technology, but shouldn't they be withheld from mainstream until the kinks are worked out? IOW, if we know that similar technologies failed in the past, then new incarnations should be well tested by *volunteer* organizations before going mainstream it would seem. Or perhaps one can argue that the only way to truly road-test a technology is to have it be mainstream for a while. This may perhaps be true, but it is kind of disappointing because it means that developers and organizations are guinea pigs whether they want to be or not.

"Be withheld" ... "should be well tested by *volunteer* organizations". That's wishful utopian thinking. We'll always be guinea pigs. The winners leverage innovation to increase value (e.g., productivity) without overly increasing risk.

{Yes, but we don't know the winners until it is too late to do anything about the non-winners. Perhaps technology should be presented like stocks: high risk and low risk. There have been a lot of failed ideas on the way, or at least ideas that did not live up to their billing but find useful niches. CASE and Expert Systems come to mind. If an organization invested heavily in Expert Systems when they were big, they probably later regretted it.}