Xref: utzoo comp.lang.misc:7258 comp.lang.icon:688
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!boingo.med.jhu.edu!haven!mimsy!midway!ellis.uchicago.edu!goer
From: goer@ellis.uchicago.edu (Richard L. Goerwitz)
Newsgroups: comp.lang.misc,comp.lang.icon
Subject: Re: Survey Results : Perl vs Icon vs .... (> 500 lines)
Message-ID: <1991Apr3.151153.3447@midway.uchicago.edu>
Date: 3 Apr 91 15:11:53 GMT
References: <BEVAN.91Mar29162211@panda.cs.man.ac.uk> <1991Apr1.043321.11251@midway.uchicago.edu> <3252@charon.cwi.nl>
Sender: bcareful@midway.uchicago.edu
Distribution: comp
Organization: University of Chicago
Lines: 84

In article <3252@charon.cwi.nl> guido@cwi.nl (Guido van Rossum) writes:
>
>>> -  [the Icon-]Unix interface is quite primitive.
>>>    If you just want to use a command, you can use `callout', anything
>>>    more complicated requires building a personal interpreter (not as
>>>    difficult as it may sound)
>
>Goerwitz:
>>It is quite true that Icon does not provide a good low-level interface
>>with the operating system.  Moreover this is unlikely to change, since
>>one of the great aims of Icon has been to keep it portable....
>
>I don't buy the argument that you can't provide a good Unix interface
>because of portability.
>
>Python is designed to be just as portable as Icon (runs on the Mac,
>for starters) but its Unix interface is quite good (and will improve).
>The trick is that all the Unix dependencies are encapsulated in a
>separate module.  Unix dependent applications won't run on non-Unix
>systems, but then they are probably not needed there either.

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?

	MS-DOS
	OS/2
	Mac (MPW and standalone)
	Atari
	Apollo (AEGIS)
	IBM 370 (MVS/XA and VM/CMS)
	Amiga
	DEC VAX (8650, running VMS)

And for Unix-oids:

	BSD 4.3
	SunOS 4.0
	Ultrix
	AIX
	Xenix
	Mach (on the NeXT)
	SYSVR3 (4 also?)

This is just what I can think of offhand.  There are probably others as
well.

>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.

I'm not sure, but I think you've got this backwards.  Customization
*creates* nonportability.  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).

-Richard (goer@sophist.uchicago.edu)
-- 

   -Richard L. Goerwitz              goer%sophist@uchicago.bitnet
   goer@sophist.uchicago.edu         rutgers!oddjob!gide!sophist!goer