Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hplabs!hpfcdc!marc
From: marc@hpfcdc.HP.COM (Marc 'Sphere' Sabatella)
Newsgroups: comp.os.misc
Subject: Re: Why Unix is good (was Re: Unix bigotry) LONG
Message-ID: <5900005@hpfcdc.HP.COM>
Date: 22 Feb 89 23:24:32 GMT
References: <285@bnr-fos.UUCP>
Organization: HP Ft. Collins, Co.
Lines: 76

/ hpfcdc:comp.os.misc / schow@bnr-public.uucp (Stanley Chow) /  9:56 pm  Feb 20, 1989 /

>Given the same amount of effort, there are langauges like Fortran
>(oh no, did I just say another bad word?) that can be more portable, even
>if the application is restricted to a narrow domain.

Any particular Fortran restricts the domain of the applications written in it.
The intersection of different vendors' Fortran's yields a language
that is probably not even functionally complete; certainly it would
not make an effective general purpose programming language.

>(By the way, do you handle 9 bit bytes? Nil pointer that
>is not 0? Segmented architecture that does not allow addresses before or 
>after an allocated object? Different precision floating point?)

A minor nit:  ANSI defines NULL to be 0, so one needn't worry about that.
Your point about C programmers relying on implicit assumptions such as
byte size, etc. is well taken, although I don't see floating point precision
as an issue because C programmers are no worse here than Fortran programmers.

However, picking on such obsurities as 9-bit bytes emphasizes the portability
of C: with careful (but not excessively difficult) programming, your C
program will run on the majority of architectures; and if you are a real
zealot, you can even #ifdef away dependency on byte sizes.

>> [ someone else's description of abstraction ]
>My point exactly. It is the methodology and style of coding that
>makes code portable, not the system for which it is written and not
>the language in which it is written.

The system independence of good code is true in principle, but sidesteps
the issue that the systems themselves (except Unix) are non-portable.
All but the most trivial of program will have some system dependence.
If you abstract carefully, as the previous poster did, you can localize
the system dependence, but you will still need separate system-dependent
sections for each system.  With Unix, you can structure that section so that
it may be Unix specific, but is not machine dependent.  With VMS, (or NOS, etc)
the system dependent code will run only on Dec, (or CDC, etc).

As for the language, this is simply untrue.  With most other languages, the
system dependent part must be extended to include "language implementation"
specific code (for example, Pascal string handling packages); the common
code must be written for the least common denominator (a misnomer, but I
digress) of the feature sets of the various different Fortrans or Pascals
provided by different vendors.  With C, you have some assurance that this
least common denominator will be some semblance of what is described in K&R,
which is a language with enough power to allow you to write reasonable
programs.  You also know you will have the ability (via #ifdef) to isolate any
dependcies; you have no way to (portably) do that in most other languages.

>I have had occasion to move Fortran (that dreaded word again) programs
>between some systems, in the intended domain (that is, a lot of number
>crunching), I suggest Fortran is at least as easy to port.

You cannot be serious.  Vendor X does not support recursion, Vendor Y does
not support records.  Vendor Z does not allow calls to "C" library routines.
Vendor Q doesn't even allow separate compilation.  You want to port between
these?  This is a nightmare.  Perhaps "in the intended domain" is the key:
programs which use only a bare bones subset of the language will be easy to
port.  But then the program could probably have been written just as
portably in C.

>In fact, I
>think I will go whole hog and suggest that on large projects (> 1 million
>lines), the language and the O/S is irrelevent since it will be cheap
>to retarget the compiler and O/S to the new harware.

This just begs the question.  If we accept that OS's and compilers may just
be retargeted, then of course all systems and languages promote portability
equally.  The point is, Unix and C make this a necessity less often than any
other OS/language combination.

--------------
Marc Sabatella
HP Colorado Language Lab
marc%hpfcrt@hplabs.hp.com