Languages do evolve. For example:
Pascal => Modula => Oberon C => C++ Java => Generic Java Python => Python 3000 ... etc... Pascal was once so popular that a US president had publicly acknowledged Pascal's importance for his country. Unfortunately, Pascal had some drawbacks, such as ad hoc IO and lack of modules. So Niklaus Wirth designed Modula, a nice language with uniform I/O and modules. Wirth disregarded compatibility: a valid Pascal program was not a valid Modula program. Although Modula - a very good language - gained some popularity, it was a substantial decline in comparison to Pascal' popularity. Because Modula did not have classes, Wirth developed Oberon, a compact and very efficient OO language. Again, Wirth chose incompatible design: a Modula program is not an Oberon program. Now Oberon is so obscure that many on this list might have never heard of it. Bjarne Stroustrup was educated in the Simula tradition and recognized the benefits of objects, so he decided to improve C by adding objects. Most notably, Stroustrup preferred compatible design in his transition from C to C++. Indeed, C programs are C++ programs as well. (In the I/O area in particular, C++ not only preserved C's I/O means, but even added convenient standard I/O idiom for the new I/O objects.) Look at the results of these evolution lines. Incompatible evolution: Pascal (popular) => Modula (less popular) => Oberon (obscure) Compatible evolution: C (popular) => C++ (popular++) One contemporary example: Sun Microsystem's recent extension of Java with genericity was guided first and foremost by the need to provide full compatibility between the two languages. Sun sacrificed language simplicity and orthogonality for full compatibility. Apparently, incompatible language evolution can invalidate the legacy of the evolving language. Unless you are Microsoft, this is difficult to overcome. In contrast, compatible evolution allows the user base of the language a smooth transition to the new language. Now Python is evolving into Python 3000. Will a valid Python program be a valid Python 3000 program? This is important. I think that the thread on the fate of raw_input actually addresses concerns that go way beyond the fate of raw_input. People are concerned because the lack of compatibility will invalidate some Python legacy, at least in the area of using Python as a teaching tool. Even though compatibility in language evolution can be somewhat detrimental to clean language design, it can promote a wider acceptance of the new language. Atanas _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
