Re: Porting Experiences (was Ada and Pascal etc )

["Samuel T. Harris" <s_harris@hso.link.com>]

Steve Summit wrote:
> 

snip a whole lot of stuff I can't argue with...

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

Just to clarify. I agree completely that file format over which
I have control will be defined in a "portable" manner. However,
many times the context of the applications forces me to use
file formats, parameter types, etc. which are externally defined.
In the simulation world, they are usually defined to take advantage
of the idiosyncracies of target/embedded hardware which I have to
simulate/interface to with wholly incompatible hardware. In those
cases, I just don't have a choice.

I take an exception at the bit about "erecting a bit of a strawman".
Any language which is more convenient in a problem domain is a
superior choice over other, less convenient languages. "Language
wars" are not won or lost of singleton point such as our discussion
on portability (and the various flavors that involves) because
each projects have several of these problem domains with which
to deal. Each project has to take an aggregation of specific
considerations, each of which may or may not have a clear winner,
and decide what the primary language will be.

This sub-thread is about a particular problem domain. IMHO the
clear winner is Ada because of the convenience, lack of required
supported code, lower initial development, and lower maintenance.
But that only applies to this particular problem domain.
Add this comparison to your checklist and move on.

-- 
Samuel T. Harris, Senior Engineer
Hughes Training, Inc. - Houston Operations
2224 Bay Area Blvd. Houston, TX 77058-2099
"If you can make it, We can fake it!"