It seems that all too often someone comes up with a new and improved tool to solve the crisis of the day, when in fact it's the same crisis everyone has been dealing with for years and a plethora of existing tools to choose from already exists. The current crisis of the day is developing a software application that is network aware, database connected, web serviceenabled, and any other advanced feature that clients, customers, and management alike need for the next generation of software applications.
So, why create a new language? After all, there are so many languages out there to choose from; surely one of them would suffice to do the job. We have Visual Basic for high-level abstraction and C++ for expressiveness and raw power. Although these languages are great and fill a vital role, the real need for a new language is not so much the language itself, but the idea behind a new platform for software development in general.
In the same way that some people like the city life but others prefer the quiet countryside, the choice of languages is also a personal preference. Of course, language wars are often debates over language semantics, the expressive power and performance versus ease of use and high-level constructs such as object-oriented features. However, one thing has always remained constant: the need to reach the Holy Grail of software engineering, code reuse. Or, better yet, component-based development. The ability to create a component and use it in a software application that is written in another programming language is what developers have been searching for. Many attempts and standards have been created to address this very issue. This includes CORBA, COM, DCOM, Win32 libraries, and so on. However, each solution has had a single unavoidable roadblock: a common type system that unifies all languages and allows them to pass information back and forth in a consistent well-defined format.