Unreal Tournament>>To Use Python?!

skaller skaller at maxtal.com.au
Sun Dec 12 15:37:36 EST 1999


"Jesse D. Sightler" wrote:

> > BTW, the same page has a rant about how 'old' most languages are in terms of
> > their underlying technology, for example, C++ and Java use 20+ year old
> > techniques.   I quote again:

> > <quote src="http://unreal.epicgames.com/News.htm" date="12041999">
> > I'd like to end this update with a rant, based on the observation that
> > mainstream programming languages, C++ and Java, are dismally far behind the
> > state-of-the-art.  The theoretical underpinnings of these languages were all
> > set in stone in the late 1960's, before I was even born!
> >
> > Compare this state of affairs too advances in microprocessor technology,
> > where time-to-market is under 5 years; or games and 3D hardware, where there
> > is less than 24 months of lag between "great new idea" and "product on store
> > shelves".
> >
> > Yet with programming languages, the lag in widespread adoption of new
> > theory-level advances seems to be 20-30 years. 

> > Would Python fall under the same critique?
> 
> No.  But then again neither would C++ or Java.
> 
> Processors are based on silicon, which is based on atoms, which have
> been around forever... therefore all processor technology could have
> just as easily been available in the year 6000 B.C.  Great logic
> there... if you're an idiot. :)

I happen to agree with what the original author is saying.
There is a real issue here: why do people go for the latest
hardware technology, but not the latest software, particularly
programming languages??

At least in part, the answer is COMPATIBILITY.
And not just with other software, but with built
in mind sets -- human knowledge.

For example, there is suitable theory, and much experimental
practice, on technology which obsoletes object orientation.
But very few non-academics know anything about it.
Indeed, very few acedemics know anything about it.

The theory is called 'category theory', and it is the central
theory of modern mathematics (obsoleting set theory).
There are programming languages based on it, or at least
influenced by it, and almost all modern language design
is discussed using its terminology. The module system
of Standard ML has been based on it for a number of years,
and computing engines using categorical combinators and
other technhiques are beginning to dominate new language
designs, especially in the functional area.

There is a high performance, pragmatic, programming
language whose engine and theoretical underpinnings
are based on it (caml: Categorical Abstract Machine Language;
ocaml: with objects). My Viper interpreter for Python is
written in Ocaml.

Why aren't people using it, instead of C, which is
totally archaic? Because C is available everywhere
and used to interface with the operating system;
and modern programming is all about interfacing
and resource managements and NOT computation
(i.e. numerical calculations). Fortran -- it's
still the fastest specialist language for numerical
computation. C++ -- because it is more advanced than C,
but still C compatible.

One may wonder, why are people using Java?
Well, it is basically a version of
C/C++ which provides mind set compatibility though
not physical compatibility, and overcoming
_that_ hurdle required a monumental campaign from a 
seriously scared company, which had enough foresight to see
its market position (based on work stations)
was doomed, and also spot a new niche
(Internet programming).

So now we come to Python. In fact, it is based
on archaic technology, and Guido is pushing to make
it even more so. However, the _implementation_
technology is more modern. Why is it increasingly
popular?

Part of the answer is: it is archaic.  It interfaces
well to C -- archaic, but pragmatic. It uses a simplistic
statement based grammar, and lacks proper scoping:
archaic, but familiar. But it _also_ avoids some
of the pitfalls of older languages: it has a clean
syntax, for example, and a system of modules and
packages, which is somewhat more modern, and 
the design supports pretence of object orientation,
also slightly more modern.

There is an important point here. Languages based
on _modern_ theory are still experimental.
Python on the other hand is _mature_: there is nothing
new in it, it is just an excellent synthesis of the best
mature technology. And this is a significant achievement,
well recognized on comp.lang.python.

There's an excellent reason to use a mature product:
problems you have doing so have usually arisen before,
and there is a sensible solution. Omissions and bugs
from earlier versions have been fixed. The limitations
of the system are known.

The point probably is: software is much more complex
than hardware. It therefore takes much longer for
ideas to become 'industrial strength' products.
This is why, for example, CPython still uses reference
counting instead of a garbage collector.
(And collectors have been around since LISP!)
This may change in Python 2 -- both JPython
and my Viper system use collectors, and together
they should demonstrate that collectors are a practical
choice for CPython too.

How mature is Python? Well, in a few days there will be
THREE implementations, which is indicative of a very strong language.
In a few years, it might get Standardised, which is often
indicative that the vestiges of experimental design are
gone (C++ was an exception to this).

Just look at Unix: archaic. Yet the fastest growing
OS around -- Linux -- is based on the same archaic design.
More modern systems (such as NeXt) have failed.
[Windows is an exception -- but the modern design
is hidden under a compatibility layer]

It's very unlikely there will be any change in 'local'
operating software until it is truly hidden under a
layer of 'internet' software, when compatibility
becomes less of an issue, or when parallel computing
becomes important enough that a new paradigm is
essential.

-- 
John Skaller, mailto:skaller at maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia
homepage: http://www.maxtal.com.au/~skaller
voice: 61-2-9660-0850



More information about the Python-list mailing list