🚀 go-pugleaf

In article <16438@shlump.nac.dec.com> heintze@fmcsse.enet.dec.com (Siegfried Heintze) writes:

>So, assuming VAXset is part of the VMS environment, what makes U* better?
>(Feel free to answer in the context of "money is of no concern" as well as
>"money is significant").

	As a pure development environment, none is better than whatever
one you're most familiar with.

	When I did [uck!] some coding on PCs, I used a toolkit that hid
the PC from me by making it look Unix-like. If I do development on VMS,
I'll try to work from within Eunice. Not because one or the other is
inherently *better*, but because Unix is what I know best. [I happen to
have learned Unix in preference to everything else because the way it
works resonates nicely with the way I think] This argument cuts both
ways, of course.

	The big benefit I think a lot of people see in Unix is that it
offers the *potential* for a high degree of portability (inter vendor,
inter platform, inter O/S - sometimes) if due care is taken. This makes
a *BIG* difference if "money is significant" is the answer.

mjr.

In article <16438@shlump.nac.dec.com> heintze@fmcsse.enet.dec.com (Siegfried Heintze) writes:
>Having used VMS for many years and being terribly ignorant of the different
>flavors of U* I would like solicit comments from programmers experienced
>in both VMS and U*.
>
>Specifically I would like to know what makes U* a better development
>environment.  (I assume there is someone out there who is certain U*
>is a better development environment.)
>
>So, assuming VAXset is part of the VMS environment, what makes U* better?
>(Feel free to answer in the context of "money is of no concern" as well as
>"money is significant").
>                                                           Sieg

We switched from VMS to Unix for the reason that, these days,
"portability" and "openness" are industry watchwords.  Using VMS ties
you specifically to DEC and whatever direction they choose to take.
Using Unix means that we can abandon a vendor which is not supporting us
adequately, and switch to another (which might not either), in search of
the best available support.  The switch from one vendor's Unix to
another may not be trivial, but it's sure less painful than VMS to
anything else.

Personally, as a programmer I prefer the facilities of VMS, which are
capable if not necessarily convenient; and the VMS manual set which,
if not exactly readable, at least has all the details I have
needed. I can't exactly say the same for Unix. I haven't used the VAXset,
and now I probably never will.
-- 
First comes the logo: C H E C K P O I N T  T E C H N O L O G I E S      / /  
                                                                    \\ / /    
Then, the disclaimer:  All expressed opinions are, indeed, opinions. \  / o
Now for the witty part:    I'm pink, therefore, I'm spam!             \/

In article <16438@shlump.nac.dec.com> heintze@fmcsse.enet.dec.com
(Siegfried Heintze) writes:
[much about tools deleted]
>So, assuming VAXset is part of the VMS environment, what makes U* better?
>(Feel free to answer in the context of "money is of no concern" as well as
>"money is significant").

If one assumes that money is significant, a simple answer turns up,
one which has little to do with availability of tools (though some to
do with their prices).  That answer is this:

	DEC uVAX 3 with VMS: cost approximately US$15,000; speed around
		5 or 6 Meaningless Indicators of Processor Speed.

	Any SPARC or MIPS system with UNIX: cost approxmately US$5,000;
		speed around 20 Meaningless Indicators of Processor Speed.

The MIPS numbers are extremely slippery, and the costs above are
far too `rounded', but it is now clear that Unix boxes cost less and
run faster than VMS boxes.  The money saved can be spent on buying
or developing production tools if necessary, and the result is a
system that runs about four times faster.  You can get a faster VMS
machine by throwing more money at the problem, but you can also get
a faster Unix machine the same way.  For the price of a VAX 9000
system you can probably buy an Amdahl or a couple of dozen MIPS 6280s
(the MIPS 6280 system being between 55 and 65 Meaningless IPS).

This is, of course, a relatively recent development, but certainly an
important one.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 405 2750)
Domain:	chris@cs.umd.edu	Path:	uunet!mimsy!chris

In article <16438@shlump.nac.dec.com>, heintze@fmcsse.enet.dec.com (Siegfried Heintze) writes:
> Having used VMS for many years and being terribly ignorant of the different
> flavors of U*
> I would like solicit comments from programmers experienced in both VMS and U*.
> 
> Specifically I would like to know what makes U* a better development
> environment.

[much of his question omitted]

> your source code like "find all the occurences of variables of type x whose name
> matches
> the pattern *jj*h in the set of routines  whose names match j* in call tree x
> ...."
> 
This one "feature" of VMS is enough to make one climb the walls after
one becomes accustomed to UNIX regular expressions.

There are one or two other advantages of UNIX.

dan herrick

In article <1990Oct17.211857.19213@decuac.dec.com>, mjr@hussar.dco.dec.com (Marcus J. Ranum) writes:
> >So, assuming VAXset is part of the VMS environment, what makes U* better?
> 	As a pure development environment, none is better than whatever
> one you're most familiar with.

Only if the environment you're familiar with is good enough.  
When I switched to UNIX, the environment I was most familiar with was IBM TSO,
and ANYTHING was better than that, except punch cards which I also knew well.

(Unfortunately, vi is "good enough", so I stil haven't switched to EMACS,
in spite of its obvious superiorities. :-)
Marcus goes on to say good things about using toolkits to make the
new environment emulate the old one when possible.

			Bill
-- 
					Thanks; Bill
# Bill Stewart 908-949-0705 erebus.att.com!wcs AT&T Bell Labs 4M-312 Holmdel NJ
Government is like an elephant on drugs: It's very confused, makes lots of noise,
can't do anything well, stomps on anyone in its way, and it sure eats a lot.

  Well, there are a lot of tools using the same conventions, so you can
learn something and use the info in many places. Regular expressions
come to mind.

  There are a number of user interfaces, allowing the developer to use
the one most suited to his (her) needs or preferences. In the same vein
there are more editors than you can count, and many are customizable.

  UNIX has a large number of tools which manipulate data and pass it on,
giving the ability to do many ad hoc text enquiries and manipulations
using pipes, without intermediate files. This is simply not practical in
VMS, due to the high overhead required for process creation. No matter
what the horsepower of the CPU, a pipe with more than a few processes is
slow. I have run DECshell on an unloaded large VAX (sorry, number
escapes me), and it is a pig.

  The filenames are more consistant in UNIX, and you can have links when
needed to make directory structures intuitive. That doesn't mean simple,
just that you can find the same data file in /techrept/mit and
mit/techrept, without having multiple copies. You don't need to know
where a file is physically to get to it, that's the diference of
"~joe_s/doc/scan" as opposed to "BIGVAX::USR$DISK3:[JOES.DOCS]SCAN."

  VMS assumes that it knows what you're doing, and UNIX assumes that
*you* know what you're doing. If a filename doesn't have a dot in it VMS
usually wants to add one, and a filetype. Often it guesses right, but it
still guesses.

  UNIX has what appear to be better tools standard to allow multiple
users to develop on the same project, Notable SCCS and make. And there
are versions of these themes if you don't find vanilla fits your
situation.

  Portability is important. You can do development on a number of
platforms, and if you follow some rules the result can be run on any and
all of them. You really can do development on mixes like Ultrix, SunOS,
and V.3.2, with all developers compiling the successive production parts
on their machine, but doing the editing and testing of modules against
the current base locally. NFS makes this possible.

  Access control in VMS can be by access control list, that's not in
most versions of UNIX. UNIX uses groups to get the same functionality,
but it works poorly if you have a large number of files and need to
control access to each one individually. That is not usually needed or
even remotely useful in most software development environments.

  That's about it for head to head in my mind, I find the UNIX
environment easy to tailor to the way I want a computer to work, and
that usually improves productivity.
-- 
bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen)
    sysop *IX BBS and Public Access UNIX
    moderator of comp.binaries.ibm.pc and 80386 mailing list
"Stupidity, like virtue, is its own reward" -me

It's been almost a week since Siegfried Heintze made his bold request.  I'm
gratified to see no one has flamed him, but really no one has made a strong
answer either.  The utilities and shell tricks and so forth are nice, but what
about the design choices that make UNIX popular for systems and applications
programming?

This group is comp.unix.programmer, after all.  Isn't there someone out there
who can summarize the differences in working with the guts of VMX and UNIX,
someone who can speak from the experience of porting highly interactive
applications or writing device drivers or something like that?  There must be
some good general learning experiences here.

Guess everybody's too busy developing more such experience...

(I don't have such direct experience, so I've limited myself to replying to
Mr. Heintze by E-mail.)

-------------------------------------------------------------------------------

Andrew Oram                            Concurrent Computer Corporation
(I don't represent Concurrent; this message represents my own opinion)

Digital Communications Route: andyo@westford.ccur.com
                              {harvard,uunet,petsd}!masscomp!andyo
Analog Communications Route:  (508) 392-2865

Automatic UN*X documentation utility:

          cref | compress | crypt | man

-------------------------------------------------------------------------------

-----On 23 Oct 90 14:14:16 GMT, andyo@glasperl.masscomp (Andy Oram) said:

Andy> It's been almost a week since Siegfried Heintze made his bold
Andy> request.  I'm gratified to see no one has flamed him, but really
Andy> no one has made a strong answer either.  The utilities and shell
Andy> tricks and so forth are nice, but what about the design choices
Andy> that make UNIX popular for systems and applications programming?

Andy> This group is comp.unix.programmer, after all.  Isn't there
Andy> someone out there who can summarize the differences in working
Andy> with the guts of VMX and UNIX, someone who can speak from the
Andy> experience of porting highly interactive applications or writing
Andy> device drivers or something like that?  There must be some good
Andy> general learning experiences here.

I would speculate that there aren't that many people who have seriously
used both VMS and UNIX.  I have, at least somewhat seriously, although
I don't consider myself expert on either one.  I've used most of the
system service calls under VMS, and done some strange terminal I/O 
stuff under BSD.  More explicitly, I used VMS from versions 1.x to 4.x,
from 1979 to 1986, and UNIX from 1986 to present.  I bought VAXset,
which was referred to earlier, when it first came out, and watched
it develop.

I develop simulation software, and do not do device drivers or kernel
hacking.  My views would undoubtedly be different if I did device
drivers or internals.

Frankly, other than the portability argument, I don't think that
there's a lot of reason to switch from VMS to UNIX.  (Other than
getting out from under DEC's very expensive domain.)  VAXset compares
very favorably with the standard make/SCCS setup.  VERY favorably: CMS
has features in it that make it look OK compared to SCCS/RCS.  MMS
(comparable to make) is miserable and cryptic, but so is make.  The
code/variable navigation capability of (PCS? forget the name) isn't
available under UNIX unless you buy some third party stuff.  The VMS C
compiler was nearly ANSI three or four years ago -- most other vendors
haven't got their ANSI compilers out yet.  And, as a command language
environment, UNIX has a lot to hate: every command is its own little
world, with its own syntax and, frequently, the same switch does
something entirely different.  VMS has commands that behave according
to the same rules, with consistent syntax.  There are some things that
I used to do under VMS with a one line, relatively short command, that
take a shell script with a find command to do under UNIX.  Of course,
you can do anything with a complex enough find command ;-)

VMS, of course, has lots to get irritated about also, but I think a
person in the know can match point-for-point with similarly irritating
UNIX characteristics.  I can get my job done, reasonably well, in
either UNIX or VMS.

Now I am using UNIX and wouldn't go back to VMS (well, if someone
offered me LOTS of $$, perhaps).  Why?  DEC lost the workstation war
(or at least the first round of battles), and my program runs on
workstations.  If I port to a DEC machine, it will have to be one
running ULTRIX: VMS is an expensive, proprietary environment, and that
means lots of work, time, and effort in porting for a limited
audience.


--
Steve Hamm -------  Motorola Inc. Semiconductor Systems Design Technology
                    3501 Ed Bluestein Blvd., MD-M2, Austin TX 78762
Ph: (512) 928-6612  Internet:  hamm@austoto.sps.mot.com   
Fax:(512) 928-7662  UUCP:      ...cs.utexas.edu!oakhill!austoto!hamm