levy@ttrdc.UUCP (Daniel R. Levy) (04/25/88)
In article <1988Apr24.004626.3209@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: > > VMS and big VAXEN are successes NOW in TECHNICAL MARKETS... > > If you think this says anything about the merits of gotos in DCL, please tell > me whether you think Reagan's election victory in 1984 constituted popular > endorsement of his policies on, say, abortion. Or whether the sales of the > IBM PC are due to the beauty and elegance of its memory-addressing model. > Or whether OS/360 was the reason people bought IBM 360s. Ha, ha, I guess. To use your Reagan example, one might say that his position on abortion was not sufficient to hurt his campaign. Likewise, any supposed "technical opposition" to gotos in DCL AND ESPECIALLY THE ABSENCE OF ALTERNATIVE STRUCTURES are not enough, in DEC's view, to warrant support of such structures. DEC has indeed revised DCL many times in the recent past. Alternatives to the goto appear to be at the bottom of the list of things they worry about, and they supply to a largely technical clientele. Face it, Henry. Gotos are a pinprick on the surface of all technical concerns in the computer world. If they were that big a deal, DCL would support all the C-like control structures that the UNIX shells do. > Marketing success and technical merit are largely unrelated. Oh, technical > merit *helps* to sell things, but it's by no means a requirement. IBM has > built a multinational empire on aggressive marketing and excellent support > of usually-inferior equipment. Yes, you'd do well to keep that in mind, that "technical merit" in and of its ivory-tower little self is not the be-all and end-all of the world. Before trying to dump on DEC a la IBM, however, keep in mind that IBM sells primarily to business customers, who don't know a goto from a RAM chip, whereas DEC sells primarily to technical installations and research institutions. -- |------------Dan Levy------------| Path: ihnp4,<most AT&T machines>!ttrdc!levy | AT&T | I'm not a real hacker, but I play one on | Data Systems Group | USENET. If you think that AT&T endorses |--------Skokie, Illinois--------| my opinions, I've a nice bridge to sell ya.
dhesi@bsu-cs.UUCP (Rahul Dhesi) (04/25/88)
In article <2605@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes: >Likewise, any supposed >"technical opposition" to gotos in DCL AND ESPECIALLY THE ABSENCE OF >ALTERNATIVE STRUCTURES are not enough, in DEC's view, to warrant support of >such structures. DEC has indeed revised DCL many times in the recent past. >Alternatives to the goto appear to be at the bottom of the list of things >they worry about... Based on a superficial (and rather skeptical, raised-eyebrow) look at VMS, I conclude as follows. VMS's design makes it very difficult to include structured control structures in DCL. The UNIX shells can save their context between commands because they execute other programs as subprocesses. Under VMS subprocess creation is so painfully slow that it is seldom done. Thus the DCL interpreter cannot save its entire context when executing another program. To use while loops and if-then statements the DCL interpreter would have to save quite a bit of the current context so it could continue executing the current control structure. Nested control structures would require even more information to be saved. Alas, the DCL interpreter and VMS make this nearly impossible. This is also the reason why VMS does not allow multiple commands on the same line. Doing so would mean saving the command line between executions of different programs so the command interpreter could then pick the next command on the same line. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
henry@utzoo.uucp (Henry Spencer) (04/27/88)
> ... If they were that big a deal, DCL would support all the > C-like control structures that the UNIX shells do. Remember that DEC has its own agenda, not necessarily matching that of their users. > ... keep in mind that IBM sells primarily > to business customers, who don't know a goto from a RAM chip, whereas DEC > sells primarily to technical installations and research institutions. I think you're a bit out of date. The research institutions and technical installations buy Suns or other fast machines these days; DEC has not been competitive in that market for years. DEC's big marketing push these days is in the business market -- just look at any of their self-congratulatory newsletters and note what kind of sales they're boasting about. -- NASA is to spaceflight as | Henry Spencer @ U of Toronto Zoology the Post Office is to mail. | {ihnp4,decvax,uunet!mnetor}!utzoo!henry
campbell@maynard.BSW.COM (Larry Campbell) (04/30/88)
In article <2725@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
<>Based on a superficial (and rather skeptical, raised-eyebrow) look
^^^^^^^^^^^
<>at VMS, I conclude as follows.
<>
<>VMS's design makes it very difficult to include structured control
<>structures in DCL. The UNIX shells can save their context between
<>commands because they execute other programs as subprocesses. Under
<>VMS subprocess creation is so painfully slow that it is seldom done.
<>Thus the DCL interpreter cannot save its entire context when executing
<>another program. To use while loops and if-then statements the DCL
<>interpreter would have to save quite a bit of the current context so it
<>could continue executing the current control structure. Nested control
<>structures would require even more information to be saved. Alas, the
<>DCL interpreter and VMS make this nearly impossible.
<>
<>This is also the reason why VMS does not allow multiple commands
<>on the same line. Doing so would mean saving the command line
<>between executions of different programs so the command interpreter
<>could then pick the next command on the same line.
[This is really getting off the comp.lang.c track, so I've cross-posted
and directed followups to comp.os.misc]
A little knowledge is a dangerous thing, Rahul. Although VMS does not
create new subprocesses to run user programs, DCL does not have to get
out of the way when running a user program because the address space
is divided into two parts -- one for the user and one for DCL (and RMS).
The user part keeps getting zapped and reloaded with user programs,
but the DCL/RMS part (P1 in VMS jargon) stays around as long as you're
logged in.
So there is no _technical_ reason why DCL couldn't easily have multiple
commands per line, and reasonable control structures. The reason it
doesn't is cultural -- the VMS people have a FORTRAN mentality. For a
FORTRAN-inspired system, VMS isn't too bad. ("Gee, for a fat girl,
you don't sweat too much.")
--
Larry Campbell The Boston Software Works, Inc.
Internet: campbell@maynard.bsw.com 120 Fulton Street, Boston MA 02109
uucp: {husc6,mirror,think}!maynard!campbell +1 617 367 6846dhesi@bsu-cs.UUCP (Rahul Dhesi) (05/01/88)
In article <1079@maynard.BSW.COM> campbell@maynard.UUCP (Larry Campbell) writes: [much omitted] >So there is no _technical_ reason why DCL couldn't easily have multiple >commands per line, and reasonable control structures. The reason it >doesn't is cultural -- the VMS people have a FORTRAN mentality. I forwarded Larry's entire article to comp.os.vms, where the VMS experts will spring to its defense. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi