🚀 go-pugleaf

In article <1472@optima.cs.arizona.edu> Kenneth Walker writes:
>In article <3252@charon.cwi.nl>, guido@cwi.nl (Guido van Rossum) writes:
>> There is no excuse for not providing a decent Unix interface for a
>> language that runs under Unix.  Leaving it up to local initiative
>> ("customization") is fatal for portability.
>
>The argument applies equally to the Amiga, Atari ST, MS-DOS, OS/2,
>MPW on the Macintosh, CMS, VMS, and VMS. That's a lot of work!
>Actually there are some operating system specific functions, mostly
>supplied by those who did the ports and other members of the user
>community. My point is that implementing and supporting such interfaces
>requires resources.

True, but there should be a distinction between adding the interfaces
to the base language and adding them as library support.  One of the
advantages of Python as I see it is that it has a good library
mechanism.  This allows you to hide all the system specific details in
a library (and in a different namespace) rather than cluttering up the
base language.

The Python method is borrowed from Modula II, which, although not a
great language, is a definite step up from languages like C and
Pascal.  Unfortunately due to a number of reasons, (doesn't look like
C? European?) Modula II never caught on in a big way and thus I don't
think a standard set of libraries was ever produced.  This is often
used as a stick to beat Modula II with.  However, most people seem to
ignore the fact that until ANSIfication, the C library situation was
not exactly stable.

Stephen J. Bevan			bevan@cs.man.ac.uk