From: lezz@merlin.dev.cdx.mot.com (Lezz Giles)
Subject: Re: The need for an assembler (was: Favorite CPU)
Reply-To: lezz@merlin.dev.cdx.mot.com (Lezz Giles)
Organization: Motorola Codex, Canton, MA
Date: Thu, 3 Sep 1992 17:39:45 GMT

In article <1992Sep3.090347.21766@news.columbia.edu>, lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
|>In article <id.HLVS.5DJ@ferranti.com> peter@ferranti.com (Peter da Silva) writes:
|>>In article <1992Aug31.162630.23913@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes:
|>>> A very popular and recent piece of software is DR-DOS Version 6, which 
|>>> is written in mostly assembler and runs on all of these, picking up options
|>>> along the way in a seamless manner where applicable.
|>>
|>>An operating system of that level (basicaly file system and monitor) is
|>>inherently non-portable, so who cares?
|>
|>Your out-of-context quote doesn't change the point of the original: the O/S
|>runs best on any hardware it was designed to run on; it isn't portable the
|>way you would demand of it, so what?  The example was to point out that the
|>poster was attempting to make claims that there were drastic changes in the
|>PC's evolution that caused major software upheavals as a consequence; the
|>example merely proves how wrong that is.
|>
|>>
|>>> Within the world of Kermit, we have frustrating cases of even small programs
|>>> that need worlds of conditionals to satisfy the bizarre variations floating
|>>> around the industry.
|>>
|>>Within the world of Kermit the latest release I've tried still runs on Xenix-
|>>286 (System III Xenix, not SCO), System V on the 386, System V on the 68000,
|>>and on the Sparc. I would take some convincing that this would be possible
|>>in any other language that's reasonably widely available, except maybe Fortran.
|>
|>So, why don't you thank the Kermit group for all of its frustrating work?  I
|>didn't say it wasn't overcome, just that an inordinate amount of time was
|>spent getting it to work properly on most of the systems it was meant to.
|>
|>The point still stands: C implementations are insidiously non-standard, and
|>cause major maintainence problems when programs are *not* migrated, but
|>rather are proliferated.  The portability arguments usually stated to
|>proclaim the virtues of C are "burn the bridges behind" arguments.  The
|>Kermit project supports *all* appropriate machines, thus has to clean up
|>all the shit left behind as well.
|>
|>Before C existed, no one "ported" anything; we merely had language specs and
|>various levels of compatibility, hopefully of the kind of either it worked or
|>the feature was lacking and you got error messages.  Now, the code may
|>seem to be compiler error free yet not work, or needs to be allowed to
|>get confusing warning messages from some compilers to actually function,
|>because there's no reasonable way to eliminate the warnings all together
|>without essentially having N copies of the program with one woken up for
|>each system type in much of the code.
|>
|>Furthermore, Kermit tends to be written by a different segment of the industry
|>than I am ragging on, yet these generally better people are still having a
|>lot of grief stemming from these problems.  If this is ease of programming, 
|>I'll stick to 100% assembler :-).  (You have to admit it solves all insidious
|>near-compatibility problems :-).)

I know very little about kermit, but I do know about GNU and perl.  Perl
runs first time on 99% of platforms with no hassle, and the same holds
for GNU products - I haven't heard of much in the way of grief from them
in trying to support different environments...

Lezz "throw on some more coals" Giles
Newsgroups: alt.folklore.computers,alt.religion.computers