NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/os/vms/20372

Internet Message Format | 1993-01-05 | 7.4 KB

Path: sparky!uunet!cs.utexas.edu!zaphod.mps.ohio-state.edu!moe.ksu.ksu.edu!mccall!mccall!tp
Newsgroups: comp.os.vms
Subject: re: VAX c
Message-ID: <[e-mail]>
From: [e-mail] (Terry Poot)
Date: Tue,  5 Jan 1993 12:10:34 CST
Reply-To: [e-mail] (Terry Poot)
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: The McCall Pattern Co., Manhattan, KS, USA
Nntp-Posting-Host: mis1
Nntp-Posting-User: tp
Lines: 132


In article <[e-mail]>, [e-mail]
(Remember Grimalkin) writes:
>This discussion just reinforces my belief that C is an unacceptable language
>because the run time library has to emulate unix, regardless of the OS. I
>have seen C take over as 'this weeks language' and I just don't understand it.
>Why in hell are so many people using C on VMS?

Because FORTRAN, COBOL, Pascal, PL/I, and Basic suck? To paraphrase someone
else, it's the worst language in the world, except for the rest of them.

But to directly answer your question, I use C because I require a portable
language (meaning that most of my code can be portable, and most any platform I
might ever run on has a reasonably compatible implementation of the language
with vendor or equivalent support and native platform debugger support) with
modern control structures and data structures, and dynamic memory
allocation/deallocation. As far as I know, C is IMHO the only language that
meets these criteria (many of which are admittedly subjective). Since I made
that decision, embedded SQL support and convenient access to Xlib, Xt, and Motif
APIs have been added to that list of requirements, and I'm more pleased than
before with my choice.

BTW, the choice came about in both of my last 2 jobs, on different platforms,
and happened to come out the same. The previous job was a mixed Harris VOS/unix
shop.

I expect to transition eventually to C++, but it does not currently meet the
above criteria to the best of my knowlege (which is limited at this time, I
freely admint).

>Why would you want to hose your
>performance running through 14 levels of emulation attempting to (and often
>failing) make the rtl conform to every little idiosyncrasy of one particular
>system?

a) I don't do enough I/O in most of my applications for the degradation to
amount to a hill of beans.

b) The key word in least common denominator is still _common_. If you don't care
about portability, use RMS directly and avoid all that emulation. This isn't a
language issue per se. Any portable API will have to define an I/O model, and
there will be some systems it doesn't fit well on. As it happens, the industry
has settled on the unix I/O model.

Personally, I think it's a good choice, as it is about as simple a model as you
can get (simple byte stream). The problems with the VMS RTL (and yes, that is
where they are) are bad design, and the need to try to extend this model to
support the VMS I/O model. If you never use anything but stream files, you won't
have much trouble with I/O. You'll still have some, because VMS doesn't really
support stream files.

If you need something that is intrinsically not a stream file, you might as well
use RMS directly, because it isn't portable anyway. In cases other than I/O, I
certainly don't use the unix emulation, because it isn't any good. I isolate
that code to a module that will be rewritten if I port. For instance, I use
lib$spawn, lib$do_command, lib$run_program, lib$set_logical, callable TPU, etc.
There isn't a portable way to do what I want, so I isolate the code and do it in
a way that makes sense. It's still in C, but I avoid the RTL where it's broke or
insufficient.

>I mean, is it a management decree based on 'marketing related
>concerns'? Is it for 'portability' (seems like the typical C program depends
>on
>such exact unix behavior that this portability is just a myth touted by people
>running unix. Christ, look at the contortions the guy who ported XV had to go
>through)?

I ported the entire PBMplus suite in probably under 15 man-hours. Most of that
work consisted of coping with the fact that VMS doesn't support pipes, and
developing build procedures, which had nothing to do with language issues. A few
problems showed up because VAX C isn't ANSI compliant, but except for the pipe
problem, it pretty much dropped in and ran. I don't know what the problems with
XV were, so I can't comment on that. I ported YACC. It took a one line change to
a file name. I ported Ghostview. Again, the problems were pipes and environment
variables.

I've ported Fortran code from system to system (professionally). It takes a LOT
more work. It's one of the reasons I chose C. The typical C program is generally
quite easy to port (ease is relative, of course). The trouble spots are file and
directory manipulation in unusual ways, and pipes forks and execs (the biggies).
These aren't features of the C language per se. They could be done better in the
VAX C RTL than they have been.

In my case, it is a "mangement decree" (I'm a manager) based on productivity.

>The latest ante in the game (but one that could be predicted given the way
>things are going) is this abomination called VMS POSIX

Other than detesting anything that looks like unix, why do you consider it an
abomination to be able to run progrms from other systems? Do you prefer
proprietary systems? Once POSIX works well, we'll have access to a great deal
more software than we do now. You see this as a drawback?

>(I won't even start
>about 'OpenVMS').

Pure BS until POSIX works well.

>It sure would be nice if there was some non-biased attempt at
>environment interoperability, but I guess we're gonna be stuck with 'If you
>can't beat 'em, join 'em'.

You prefer "If you can't beat them, declare chapter 11"? I guess a non-biased
attempt would be to define an environment that doesn't exist and is equally
different from every other environment so it won't fit easily anywhere. Not much
chance of that succeeding. Or I suppose you could pick one that was so
featureless it'd work anywhere. Of course, that would, by definition, be
useless. Of course, if VMS were tearing up the industry, perhaps it'd be the
standard environment. That would, of course, presupose that all other computer
companies went broke, since that's the only way it could happen, given that it
hasn't been available to anyone but DEC until just recently.

>Now it's getting to the point where it's painful
>NOT to use C (example: multinet networking code and gaddam 'sockets').

A common effect of the proliferation of a standard is to make it difficult not
to abide by the standard. Drive on the other side of the street on your way home
for an illustration. Specifically, the benefit of a standard is that one can
write to it without going through a great deal of pain to work with other
software. Those that buck the standard go through the pain, but everything is
easier for the rest of us.

>I
>suppose it would behoove me to start writing everything in C, but something
>is still making me hold out. It's just the PRINCIPLE of the thing!

Your choice. But you'll increasingly be pounding square pegs into round holes.
What is the point in doing a lot of extra work just to avoid writing in C?
--
Terry Poot <[e-mail]>                   The McCall Pattern Company
(uucp: ...!rutgers!depot!mccall!tp)          615 McCall Road
[phone], in KS [phone]           Manhattan, KS 66502, USA