Xref: utzoo comp.lang.misc:7314 comp.lang.icon:697 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!hp4nl!charon!guido From: guido@cwi.nl (Guido van Rossum) Newsgroups: comp.lang.misc,comp.lang.icon Subject: Re: Survey Results : Perl vs Icon vs .... (> 500 lines) Message-ID: <3282@charon.cwi.nl> Date: 8 Apr 91 09:45:22 GMT References: <1991Apr1.043321.11251@midway.uchicago.edu> <3252@charon.cwi.nl> <1991Apr3.151153.3447@midway.uchicago.edu> Sender: news@cwi.nl Followup-To: comp.lang.misc Distribution: comp Lines: 81 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 "Twenty years ago, Dan Bernstein would be defending Assembler against HLL's"