From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1014db,4873305131bf4d94 X-Google-Attributes: gid1014db,public X-Google-Thread: 103376,4873305131bf4d94 X-Google-Attributes: gid103376,public X-Google-Thread: 109fba,4873305131bf4d94 X-Google-Attributes: gid109fba,public From: "Samuel T. Harris" Subject: Re: Porting Experiences (was Ada and Pascal etc ) Date: 1997/11/13 Message-ID: <346B3C66.41A6FDBA@hso.link.com>#1/1 X-Deja-AN: 289577913 References: <34557f2b.1934172@news.mindspring.com> <345E3ACD.A15@gsg.eds.com> <63mcmm$r3s$1@helios.crest.nt.com> <3460A7BB.3CCD27DC@hso.link.com> <64f5nr$6de$1@eskinews.eskimo.com> Organization: Hughes Training Inc. - Houston Operations Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++ Date: 1997-11-13T00:00:00+00:00 List-Id: 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!"