Re: Porting Experiences (was Ada and Pascal etc )

[scs@eskimo.com (Steve Summit)]

In article <3460A7BB.3CCD27DC@hso.link.com>,
Samuel T. Harris <s_harris@hso.link.com> evidently wrote:
> Reading the arguments between Kaz and others, I'm struck with the
> realization that Kaz is missing a significant point. As long as
> application code is not concerned with the representation of
> variables, Kaz is correct in his statements that a few simple
> guidelines insure good type choices for portable C code. What Kaz has
> failed to consider, but has been state by others, is that sometimes
> the representation of the type IS important to the application...
> context in which the application is running...  While application
> usually are only concerned witht he RANGE supported by the type...
> the context in which the app is running may force the use of
> [some type], especially when interfacing to hardware, COTS libraries,
> or in a distributed environment where heterogenous architectures must
> interface with each other. These are common examples of the context
> forcing a representation.  C does not support forcing the
> representation in a portable way. Ada does. The need for such
> cannot be simply dismissed because the need is real.

The need is as real as you make it.  (But note also that to
suggest that a problem be solved by avoiding it is not dismissing
or ignoring the problem.)

It's no surprise that performing portable, "binary" I/O to an
externally-imposed storage layout is less convenient in C.
*Everything* is less convenient in C!  It's a relatively
low-level language, as high-level languages go, and it embodies a
cornerstone of the Unix philosophy, which is that it should not
go too far in helping you to do something, because to help you to
do it invariably involves constraining the way you'll do it.
C lets you do I/O however you want; the cost is that you have
to specify more of the details to get what you want.

Of course, you can try to come up with a higher-level scheme
which contains so much flexibility that it lets you do whatever
you want, but of course, there are potential costs here, too.
One is the specification and implementation cost, and another is
the learning curve cost on the part of the would-be programmer.
From what you say, it sounds like Ada does attempt to tackle this
problem, but we know that at least one of those costs has already
been exacted.  For the first several years of its existence as a
language, Ada managed to revive an old adage from the earliest
days of high-level languages: Ada compilers were (just as FORTRAN
compilers were once thought to be) nearly impossible programs to
write.

I think that every aspect of this discussion over the problems of
performing portable, "binary" I/O is wholly consistent with the
established fact that C is a low-level language which may make
you do more work up-front than do more ambitious languages.
C's enduring popularity in spite of this tradeoff suggests
strongly that it must have some compensating merits.

But I've lapsed into silly, defensive, language-war posturing,
which is just that: silly!  Use the right tool for the job!
If you have an absolute requirement to perform I/O in a
byte-for-byte way to conform with externally-imposed storage
layouts, fread() and fwrite() are not your tools.  Either write
your own low-level I/O routines (as Kaz has been suggesting all
along), or use preexisting libraries such as those for XDR, CDF,
or HDF, or use another language which either has I/O built in or
makes it easier to encapsulate your own.  Don't blame C or call
it a poor tool for not making it easier to perform this task;
blame yourself or your superiors for choosing a poor tool or a
poor strategy.

And don't get me wrong: I do agree that, as bad an idea as it
often is, the need to perform layout-constrained I/O can be very
real.  If I were designing a language, I'd include features to
make it more convenient.  But that's another story.

> So, I can't say to Kaz that he is wrong, because he is not, as far as
> he goes. What I do say to Kaz is "You have only pricked the tip of the
> portability iceberg." Portability involves much more than guaranteeing...

Well, it all depends on how you define "portability."  I've been
a student of portability for a long time, and maybe I'm crazy or
tilting at windmills off in left field, but I'd say that if you
really care about portability, you need to define your data file
formats portably, too.  If your data format is defined, either
explicitly or implicitly, as containing fields such as "a 32-bit
integer in the machine's byte order", then it's an inherently
unportable format, and to describe a "portable" program for
reading or writing this format is an oxymoron.

Once you've defined a portable data file format, *then* you can
start arguing about which language makes it more or less
convenient, or more or less efficient, to read and write that
format.  But defining "portability" as the ability to write code
which reads and writes binary formats and which recompiles
anywhere, and then criticizing a language which does not make
this task maximally convenient, strikes me as erecting a bit of a
strawman.

					Steve Summit
					scs@eskimo.com