Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!usc!apple!voder!pyramid!ctnews!risky!pase70!scottl
From: scottl@convergent.com (Scott Lurndal)
Newsgroups: comp.arch
Subject: Re: Computers for users not programmers
Message-ID: <2922@risky.Convergent.COM>
Date: 13 Feb 91 22:26:41 GMT
References: <3159:Feb1213:56:3091@kramden.acf.nyu.edu> <1991Feb12.192725.21029@Think.COM>
Sender: root@risky.Convergent.COM
Reply-To: scottl@convergent.com (Scott Lurndal)
Organization: Unisys Network Computing Group
Lines: 39

In article <1991Feb12.192725.21029@Think.COM>, barmar@think.com (Barry Margolin) writes:
|> In article <3159:Feb1213:56:3091@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
writes:
|> >Some people think that if Fortran and C don't support an operation, it's
|> >a waste to put the operation into new chips. They're wrong. Just because
|> >language designers make mistakes doesn't mean those mistakes should last
|> >forever.
|> 
|> My guess (based on no hard evidence) is that Fortran and C are used for at
|> least 75% of systems and scientific programming, and this will almost
|> certainly be true for the lifetime of the coming generation of processors.
Yeah, but systems and scientific programming is probably 25-30% of all 
programming.   The other 70% is COBOL, RPG, 4GL (of which some are translated
into COBOL) and others.

If you look at some of the dedicated COBOL engines (such as the UNISYS V-Series
(old Burroughs Medium Systems) line), you will find that the instruction set
will not support C with any efficiency at all, and FORTRAN is marginal.

The point?  You cannot design a processor which is all things to all people
(the swiss army knife processor - (well the B1900 was a good start)).  If you 
design a processor around any particular language, you have reduced the 
overall usefullness of that processor.   Some of the current risc chips are
quite fast with scientific/systems applications (using C/Fortran/Pascal, et. al.);
but performance falls rapidly when you start running COBOL applications which
require translation from BCD<->binary before and after each arithmetic op.

Now I personally don't like COBOL, but I recognize that there is a tremendous
investment in COBOL programs in industry - and they are not going to go away
tomorrow.

|> --
|> Barry Margolin, Thinking Machines Corp.
|> 
|> barmar@think.com
|> {uunet,harvard}!think!barmar

Scott Lurndal
UNISYS Network Computing Group