Compatibility and legacy in language evolution
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
Op za, 09-09-2006 te 13:49 -0700, schreef Radenski, Atanas:
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.
That's not true and mr. Stroustrups own books explain how and why; even basic C programs might be invalid as C++ programs (or they work different in C than in C++, which is even worse). -- Jan Claeys
On 9/9/06, Radenski, Atanas <radenski@chapman.edu> wrote:
Languages do evolve. For example:
Pascal => Modula => Oberon
C => C++
Java => Generic Java
Python => Python 3000
... etc...
Another interesting example: APL => J Kenneth Iverson of Harvard's APL was the first computer language I fell in love with, made me hate FORTRAN or any other punch card language. This was early "dot prompt", an interactive command line. No big long delayed gratification while you write this huge script, then debug it for hours. So *not* the XP style (so the opposite of unit testing as you go). APL you may recall, uses a not-ASCII developed as a chalkboard math notation, then made executable. J is the same thing, but ASCII. You really have to change your thinking to appreciate J's power. I'm still just a yellow belt in that world, Bruce Lee's retarded little brother in some late night Kung Fu flick (he protects me from The Man (played by Roger Hui)). Even in Python world I'm not Mr. Metaclass, nor smooth talkin' Plone Archetypes. Arthur sometimes ridicules my short little code blocks (where are my thousands of lines (answer: in FoxPro)). But that's just or "stars in the sky" style over in Buckyville. We have these weird slogans, like "YOU be the glue." Brad says our private sky is NOT THE WORLD in his posts. He sounds like a philosopher. Some other castle somewhere, where they use "all caps" a lot (I try to be sparing, but yes, I use them too). Anyway, does the fact that J doesn't run APL programs mitigate against it? Does J have a bright future? I'd think so. I sure hope gnu math teachers find a way to teach it. Like with other stuff, it's not "down to the chip" that it's open (and these days, the chip isn't either), and open source J code, like open source IronPython, doesn't imply .NET itself is completely transparent (unlike the Monkey -- the Mono -- which is much more so, or so they tell me (no I don't read a lot of C# in the course of a regular business day)). Kirby
On 9/9/06, kirby urner <kirby.urner@gmail.com> wrote:
But that's just [our] "stars in the sky" style over in Buckyville. We have these weird slogans, like "YOU be the glue." Brad says our private sky is NOT THE WORLD in his posts. He sounds like a philosopher. Some other castle somewhere, where they use "all caps" a lot (I try to be sparing, but yes, I use them too).
Actually, that was Michael Sparks of cerenity.org who reminds me I'm not the world (thanks Michael). Brad Miller is someone else: http://www.cs.luther.edu/~bmiller/ Not to be confused with... John Miller, author of PhD dissertation, Promoting Computer Literacy Through Programming Python (1.37 MB) which looks at the issues around teaching with Python, and explores some of the threads taken up right here on edu-sig, and available for download from the Python Community edu-sig home page. Kirby
participants (3)
-
Jan Claeys -
kirby urner -
Radenski, Atanas