Quoth Oleg Goldshmidt on Sat, Jul 05, 2003:
> Vadim Vygonets <[EMAIL PROTECTED]> writes:
> 
> > Quoth Oleg Goldshmidt on Fri, Jul 04, 2003:
> > [snip snip]
> > > So "portable" in the Java/Python/etc sense means *portable across a
> > > limited, albeit maybe wide enough, range of platforms*. This is a very
> > > different notion of portability than that of, say, ISO C.
> > 
> > Which is only portable across a limited, albeit maybe wide
> > enough, range of platforms which have a C compiler (which happens
> > to be a widely implemented language, but I don't think it exists
> > for PalmOS, for example (PalmOS C is not ISO C, if I'm not
> > mistaken)).
> 
> In general no, you do not have to have a C compiler *on* your target
> platform. You can compile elsewhere.

Yes, but you need to have a C compiler for your target platform,
which is almost as hard.

> The main difference is that you
> do not need an external program such as JVM to *run* your code in this
> case. 

You still need environment support, which is quite a lot.  The
amount of code you need to run hello.c on your computer is much
bigger than that you need to run a Forth version of it on Sun's
OpenFirmware (kernel + init + libc + ld.so (or whatever have you)
vs. an interpreter the size of a couple of KB on a chip).  There
is no fundamental difference between interpreter and other kinds
of environments, and if you want to minimize the runtime support
you need, you should write standalone programs in assembly
language.

Is PNG portable?  (To dismiss this question as irrelevant, one
must argue the fundamental difference between code and data.)

> I have never owned a Palm or written code for it, but I do think a lot
> of C/C++ code has been written to run on PalmOS. AFAIK a GNU toolchain
> for PalmOS is widely used
> 
> http://www.palmos.com/dev/tools/gcc/

Yes, but I don't think it has all of ISO C libraries, and hello.c
will probably not run on PalmOS as is.  The compiler is gcc, but
it doesn't mean you have the rest of the environment there.

> Of course, you have to use the PalmOS system API to write for PalmOS,
> and FubarOS system API to write for FubarOS.

What good is a portable language if you can't write portable
programs in it?

> But that's the point - you can.

Yes, the language that combines the power of assembly with the
portability of assembly.  You can write portable C programs with
#ifdefs in too many places, but this practice is not called
portability, but re-implementation.

> In Java, you will have to wait till someone else develops the
> facilities.

UNIX is C-centric, so every facility that is developed for UNIX
is developed for C.  Every low-level facility, that is.  Programs
like wget are better used from shell than from C.

On systems where C is not the native language (such as MS-DOS)
all of these facilities needed to be provided for C explicitly
(MS-DOS C compilers came with their versions of libc).  And if
you needed to use a system facility provided by the environment
but not provided by this particular compiler, you needed to write
your own interrupt calls and such, which would be as portable as
writing in assembly.

> Doesn't that bring you back to a familiar argument? ;-)

Umm, which one?

> > Also, to write a portable ISO C program you must use only a small
> > subset of libraries, which is not nearly useful enough, 
> 
> I never saw this as much of a restriction. And in most code I saw that
> deviated from ISO C it was not necessary at all.

Most of C code I see in *my* daily life is UNIX specific, and
mostly for good reasons (networking, filesystem specific details,
authentication, reliance on multi-tasking, graphics, TTYs,
printing, signals, to name a few in pseudo-random order).

> > There are still issues like different formats of filenames
> 
> That is external and is the same for any language, so this does not
> discriminate.

True, I was just pointing on more difficulties in portability.

C may be the most ported language in the world, which does not
make it the most portable, nor does it make the programs written
in it most portable, surprisingly enough.  But I'm not trying to
say things about C, I'm just disagreeing with your statement that
interpreted languages are less portable than compiled ones.  To
summarize:

+ The original poster asked about writing portable programs, so I
  define portability of language as the ability to write portable
  programs in it, not the number of platforms the language is or
  may be ported to.

+ In this context, libraries are as much a part of the language
  as the syntax.  I don't care on how many poatforms I can
  compile a "while" loop in C.

+ #ifdef is not "portability", but system dependent tricks which
  make the program compile *differently* on different platforms.
  The program is thus not portable across many platforms, but
  *ported* to them.

+ Therefore, if in language Foo I say "open a window with these
  menus" where in Bar I need to re-implement the same code for
  different window systems, then the Foo program is portable
  across all platforms which provide Foo runtime and a window
  system, and the Bar program is merely ported for those Bar
  environments which have window systems A and B, but if I want
  to run the program on window system D, I need to re-implement
  some parts.

+ Interpreted language need an interpreter at run time.  Compiled
  languages need a slightly different kind of run time
  environment, which may be bigger (C on UNIX vs. on-chip Forth
  or Lisp on Lisp machines) or smaller (C vs. Perl).

+ The issue of interpreted vs. compiled has nothing to do with
  portability.  Emacs gurus may correct me, but I presume that
  it's possible to draw a picture on the screen in elisp so it
  will work on UNIX, Win32 and MacOS X, while if you do the same
  in C using X11 libs your program will be less portable.  OTOH,
  the author of zsh says it's easier to write a potrable shell
  than a portable shell script.

Vadik.

-- 
There is hopeful symbolism in the fact that flags do not wave in a
vacuum.
                -- Arthur C. Clarke

=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]

Reply via email to