Tower Of Babel

Tower of Babel, \Tow"er Of Ba"bel\

n. , 1. Biblical tower in the land of Shinar, where the confusion of languages took place. 2. Hence: A place or scene of noise and confusion; a confused mixture of sounds, as of voices or languages. 3. Any large software project with poor management and communication. 4. Any software project employing multiple implementation languages [4]. 5. A software project that solves problems via the Unix philosophy of linking many small, existing, domain specific tools together, rather than producing a complete, monolithic, monumental pile of code that will become historically notorious for its failure.

[4] In other words, every software project.

Some people think that supporting many different languages is a really good thing... e.g. that each OperatingSystems should be broken and shattered TowerOfBabel, with noisy, confusing, 'hacked'-together solutions. I'm of a different opinion. The TowerOfBabel was a work of man with its very own StairwayToHeaven?. There would be some rather significant advantages for a SingleLanguageOperatingSystem (where the LanguageIsAnOs and designed for it)... e.g. a completely integrated typing system for both volatile and persistent data, data being equally accessible to all consumers (possibly in mini Databases as per ExBase or PrologLanguage), a wholly integrated CapabilitySecurityModel, etc.. A language also designed for distributed systems would simply become (or easily allow for) a distributed OperatingSystem. The runtime and the compile-time would be one fully IntegratedEnvironment?. Optimizations can apply not only across abstraction layers, but across process-layers, reducing validation costs and improving throughput... so long as the environment tracks what to recompile in the event a component changes.

It is sometimes said that SmalltalkLanguage is currently the closest to this TowerOfBabel concept. It just runs too slowly for production systems. Some of the Lisp machines and Emacs may also come close. Interpreters also come close (e.g. irb).

Since DomainSpecificLanguages are often appropriate, it would be perfectly reasonable to choose a 'Single Language' capable of powerful macro support or syntax extension.

According to the biblical account, a united humanity of the generations following the Great Flood, speaking a single language and migrating from the east, came to the land of Shinar, where they resolved to build a city with a tower "with its top in the heavens...lest we be scattered abroad upon the face of the Earth." God came down to see what they did and said: "They are one people and have one language, and nothing will be with holden from them which they purpose to do." So God said, "Come, let us go down and confound their speech." And so God scattered them upon the face of the Earth, and confused their languages, and they left off building the city, which was called Babel "because God there confounded the language of all the Earth."

Is the hebrew history of the TowerOfBabel the first example of the failure that kills a project, when the team fails to keep a good SystemMetaphor and UbiquitousLanguage? And maybe it is also an example of the how the combinatorial explosion of team communication paths can easily kill a big project?

If you think it, there is no need for God angels to "go down and confound our speech", we are pretty good in doing that, all by ourselves (one just has to look at pretty much any software project so know it is true). Now imagine the coordination effort of building a huge tower a few thousand years ago... now-days it seems like a simple endeavor that a single (if very big) construction company can do, but back then, I bet the team coordination problems inside such a project just killed it, (and without the modern knowledge on team dynamics) they just thought that it as "confusion created by the angels of God"