🚀 go-pugleaf

goer@ellis.uchicago.edu (Richard L. Goerwitz) writes:

>What is portability?  Portability doesn't just involve the compiler or
>interpreter itself.  It's a property of code written for it as well.
>Why?  Because the code is as important as the language tools themselves.
>What good is it, say, to be make it easy to reimplement a compiler for
>more than one system when code written for that compiler will present
>a horrendous problem?
>
>Portability is also not just a theoretical thing.  The proof is in the
>pudding.  How many platforms is Python actively used on?  Here's a list
>for Icon.  Note that most programs will run practically unaltered on
>each of the listed platforms.  Do you know of any language for which a
>similar claim could be made for so many machines and operating systems?

If I understand you well, you can make this claim for Icon because
Icon forbids things that are inherently system-dependent.  This means
that probably a host of programs that would benefit from Icon's
high-level problem-solving abilities won't be written in Icon because
it lacks the low-level interfaces needed to gather the data or
whatever.

True, if a program opens a pipe and forks off a process that calls
sendmail it won't be portable to the Mac.  But forbidding such things
even when the OS provides the functionality forces the author to use a
non-portable solution anyway (such as writing a shell script wrapper
around an Icon program).  I argue that if the language at least allows
you to make non-portable OS calls, users are better off -- of course
assuming standard modularization techniques are available to isolate
non-portable portions of programs, and encouraging portable solutions
where they exist.

>[list of platforms on which Ican is used deleted]

I don't really want to engage in "mine is longer than yours" contests,
but just for the record: Python is out only two months now and has
already been ported to all of the Unix platforms you mention (plus
hpux) and some of the micro ones (Mac, MS-DOS, Atari ST).  I don't
claim that all Python programs run on all platforms, because some
platforms don't provide some built-in modules, but Python programs
that don't use system-dependent modules will run everywhere
without change.  The crux is that a non-portable Python program is
immediately recognizable because it imports a system-dependent module.
Also note that Python provides uniform interfaces for OS-dependent
features that are available on many systems but not all -- if you have
a symbolic link system call, it will be called posix.symlink().
Programs can dynamically test for the presence of such features (which
is unly useful if they have a way of handling their absence).

>[...]  Still, I think you are right that languages
>need a good OS interface in order to be useful for certain types of
>tasks.  The question is, "What features would you regard as vital for
>work in a Unix environment?"  I'll be curious to see your answer.
>Mine would be:
>
>	ability to call C functions
>	ability to store C pointers for calls to C functions
>	built-in support for conversion from Icon to C types
>	intrinsic fork()/exec()/wait() ability
>	intrinsic ability to work with pipes
>	intrinsic system() function

>These would be the basic things I'd want.  Icon has three of them.  It
>lacks the other two.  Yet another it partially implements, but the inter-
>face is nontrivial for complex objects (I'm talking about Icon->C type
>conversions).

You don't say which three Icon has and I don't know enough about Icon
to guess.  Python has all that you mention except fork/exec/wait and
pipes, which are easy enough to add, but since this is a one-person
project, for now I am content with system() and temporary files.

Disclaimer: maybe I seem stubborn on this point, but I have worked on
a language project where OS independence was considered so important
that the language didn't even have a primitive to open a file and read
data from it within a program.  The language didn't become a terrible
success, even though it had other properties that made it a big leap
forward from other languages...

--Guido van Rossum, CWI, Amsterdam <guido@cwi.nl>
"Twenty years ago, Dan Bernstein would be defending Assembler against HLL's"